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:
> >> >
> >> >
> >> 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:
> 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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk