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)