[GIL] Why does 'get_color' take a tag object instead of its type only?

TONGARI

28 Jan 2013 28 Jan '13

2:53 p.m.

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.

Attachments:

attachment.html (text/html — 432 bytes)

Show replies by date

Christian Henning

28 Jan 28 Jan

3:12 p.m.

Hi, On Mon, Jan 28, 2013 at 9:53 AM, TONGARI 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

TONGARI

29 Jan 29 Jan

5:52 a.m.

2013/1/28 Christian Henning

...

Hi,

On Mon, Jan 28, 2013 at 9:53 AM, TONGARI 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(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.

Christian Henning

3:26 p.m.

...

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

TONGARI

3:59 p.m.

2013/1/29 Christian Henning

...

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 get_color(ColorBase& cb, Color=Color()) I just want to know why not just take Color by the type, e.g. template 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(a) == fusion::at_key(b)

Christian Henning

4:16 p.m.

...

Uh... maybe I didn't express clearly. It's currently defined as:

template get_color(ColorBase& cb, Color=Color())

I just want to know why not just take Color by the type, e.g.

template 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::type foo( Color_Base& p ) { return get_color( p, Color() ); } template< typename Color, typename Color_Base > typename color_element_const_reference_type::type foo( const Color_Base& p ) { return get_color( p, Color() ); } int main() { unsigned char ff = foo( 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(a) == fusion::at_key(b)

Was Fusion around when gil was introduced? Christian

Mateusz Loskot

4:42 p.m.

On 29 January 2013 15:59, TONGARI wrote:

...

2013/1/29 Christian Henning

...
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 get_color(ColorBase& cb, Color=Color())

I just want to know why not just take Color by the type, e.g.

template 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

4407

Age (days ago)

4408

Last active (days ago)

List overview

Download

6 comments

3 participants

participants (3)

Christian Henning
Mateusz Loskot
TONGARI