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