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-15 17:14:52

Hi Mateusz,

>
> I have update my clone of GIL IOv2 and briefly played with your
> example a bit [1]
> using VS 2012 on Windows 8. FYI, your example compiles and runs well.
>
> [1] https://github.com/mloskot/boost-gil-workshop

That's good to know!

>
> A few questions from me:
>
> 1) Are we speaking of image_read_iterator or scanline_read_iterator?

scanline_read_iterator. I decided to rename the iterator to a name
that represents better the actual behavior. Turns out there are many
ways to read an image.

>
> 2) What is the difference between two templates in two different headers:
> /boost/gil/extension/io_new/scanline_read_iterator.hpp
> /boost/gil/extension/io_new/detail/image_read_iterator.hpp

scanline_read_iterator.hpp is obsolete and has been removed.

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

>
> 4) The meat of your example:
>
> reader_t reader = make_scanline_reader( file_name, bmp_tag() );
> byte_t* buffer = new byte_t[ reader._scanline_length ];
> scanline_read_iterator<reader_t> it  =
> scanline_read_iterator<reader_t>(reader, buffer);
> scanline_read_iterator<reader_t> end = scanline_read_iterator<reader_t>();
> int row = 0;
> while( it != end )
> {
>     *it; // ?
>
>     copy_pixels(
>         interleaved_view(reader._info._width, 1,
>             (image_t::view_t::x_iterator) buffer, reader._scanline_length)
>             , subimage_view(view(dst), 0, row, reader._info._width, 1));
>
>     ++row;
> }
>
> a) Initially, I was wondering why not to hide the buffer behind the reader.
>     But, I think the proposed composition of iterator from reader and buffer
>     given separately gives better flexibility.

Agreed.

>
> b) reader_t::begin(buffer) could be added, for convenience

Mhmm, you think so?

>
> c) Any particular reason you don't use result of the iterator
> deference directly?
>
> (image_t::view_t::x_iterator) *it

I don't need to in my example. The dereference operator returns the
buffer which we already have access to.

>
> d) By the way, have you tested writing the dst into a file?

I'll add that to my test. Just to be on the save side.

>
>
>
> Finally, question not related directly to iterators, but to GIL
> interface in general.
> GIL functions require to cast various objects to pointers or iterators,
> like in the example above:
>
>  (image_t::view_t::x_iterator) buffer
>
> IMO, it's weak link and it's the point where users mostly get into
> trouble with GIL.
> Would it be possible to at least document rules for such conversions?

I agree that gil's documentation is somewhat lacking and that the
learning curve is quite steep. On the other side gil does a lot behind
the scene and sometimes I find it amazing that it just works!

Now I cannot really comment on the reasoning why the initial
developers designed parts the way they did. But for x_iterator I
believe they did it well. Somehow you have to tell interleaved_view
what kind of view you will create. It's also very handy when dealing
for instance, with rgb and bgr images and generic algorithms.

A next version of gil will be better documented to at least boost
standard. That's at least a goal of me.

> What are the basic steps to decide on particular conversion of image
> buffer or view to
> certain type of pointer/iterator/location.

??? You lost me here.

> Obviously, it generally depends on image layout and configuration.
> The trouble for me so far was that to figure out valid and required conversions,
> one has to look at concrete types generated, frequently dig deep into GIL code.

Any example?

> Shortly, would it be possible to describe systematic way of deciding
> about these conversions in GIL?

What conversion? For instance there is no conversion when dealing with
"compatible" images, like rgb and bgr. Conversion takes place when
changing the color space.

Thanks again for your insight.

Christian