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-16 18:30:08

Hi Mateusz,

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

Could you give me some prototype code?

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

I don't wanna create an "obscure" iterator and try my best to make
sure it's easy to use and also to behave as expected. I know I'm not
an expert in the field but I'm here to learn.

Anyway, there are two thing I need to accomplish when reading image
and the common iterator interface doesn't seem to support it
naturally:

1) read a scanline, via dereference operator
2) don't read the scanline but still move the internal scanline
counter, via ++operator

I'm open to better ideas!

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

For rgb8_image_t the x_iterator is rgb8_pixel_t*. x_iterator you use
when you don't know the image_t or view_t during compile time.

Does that make sense?

Regards,
Christian