[GIL] Why does 'get_color' take a tag object instead of its type only?
Hi there, I'm curious of why gil::get_color(pixel, tag) is defined that way. Any need to take the tag value? If not, I'd prefer gil::get_color<Tag>(pixel) or just gil::get<Tag>(pixel) or even Tag::get(pixel). And if possible, I hope GIL would just make pixel a Fusion sequence. Thanks.
Hi, On Mon, Jan 28, 2013 at 9:53 AM, TONGARI <tongari95@gmail.com> wrote:
Hi there,
I'm curious of why gil::get_color(pixel, tag) is defined that way. Any need to take the tag value?
If not, I'd prefer gil::get_color<Tag>(pixel) or just gil::get<Tag>(pixel) or even Tag::get(pixel).
You can use the "at_c" function. rgb8_pixel_t p( 10, 20, 30); unsigned char c = at_c<0>( p ); assert( c == 10 );
And if possible, I hope GIL would just make pixel a Fusion sequence.
I'm very interested in ideas to improve gil! Since I'm not familiar with a fusion sequence could you elaborate a little further. Regards, Christian
2013/1/28 Christian Henning <chhenning@gmail.com>
Hi,
On Mon, Jan 28, 2013 at 9:53 AM, TONGARI <tongari95@gmail.com> wrote:
Hi there,
I'm curious of why gil::get_color(pixel, tag) is defined that way. Any need to take the tag value?
If not, I'd prefer gil::get_color<Tag>(pixel) or just gil::get<Tag>(pixel) or even Tag::get(pixel).
You can use the "at_c" function.
rgb8_pixel_t p( 10, 20, 30); unsigned char c = at_c<0>( p ); assert( c == 10 );
That doesn't really answer my question... I just wonder the rationale for taking the tag value. I know there are at_c/semantic_at_c things, but they don't fit my need. Those functions are useful if I'm an end-user who knows the exact format, but I'm writing a 2D graphics lib building on GIL that intends to support all types the user gave, so index means nothing here, I must get the component by tag, thus get<red_t>(c) won't compile if the user gives cmyk.
And if possible, I hope GIL would just make pixel a Fusion sequence.
I'm very interested in ideas to improve gil! Since I'm not familiar with a fusion sequence could you elaborate a little further.
I imagine it to be an Associative Sequence in Fusion (naturally or adapted). So I can just use the algorithms provided by Fusion, which seem to overwhelm the static_xxxs in GIL. Thanks.
I'm curious of why gil::get_color(pixel, tag) is defined that way. Any need to take the tag value?
If not, I'd prefer gil::get_color<Tag>(pixel) or just gil::get<Tag>(pixel) or even Tag::get(pixel).
You can use the "at_c" function.
rgb8_pixel_t p( 10, 20, 30); unsigned char c = at_c<0>( p ); assert( c == 10 );
That doesn't really answer my question... I just wonder the rationale for taking the tag value.
I know there are at_c/semantic_at_c things, but they don't fit my need. Those functions are useful if I'm an end-user who knows the exact format, but I'm writing a 2D graphics lib building on GIL that intends to support all types the user gave, so index means nothing here, I must get the component by tag, thus get<red_t>(c) won't compile if the user gives cmyk.
By tag is useful when dealing with swapped channels, like rgb and bgr. For instance when reading a bmp file I read it as bgr but the end user most likely wants the rgb format. I'm not sure I follow your arguments. Why would you care for the tag? Just take the number of channels and enumerate over them. Is that not general enough for you? But maybe you wanna specialize your algorithm by the pixel layout type, e.g. rgb_layout_t.
And if possible, I hope GIL would just make pixel a Fusion sequence.
I'm very interested in ideas to improve gil! Since I'm not familiar with a fusion sequence could you elaborate a little further.
I imagine it to be an Associative Sequence in Fusion (naturally or adapted). So I can just use the algorithms provided by Fusion, which seem to overwhelm the static_xxxs in GIL.
Can it handle swapped channels? Like: rgb8_pixel_t a( 10, 20, 30 ); bgr8_pixel_t b( 30, 20, 10 ); assert( get_color( a, red_t() ) == get_color( b, red_t() ) ); Regards, Christian
2013/1/29 Christian Henning <chhenning@gmail.com>
By tag is useful when dealing with swapped channels, like rgb and bgr. For instance when reading a bmp file I read it as bgr but the end user most likely wants the rgb format.
Uh... maybe I didn't express clearly. It's currently defined as: template <typename ColorBase, typename Color> get_color(ColorBase& cb, Color=Color()) I just want to know why not just take Color by the type, e.g. template <typename Color, typename ColorBase> get_color(ColorBase& cb)
I'm not sure I follow your arguments. Why would you care for the tag? Just take the number of channels and enumerate over them. Is that not general enough for you?
But maybe you wanna specialize your algorithm by the pixel layout type, e.g. rgb_layout_t.
And if possible, I hope GIL would just make pixel a Fusion sequence.
I'm very interested in ideas to improve gil! Since I'm not familiar with a fusion sequence could you elaborate a little further.
I imagine it to be an Associative Sequence in Fusion (naturally or
adapted).
So I can just use the algorithms provided by Fusion, which seem to overwhelm the static_xxxs in GIL.
Can it handle swapped channels? Like:
rgb8_pixel_t a( 10, 20, 30 ); bgr8_pixel_t b( 30, 20, 10 );
assert( get_color( a, red_t() ) == get_color( b, red_t() ) );
I'm trying the non-intrusive (adapted) approach to make it a Fusion Sequence, I'll back to here when done. Code above could be rewritten as: fusion::at_key<red_t>(a) == fusion::at_key<red_t>(b)
Uh... maybe I didn't express clearly. It's currently defined as:
template <typename ColorBase, typename Color> get_color(ColorBase& cb, Color=Color())
I just want to know why not just take Color by the type, e.g.
template <typename Color, typename ColorBase> get_color(ColorBase& cb)
Sorry, I cannot comment on the this design decision. In case it really annoys you. You could just: template< typename Color, typename Color_Base > typename color_element_reference_type<Color_Base,Color>::type foo( Color_Base& p ) { return get_color( p, Color() ); } template< typename Color, typename Color_Base > typename color_element_const_reference_type<Color_Base,Color>::type foo( const Color_Base& p ) { return get_color( p, Color() ); } int main() { unsigned char ff = foo<red_t>( p ); return 0; } Hope this helps.
I'm trying the non-intrusive (adapted) approach to make it a Fusion Sequence, I'll back to here when done.
Code above could be rewritten as: fusion::at_key<red_t>(a) == fusion::at_key<red_t>(b)
Was Fusion around when gil was introduced? Christian
On 29 January 2013 15:59, TONGARI <tongari95@gmail.com> wrote:
2013/1/29 Christian Henning <chhenning@gmail.com>
By tag is useful when dealing with swapped channels, like rgb and bgr. For instance when reading a bmp file I read it as bgr but the end user most likely wants the rgb format.
Uh... maybe I didn't express clearly. It's currently defined as:
template <typename ColorBase, typename Color> get_color(ColorBase& cb, Color=Color())
I just want to know why not just take Color by the type, e.g.
template <typename Color, typename ColorBase> get_color(ColorBase& cb)
One of reasons, because then you couldn't utilise the fantastic feature of template argument deduction. Learn about "don't try help the compiler" principle from STL, at 10:00 min: http://channel9.msdn.com/Series/C9-Lectures-Stephan-T-Lavavej-Core-C-/Stepha... Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
participants (3)
-
Christian Henning -
Mateusz Loskot -
TONGARI