|
Boost : |
Subject: Re: [boost] [GIL] Pixel Layout Padding?
From: TONGARI J (tongari95_at_[hidden])
Date: 2013-12-28 00:21:44
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.
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,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk