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.

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)

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