|
Boost : |
Subject: Re: [boost] [gil] numeric extension, arithmetic operators
From: TONGARI (tongari95_at_[hidden])
Date: 2013-04-08 11:57:02
Hi Harg,
(bringing this back to the list)
2013/4/8 Harg Tholan <hargtholan_at_[hidden]>
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk