Re: [Boost-users] [GIL] gil_function_requires( view that contains alpha )

Subject: Re: [Boost-users] [GIL] gil_function_requires( view that contains alpha )
From: Christian Henning (chhenning_at_[hidden])
Date: 2009-12-06 10:47:13

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_at_[hidden]> 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_at_[hidden]>
>>
>> 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_at_[hidden]>
>> 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_at_[hidden]>
>> >>
>> >> 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_at_[hidden]
>> >> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>> >
>> >
>> > _______________________________________________
>> > Boost-users mailing list
>> > Boost-users_at_[hidden]
>> > http://lists.boost.org/mailman/listinfo.cgi/boost-users
>> >
>> _______________________________________________
>> Boost-users mailing list
>> Boost-users_at_[hidden]
>> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>