[GIL] Pixel Layout Padding?
Hi there,
The current gil::pixel design has a deficiency that you can't specify the
align of pixel, for example, you can't have an RGBX pixel in GIL where X is
padding.
An alternative is to introduce a dummy channel for X, but that doesn't seem
to be a good idea as we don't want to mess up the color space.
So, maybe it'd be better to extend the current design, say,
pixel
2013/12/27 Christian Henning
I'm sure you thought of it but for now could you use RGBA? Probably not, but what would an alignment of 4 refer to? Is it size in bytes or channels?
Size in bytes.
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... Thanks,
2013/12/28 Christian Henning
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
2013/12/28 TONGARI J
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. 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? Thanks,
On Sat, Dec 28, 2013 at 12:21 AM, TONGARI J
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/...
Would you provide some code to play around with? Christian
2013/12/29 Christian Henning
May I introduce you to the mechanism Fusion used: https://github.com/boostorg/fusion/blob/master/include/boost/fusion/sequence... then the user would specialize boost::fusion::extension::at_impl for their own type. HTH
Christian Henning wrote:
FYI, I found it reasonably straightforward to add my own pixel types. For example, I've adapted std::complex<T> to serve as a pixel type for data in that colorspace, allowing me to create views and images of it, and to iterate over channels. I did have to overload at_c in the gil namespace, which I agree is a bad idea, and specializing, at_c_impl would be preferable. Thanks, Nate
On Fri, Dec 27, 2013 at 1:05 PM, TONGARI J
So, pixel
2013/12/29 Christian Henning
Yes.
Do you already have some code which could be added to GIL? I would be willing to incorporate it and write tests and update documentation.
Here's some code I extracted from my own lib, surely it won't compile for you, but I hope you'd get some idea. https://www.dropbox.com/sh/4dwin19dtcva5q5/k1cNXd0oyD
participants (3)
-
Christian Henning -
Nathan Crookston -
TONGARI J