[GIL] gil_function_requires( view that contains alpha )
Hi everybody, I would like to know if there is an easy way to check if a view type contains an alpha channel. I would do something like that (not tested): BOOST_STATIC_ASSERT(mpl::contains<typename color_space_type<Pixel>::type, alpha_t>::value); But I don't know if it is a good idea. Is there a way to do that with gil_function_requires ? Thanks & respect ! Eloi.
Eloi,
I would do something like that (not tested): BOOST_STATIC_ASSERT(mpl::contains<typename color_space_type<Pixel>::type, alpha_t>::value);
This works just fine.
But I don't know if it is a good idea. Is there a way to do that with gil_function_requires ?
You mean by adding a new concept to gil? I would just go with the metafunction you provided above. What are you trying to do? Some SFINAE? Christian
Ok, thanks :) I was looking for a gil concept. You are right, I am trying to do some SFINAE, now it works well :) I am trying to do some channel merging with templated functors (one which uses alpha and another which doesn't). If you are interested by the code (LGPL) I have made, I can send you what I have done. Maybe are you interested by adding such functions in a future version of gil ? I give you two files that shows the principle. I don't know if that will be usefull to you, anyway I think it's an interesting feature to put in gil. (the files I give to you is subject of bugs: it is under development). Eloi. 2009/12/2 Christian Henning <chhenning@gmail.com>
Eloi,
I would do something like that (not tested): BOOST_STATIC_ASSERT(mpl::contains<typename color_space_type<Pixel>::type, alpha_t>::value);
This works just fine.
But I don't know if it is a good idea. Is there a way to do that with gil_function_requires ?
You mean by adding a new concept to gil? I would just go with the metafunction you provided above. What are you trying to do? Some SFINAE?
Christian _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Hi Eloi, thanks for your submissions. I have tested them and they are working fine. One bug, so far, was in mergefunctors.hpp inside the FunctorPlus. Here, you're returning the result value instead of assigning it to the dst channel. Fix is simple and obvious. ;-) I have so many things in my head right now. Mostly details that I'll omit for now. Instead I would like to focus on the big picture. Basically, where do you think such algorithms fit in the domain of image processing? Are they more rgb/rgba algorithms or can one mix color spaces? Next thing is how to design such algorithms? The three functors you are providing are probably ( I'm not an expert in the field ) a small subset of all possibilities. I'm a big fan of the design of STL's algorithms. Here, you have basic general algorithms such for_each, transform, etc, where you add predicates ( functors ) as a parameters. Do you think we should stick to such paradigm when designing algorithmic gil extensions? GIL comes with transform_pixels which I think we could utilize. What's your opinion? Thanks again for your code. I like to see more of it! Regards, Christian On Thu, Dec 3, 2009 at 10:02 AM, Eloi Du Bois <eloi.du.bois@gmail.com> wrote:
Ok, thanks :) I was looking for a gil concept.
You are right, I am trying to do some SFINAE, now it works well :) I am trying to do some channel merging with templated functors (one which uses alpha and another which doesn't). If you are interested by the code (LGPL) I have made, I can send you what I have done. Maybe are you interested by adding such functions in a future version of gil ? I give you two files that shows the principle. I don't know if that will be usefull to you, anyway I think it's an interesting feature to put in gil. (the files I give to you is subject of bugs: it is under development).
Eloi.
2009/12/2 Christian Henning <chhenning@gmail.com>
Eloi,
I would do something like that (not tested): BOOST_STATIC_ASSERT(mpl::contains<typename color_space_type<Pixel>::type, alpha_t>::value);
This works just fine.
But I don't know if it is a good idea. Is there a way to do that with gil_function_requires ?
You mean by adding a new concept to gil? I would just go with the metafunction you provided above. What are you trying to do? Some SFINAE?
Christian _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
First, sorry for my poor English I'm a little tired (and French)... I am very glad that you took a look on my code. I am working hard on it to make it working better (to give a more generic code). I didn't saw that there was a numerical extension that allows to code generic formulas in gil, and yesterday, I read it and this is very interesting. The problem is that you may have formulas that uses that max value of a channel. Another example is color merging which uses hue of all other components to compute another one !... So I refactored all my code to give pixel instance to the functor insted of a component value. This makes it harder to code functors but allows us to implement all merging formulas and simplify the code in the merger. On monday, I'll send you what I did. Now to answer your questions: where do you think such algorithms fit in the domain of image processing? I thought that merging was a little thing to do, but this is a very important thing for example in digital effect compositing. Just take a look in, lets say, After Effect. You have modes called color dodge, color burn, screen, etc... And there is many others approaches to merge images. I think this may be interesting to have this in gil. Are they more rgb/rgba algorithms or can one mix color spaces? Yes, actually that's why the code I sent you is wrong...
Next thing is how to design such algorithms?
On monday, I will send you some of my ideas ;) The three functors you are providing are probably ( I'm not an expert in the
field ) a small subset of all possibilities
You are totally right: take a look on this website: http://www.pegtop.de/delphi/articles/blendmodes/dodge.htm Do you think we should stick to such paradigm when designing algorithmic gil
extensions?
You are right: if we can do it with stl/boost, it is better to use those tools. I am not a big expert, that is why I didn't use it. GIL comes with transform_pixels which I think we could utilize. What's your
opinion?
I tried, but the thing is transform_pixels only iterates on one view per time... Not two views and a destination... This would be good if we could use transform_pixels. Keep in touch, on monday I send you what I did if it is not too buggy... Thanks for your interest ! Eloi. 2009/12/5 Christian Henning <chhenning@gmail.com>
Hi Eloi, thanks for your submissions. I have tested them and they are working fine. One bug, so far, was in mergefunctors.hpp inside the FunctorPlus. Here, you're returning the result value instead of assigning it to the dst channel. Fix is simple and obvious. ;-)
I have so many things in my head right now. Mostly details that I'll omit for now. Instead I would like to focus on the big picture. Basically, where do you think such algorithms fit in the domain of image processing? Are they more rgb/rgba algorithms or can one mix color spaces?
Next thing is how to design such algorithms? The three functors you are providing are probably ( I'm not an expert in the field ) a small subset of all possibilities. I'm a big fan of the design of STL's algorithms. Here, you have basic general algorithms such for_each, transform, etc, where you add predicates ( functors ) as a parameters. Do you think we should stick to such paradigm when designing algorithmic gil extensions? GIL comes with transform_pixels which I think we could utilize. What's your opinion?
Thanks again for your code. I like to see more of it!
Regards, Christian
On Thu, Dec 3, 2009 at 10:02 AM, Eloi Du Bois <eloi.du.bois@gmail.com> wrote:
Ok, thanks :) I was looking for a gil concept.
You are right, I am trying to do some SFINAE, now it works well :) I am trying to do some channel merging with templated functors (one which uses alpha and another which doesn't). If you are interested by the code (LGPL) I have made, I can send you what I have done. Maybe are you interested by adding such functions in a future version of gil ? I give you two files that shows the principle. I don't know if that will be usefull to you, anyway I think it's an interesting feature to put in gil. (the files I give to you is subject of bugs: it is under development).
Eloi.
2009/12/2 Christian Henning <chhenning@gmail.com>
Eloi,
I would do something like that (not tested): BOOST_STATIC_ASSERT(mpl::contains<typename color_space_type<Pixel>::type, alpha_t>::value);
This works just fine.
But I don't know if it is a good idea. Is there a way to do that with gil_function_requires ?
You mean by adding a new concept to gil? I would just go with the metafunction you provided above. What are you trying to do? Some SFINAE?
Christian _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Eloi, just a quick note. GIL provides you with a transform_pixel version taking two src views and a dst view. Looking forward to your next post! Christian On Sun, Dec 6, 2009 at 10:28 AM, Eloi Du Bois <eloi.du.bois@gmail.com> wrote:
First, sorry for my poor English I'm a little tired (and French)... I am very glad that you took a look on my code. I am working hard on it to make it working better (to give a more generic code). I didn't saw that there was a numerical extension that allows to code generic formulas in gil, and yesterday, I read it and this is very interesting. The problem is that you may have formulas that uses that max value of a channel. Another example is color merging which uses hue of all other components to compute another one !... So I refactored all my code to give pixel instance to the functor insted of a component value. This makes it harder to code functors but allows us to implement all merging formulas and simplify the code in the merger. On monday, I'll send you what I did. Now to answer your questions:
where do you think such algorithms fit in the domain of image processing?
I thought that merging was a little thing to do, but this is a very important thing for example in digital effect compositing. Just take a look in, lets say, After Effect. You have modes called color dodge, color burn, screen, etc... And there is many others approaches to merge images. I think this may be interesting to have this in gil.
Are they more rgb/rgba algorithms or can one mix color spaces?
Yes, actually that's why the code I sent you is wrong...
Next thing is how to design such algorithms?
On monday, I will send you some of my ideas ;)
The three functors you are providing are probably ( I'm not an expert in the field ) a small subset of all possibilities
You are totally right: take a look on this website: http://www.pegtop.de/delphi/articles/blendmodes/dodge.htm
Do you think we should stick to such paradigm when designing algorithmic gil extensions?
You are right: if we can do it with stl/boost, it is better to use those tools. I am not a big expert, that is why I didn't use it.
GIL comes with transform_pixels which I think we could utilize. What's your opinion?
I tried, but the thing is transform_pixels only iterates on one view per time... Not two views and a destination... This would be good if we could use transform_pixels. Keep in touch, on monday I send you what I did if it is not too buggy... Thanks for your interest ! Eloi. 2009/12/5 Christian Henning <chhenning@gmail.com>
Hi Eloi, thanks for your submissions. I have tested them and they are working fine. One bug, so far, was in mergefunctors.hpp inside the FunctorPlus. Here, you're returning the result value instead of assigning it to the dst channel. Fix is simple and obvious. ;-)
I have so many things in my head right now. Mostly details that I'll omit for now. Instead I would like to focus on the big picture. Basically, where do you think such algorithms fit in the domain of image processing? Are they more rgb/rgba algorithms or can one mix color spaces?
Next thing is how to design such algorithms? The three functors you are providing are probably ( I'm not an expert in the field ) a small subset of all possibilities. I'm a big fan of the design of STL's algorithms. Here, you have basic general algorithms such for_each, transform, etc, where you add predicates ( functors ) as a parameters. Do you think we should stick to such paradigm when designing algorithmic gil extensions? GIL comes with transform_pixels which I think we could utilize. What's your opinion?
Thanks again for your code. I like to see more of it!
Regards, Christian
On Thu, Dec 3, 2009 at 10:02 AM, Eloi Du Bois <eloi.du.bois@gmail.com> wrote:
Ok, thanks :) I was looking for a gil concept.
You are right, I am trying to do some SFINAE, now it works well :) I am trying to do some channel merging with templated functors (one which uses alpha and another which doesn't). If you are interested by the code (LGPL) I have made, I can send you what I have done. Maybe are you interested by adding such functions in a future version of gil ? I give you two files that shows the principle. I don't know if that will be usefull to you, anyway I think it's an interesting feature to put in gil. (the files I give to you is subject of bugs: it is under development).
Eloi.
2009/12/2 Christian Henning <chhenning@gmail.com>
Eloi,
I would do something like that (not tested): BOOST_STATIC_ASSERT(mpl::contains<typename color_space_type<Pixel>::type, alpha_t>::value);
This works just fine.
But I don't know if it is a good idea. Is there a way to do that with gil_function_requires ?
You mean by adding a new concept to gil? I would just go with the metafunction you provided above. What are you trying to do? Some SFINAE?
Christian _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (2)
-
Christian Henning -
Eloi Du Bois