Re: [boost] [GIL] Pixel Layout Padding?

Subject: Re: [boost] [GIL] Pixel Layout Padding?
From: Christian Henning (chhenning_at_[hidden])
Date: 2013-12-28 11:52:52

On Sat, Dec 28, 2013 at 12:21 AM, TONGARI J <tongari95_at_[hidden]> wrote:

> 2013/12/28 TONGARI J <tongari95_at_[hidden]>
>
> > 2013/12/28 Christian Henning <chhenning_at_[hidden]>
> >
> >> >
> >> > > Could you describe a use case?
> >> > >
> >> >
> >> > I have to work with something like RGBQUAD which's layout is BGRX:
> >> >
> >> >
> >>
> http://msdn.microsoft.com/en-us/library/windows/desktop/dd162938(v=vs.85).aspx
> >>
> >>
> >> QQ, the rgbReserved represents the alignment?
> >>
> >
> > At least it requires 4 bytes by that structure.
> > Also note that Quartz 2D also has padded RGB: http://tinyurl.com/kdawwkl
> > So I think GIL being a generic library is reasonable to fill such a
> > requirement.
> >
> > Now I have my pixel defined as:
> >
> > template<class T, class Layout, int padding = 0>
> > class pixel;
> >
> > So RGBX becomes pixel<uint8_t, rgb_layout_t, 1>.
> >
>
> I thought I could plug my custom pixel into GIL elegantly, but I was wrong
> :(
> Is GIL not for extending!? The design somewhat prevents the user from
> customizing their pixels.
>
>
You might be right about adding new pixel types. But adding new color
spaces is quite easy, as the toolbox extension proves.

I have been working on a yuv pixel iterator which represents pixel data not
being consecutive in memory. Also here the extension of gil is not easy
since I need to extent planar_pixel_reference with a new constructor to
make the code work. It would be nice to discuss this issue in more detail
if you're willing.

The code can be found here:

http://gil-contributions.googlecode.com/svn/trunk/gil_2/boost/gil/extension/yuv

> For example, gil::at_c for each existed pixel is defined by overloading,
> that's a big problem for extension, the custom types after come cannot just
> overload 'at_c' to work with GIL, since those color_base_algorithm can only
> see those 'at_c' which are already defined before, not after.
> As the result, you see the huge "gil_concept.hpp" with lots of forward
> declaration :/
>
> Can this be improved, like what Fusion does?
>
>
Would you provide some code to play around with?

Christian