Boost logo

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