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

Subject: Re: [boost] [gil::io] Feedback for scanline_read_iterator
From: Christian Henning (chhenning_at_[hidden])
Date: 2013-02-18 12:31:28

Hi Phil,

>>> 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.  There is an exact converse case where you
> might want to combine many smaller images into one larger one, without
> needing enough RAM for the whole image.  Consider, for example, the final
> step in a panorama-stitching program like hugin: it's entirely reasonable to
> want to do this on a memory-constrained platform like a camera or phone.

You bring up a valid point and now I agree there should be
scaline_write_iterator.

>
> 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( .... );
> }
>

OK, my code sample wasn't clear. The dereference operator does return
a reference to the buffer which I ignored in my code.

> 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.

Mhmm, the ++operator will skip a scanline which is very format
specific and the dereference operator will read a scanline which of
course is also very format specific. So I guess your for loop you
presented above wont work as expected with my current implementation.

The difference to a "normal" iterator is that I have two distinct
functionalities that I need to squeeze into the standard iterator
interface. I would like to hear your opinion on how this could be
accomplished!

Thanks,
Christian