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

On Sat, Dec 28, 2013 at 12:21 AM, TONGARI J wrote:

2013/12/28 TONGARI J

...

2013/12/28 Christian Henning

...

...

...

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

...

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 pixel;

So RGBX becomes pixel.

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

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