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:
(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
    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,

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, gregod at, cpdaniel at, john at