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