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.
