Subject: Re: [boost] [gil::io] Feedback for scanline_read_iterator
From: Christian Henning (chhenning_at_[hidden])
Date: 2013-02-18 12:31:28
>>> 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
> 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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk