[gil] numeric extension, arithmetic operators
Hey, Do we plan to overload arithmetic operators for Pixel as wrappers of the numeric extension? or should users derive a class from Pixel adding such functionality? ATM, for diving two pixels (rgb_8 for example), I have to call the division this way: pix_r = pixel_divide_t<rgb_8_pixel_t, rgb_8_pixel_t, rgb_8_pixel_t>().operator()(pix2, pix1); The thing is that I have a template class that makes use of operator/ at some point on one of the template parameters, and I would like to be able to use it with 'Pixel' type. Thank you!
Do we plan to overload arithmetic operators for Pixel as wrappers of the numeric extension? or should users derive a class from Pixel adding such functionality? ATM, for diving two pixels (rgb_8 for example), I have to call the division this way:
pix_r = pixel_divide_t<rgb_8_pixel_t, rgb_8_pixel_t, rgb_8_pixel_t>().operator()(pix2, pix1);
The thing is that I have a template class that makes use of operator/ at some point on one of the template parameters, and I would like to be able to use it with 'Pixel' type.
you cannot just write: pixel_multiply_t< Pixel, Pixel, Pixel > op; Pixel c = op( a, b );
Hey, Christian, do you mean "you *can* just write"? Anyway, I will try to derive a class from Pixel overloading the arithmetic operators by wrapping the pixel numeric operations. 2013/4/8 Christian Henning <chhenning@gmail.com>
Do we plan to overload arithmetic operators for Pixel as wrappers of the numeric extension? or should users derive a class from Pixel adding such functionality? ATM, for diving two pixels (rgb_8 for example), I have to call the division this way:
pix_r = pixel_divide_t<rgb_8_pixel_t, rgb_8_pixel_t, rgb_8_pixel_t>().operator()(pix2, pix1);
The thing is that I have a template class that makes use of operator/ at some point on one of the template parameters, and I would like to be able to use it with 'Pixel' type.
you cannot just write:
pixel_multiply_t< Pixel, Pixel, Pixel > op; Pixel c = op( a, b );
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Mon, Apr 8, 2013 at 10:12 AM, Harg Tholan <hargtholan@gmail.com> wrote:
Hey,
Christian, do you mean "you *can* just write"? Anyway, I will try to derive a class from Pixel overloading the arithmetic operators by wrapping the pixel numeric operations.
How will you define the return type? You know it can be anything that's compatible to the src types: e.g.: rgb8_pixel = bgr8_pixel + rgb8_pixel Christian
2013/4/8 Christian Henning <chhenning@gmail.com>
On Mon, Apr 8, 2013 at 10:12 AM, Harg Tholan <hargtholan@gmail.com> wrote:
Hey,
Christian, do you mean "you *can* just write"? Anyway, I will try to derive a class from Pixel overloading the arithmetic operators by wrapping the pixel numeric operations.
How will you define the return type? You know it can be anything that's compatible to the src types:
e.g.:
rgb8_pixel = bgr8_pixel + rgb8_pixel
You can return a "View" that is lazily evaluated, like what I did with Fusion.
Tongari, would you please pass me a link to your code. Thanks. 2013/4/8 TONGARI <tongari95@gmail.com>
2013/4/8 Christian Henning <chhenning@gmail.com>
On Mon, Apr 8, 2013 at 10:12 AM, Harg Tholan <hargtholan@gmail.com> wrote:
Hey,
Christian, do you mean "you *can* just write"? Anyway, I will try to derive a class from Pixel overloading the arithmetic operators by wrapping the pixel numeric operations.
How will you define the return type? You know it can be anything that's compatible to the src types:
e.g.:
rgb8_pixel = bgr8_pixel + rgb8_pixel
You can return a "View" that is lazily evaluated, like what I did with Fusion.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
2013/4/8 Harg Tholan <hargtholan@gmail.com>
Tongari, would you please pass me a link to your code.
Thanks.
That's just an idea. What I've written are Fusion adapter for GIL.Pixel and some associative Fusion algorithms. If you really want to do this in Fusion, I can provide the code ;)
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.
participants (3)
-
Christian Henning
-
Harg Tholan
-
TONGARI