Re: [boost] [gil::io] Feedback for scanline_read_iterator

Subject: Re: [boost] [gil::io] Feedback for scanline_read_iterator
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2013-02-18 12:05:57

On 18 February 2013 16:52, Phil Endecott
<spam_from_boost_dev_at_[hidden]> wrote:
> Christian Henning wrote:
>>>
>>> 3) scanline_read_iterator is an input iterator, do you also plan output
>>> one too?
>>
>>
>> Not before the release. But logically I don't think there is much
>> interest. What do you think?
>
>
> The example that I originally presented for needing line-by-line access was
> to read in a very large image and cut it into tiles, without needing RAM
> proportional to the image size.

Phil,

Thanks for bringing this subject. It would be an important use case
for myself too.
I have assumed, at some point we may achieve this by the following:

* add tile_read_iterator which would dereference to tiles as views
* use scanline_read_iterator to access lines of current view (a memory
of tile data)

I'm thinking along the lines of TIFF spec, perhaps similar approach could
be based applied to strips-based access  combined with scanline_read_iteartor.

>>> c) Any particular reason you don't use result of the iterator
>>> deference directly?
>
>
> I agree that the way the iterator is dereferenced in that code ("*it;") is
> non-obvious.  I can't think of any other case where dereferencing an
> iterator has such significant side-effects i.e. it writes into an implied
> buffer and advances itself.  More conventional code might look like:
>
> buffer_t buffer = ......;
> iterator begin(.....);
> iterator end();
> for( iterator it = begin; it != end; ++it )
> {
>   const buffer_t& b = *it;
>   copy_pixels( .... );
> }
>
> Here I am explicitly (a) incrementing the iterator, and (b) using the result
> of the dereference.  I think you can do that and still get the same
> performance.

Thanks for completing the picture, I agree with that.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net