Hi Harg, (bringing this back to the list) 2013/4/8 Harg Tholan <hargtholan@gmail.com>
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<class A, class B> typename result<add_channel(A, B)>::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.