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
> 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.
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
Thanks for completing the picture, I agree with that.
-- Mateusz Loskot, http://mateusz.loskot.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk