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

Subject: Re: [Boost-users] [GIL] gil_function_requires( view that contains alpha )
From: Eloi Du Bois (eloi.du.bois_at_[hidden])
Date: 2009-12-06 10:28:26

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
>