On Mon, Apr 8, 2013 at 10:12 AM, Harg Tholan wrote:

Hey,

Christian, do you mean "you *can* just write"? Anyway, I will try to derive a class from Pixel overloading the arithmetic operators by wrapping the pixel numeric operations.

How will you define the return type? You know it can be anything that's compatible to the src types: e.g.: rgb8_pixel = bgr8_pixel + rgb8_pixel Christian

Tongari, would you please pass me a link to your code. Thanks. 2013/4/8 TONGARI

2013/4/8 Christian Henning

...

On Mon, Apr 8, 2013 at 10:12 AM, Harg Tholan wrote:

...

Hey,

Christian, do you mean "you *can* just write"? Anyway, I will try to derive a class from Pixel overloading the arithmetic operators by wrapping the pixel numeric operations.

How will you define the return type? You know it can be anything that's compatible to the src types:

e.g.:

rgb8_pixel = bgr8_pixel + rgb8_pixel

You can return a "View" that is lazily evaluated, like what I did with Fusion.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Hi Harg, (bringing this back to the list) 2013/4/8 Harg Tholan

Hey,

thanks for the suggestion, I'll try to take a deeper look Fusion tomorrow. So that adapter for GIL.Pixel is not of public domain?

Thanks.

For those interested, the Fusion adapter is attached in this mail, and you could find some Fusion algorithms here: https://github.com/jamboree/fusion/tree/feature/ref (haven't pushed it for some time, not knowing if it's outdated) For your intent, may be used like (pseudo code): struct add_channel { template<class> struct result; ... template typename result::type operator()(A a, B b) const {...} // when fusion::left_mapping cannot find the right match template<class A> void operator()(A a, fusion::void_) const { static_assert("incompatible pixels"); } }; struct assign_channel{...}; ... rgb8_pixel pix1, pix3; bgr8_pixel pix2; // pix3 = pix1 + pix2 auto view = fusion::left_mapping(pix1, pix2, add_channel()); fusion::eval(fusion::left_mapping(boost::ref(pix3), view, assign_channel())); ------------------------------------------- Note fusion::left_mapping/fusion::eval/extension for boost::ref are all what I wrote (not provided by Fusion officially) and may reside in different feature branches on my github... For short, I see GIL.Pixel as associative Fusion Sequence, and fusion::left_mapping works like a left-join (in DB term) that associates the two with matched key (i.e. red_t, green_t, ...) and combines the values by a binary functor, and fusion::eval forces the evaluation of the view, and boost::ref(pix3) is there to keep it mutable.