>>
>> I never had the opportunity to
>> get myself familiar with fusion so I started learning it and I'm
>> really amazed how easy the library is to use. I think I'm at a point
>> where I would like to reach to the community for some advice.
>
>
> The very idea is to use Fusion to manipulate the pixel, not defining the
> pixel, though you could do it.

I think I must be misunderstood you then. No problem. But would you
agree that gil and fusion share at some code which could be
eliminated?

Ideally, static_xxx in GIL could be eliminated.

> I have one file "adapted_pixel.hpp" that adapts GIL pixel (concept) to
> Fusion Associative Sequence. Though I want to share here but there's another
> dependency on my other header.

It's fine when you just point out the general idea. What algorithms in
fusion do you use that's not available in gil?

I prefer Fusion for the extensibility and flexibility in writing my own algorithms.

What in GIL is a fixed set, not for extend, while Fusion can play the role of infrastructure.

>
> reverse_view is a view after all, so you can't instantiate it with ( 30, 20,
> 10 ).
> If you wanna define the reverse one, then fusion::map<..in reverse
> order...>.

So there is no way to define the return type for reverse view?

If you want:

result_of::as_map<reverse_view<...> >::type

>
> I'm happy with the way that GIL defines the pixel, what Fusion really shines
> here is the generalized way to manipulate the data.
>

Could you hint me some ideas for what fusion provides that's not in gil?

As I said, a generalized way to manipulate the data.

You can mix different types (not necessary pixel) to collaborate.

And once you developed an algorithm, it's not bound to pixel, but any compatible type.