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

Subject: Re: [boost] [gil::io] Feedback for scanline_read_iterator
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2013-02-15 19:54:31

On 15 February 2013 22:14, Christian Henning <chhenning_at_[hidden]> wrote:
> Mateusz Loskot <mateusz_at_[hidden]> 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?

I don't know if there is any interest, but my question was triggered by the
symmetry pursuit. It could make a logical addition.
Just asking, not expecting it

>> b) reader_t::begin(buffer) could be added, for convenience
>
> Mhmm, you think so?

With this suggestion, I hoped to provoke some wider discussion about
such interface. Not very common prototype of begin() function, is it?
It seems convenient as it hides the "boring" boilerplate, analogously to
std::make_pair and other such functions.

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

Yes, I understand that, but IMHO it makes the purpose of this iterator obscure.
You know the internal details of the iterator, so you use the fact
that the iterator
simply advances the buffer pointer.
You simply use the iteration side effect here.
But, I think most of  users who don't dig how this iterator is implemented, will
wonder why the result of derefence is not used.

I think, discoverability is important and most users will try to apply
the knowledge about
iterators they already have got.
Is there similar analogy to this in std:: or other commonly used
iterators that I've missed?

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

I believe these sequence of posts exchanged during the GIL review
explains it quite well, with most important part from the third link being

"We do indeed cast the user-supplied channel* to pixel_t*, so that we can
construct an interleaved view of the user-supplied memory. "

http://lists.boost.org/Archives/boost/2006/10/112053.php
http://lists.boost.org/Archives/boost/2006/10/112059.php
http://lists.boost.org/Archives/boost/2006/10/112064.php

but...

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

Simple question users frequently wonder about (mostly on SO, AFAIR):

How do I decide in particular case between casting to x_iterator or
rgb8_pixel_t*?

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

I meant conversions by casting, a type conversion within C++ domain.
Not color/channel/pixel conversions, not raster domain.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net