Hi,

Maybe some of you can remember that, when I joined this list about two months ago, I proposed a "programable layer combine mode" for the GIMP.

The basic idea is that besides the "normal" "addition" " darken only" layer modes, to implement a "custom mode". In it, the user gets to type a c-like expression of what to do with the pixel values in each channel when combining the layer.

For example: RD=(R2 + R1) /2; GD=G2; BD= B1; will average the red component, pick the green component from the upper layer, and the blue component from the underlying image.

Another example: ED=VD> 0.5? DARKEN_ONLY : LIGHTEN_ONLY; If the Pixel value is greater than 0.5 (50%), then combine it as in the Darken Only mode, else, use Normal mode.

And it also works as a "paint mode", so custom paint mode comes as a bonus with this feature.

I had little time to fuss with it over the first month, and now I could manage to get some work going on - still only on a few hours per week.

I should make it clear that although I'd like to see it in the GIMP, at this time it's not what concerns me. If people think it's a nice feature, it can be made to work in a clean way before August 10th - actually, it already does work in a clean way, just lack features.

If no one is interested, I will appreciate help and feedback nonetheless, and once it's finished, I will just publish the patch to a stable version of the GIMP on my page.

However, I am getting some results now, so, I'd like to bring the discussion here, for there is a lot there is unknown to me in the GIMP tree.

(From here on, this message should be "readable" by people familiar] to the source code of the gimp. I mean - if you are confused with this, just skip the rest of the mail.)

First of all, I have the "engine" fairly complete in the app/paint-funcs/paint-funcs-generic.h file. Unfortunattely, I am working off-town, and can only recompile my GIMP, and hack it at all on the weekend.

And now, I am thinking on a way to get the custom combination data getting to it. For testing, so far,I had hardcoded the combiantion expression on the source file.

As far as I have thought, I'd like to feed it through a call in the combine_sub_region() paint-funcs.c function, passing extra data if mode==GIMP_CUSTOM_LAYER_MODE than it passes to the other functions. Actually, it will have to be this way.

At the same time the most obvious way to keep track of this data is putting it in image parasites. So, if a layer has got a custom mode, it's mode is attached to it in a parasite.

One issue I am having at the moment is that I'cannot figure out how to get the Parasite data from inside the "combine_sub_region" function - that function doesn't seen to be aware of in which image it is operating. I think that once I have the image id, it's allright to call the parasite functions on the libgimp-base api from within there.

One other doubt I have is where to put the ENUMs I need for the operators inside the engine. I can see the easier way is to add them to app/bse/base-enums.h.
Is there any problem with it?

And, while away from home, I try to get more familiarized with the code through browsing the cross referenced code on the developers page. But that only shows the files up to line 206. Is that correct? Is tehre a way to see the whole code files from that site?

So far...any feed back is welcome.

Thanks everybody.

JS ->

On Friday 25 July 2003 1:36 pm, Guillermo S. Romero / Familia Romero wrote:

gwidion@mpc.com.br (2003-07-24 at 2031.28 -0300):

The basic idea is that besides the "normal" "addition" " darken only" layer modes, to implement a "custom mode". In it, the user gets to type a c-like expression of what to do with the pixel values in each channel when combining the layer.

IMO you are forgeting a kind that users will like a lot more: call other GIMP functions, specially some like levels or curves (in this case, using the layer to control strengh in a channel by channel basis, or maybe using value (V in HSV) to get a single number and work like a selection mask, you should have to checke what makes sense). I guess users will find more use to those than playing around with formulas. I used the filter that lets you do math formulas to test ideas, but dunno how many people would like to use that daily.

My idea is that in the end, the custom layer formulas get recorded in a gimp directory, just like brushes and patterns. So, a set ofrather itneresting formulas would be shipped with the Gimp (or with the patch). That would provide alone could provide a lot of functionality.

My idea for the PDB entry is just to accept such a formula. I am sorry - I coonot think of another interface for this thing I am creating. When I first presented the idea, someone came up with the idea ofan interface like those used to set filters to e-mail prograns. Maybe it can be done... But when it´s i n formula type and go stage,, I will have some of you using the feature, and we will be able to think together on a new interface.

The formulas are nice, I am not saying you should drop that, but you should find a way to cover both if you can, formula and PDB. If you are going to get dirty, make it really worth it. Maybe even you can do the PDB way only, and provide a new call that does formulas (sounds simpler to me, more generic).

I don't get exactly what is your idea. I will probably, in the end make a gimp_custom_layer_set_mode (drawable, custom_layer_formula); where custom layer formula is a string exactly like the one taht would be typed on the interface.

The rendering engine use a stack - I am in the proccess of writting a "compiler" from the c like expression to the operand stack.

Hey, maybe you can fit into it effect layers. ;] Well, probably not, they are not simple operations to layers below them. Depends if you want to apply filter to the result, which is just the call idea, or to the layer data only,

Actually, thta already happens.
The formulas are simply. The input operands are the letters describing a channel, followed by "1" if the channel belongs to the image bellow, or "2" if it belongs to the actual layer. And letter+D makes the destiantion channel.
So something like:
RD=R2*R2; GD=G2*G2; BD=B2*B2;
will actually square the values of each channel. Since they are treated as normalized (i.e. from 0 to 1), it's akim to using the curves tool to enhance contrast sharply. The main difference is that you can work on the drawing while experimenting with the contrast levels, without wororring about spoiling the RGB data on the process. Just change back to "normal mode", and all your raw data is there.

which is what you need for auto
bevel or auto drop shadow when working with text, ie. Last case would be more like having a layer hidden as input and a visible one as output, and recalculate output one only when input changes, not every time layers below change.

Hmm. I am working ont he paint functions..gimp s smart,a nd the code on this are is rather clean now...The paint functions are only called when changes are made.
Drop shadow however is not an option - I can use the blend of the pixel directly bellow the one I am processing, and none other.

In any way, all are interesting ideas to explore.

I can barelly finish to get it working na reasonabvle dinamic form, so thatI myself can experiment with it.

On the technical side - I will need to code in some string manipulation now.
Are there API's for string deeply hidden ing gtk/gimplib? I had seen none so far (did nt pick GTK reference however),a nd I a m goint staright to stdlib's strlen and strncpy. Is there any issue with using these?

GSR

Cheers,

JS
->

On Saturday 26 July 2003 5:44 am, Adam D. Moss wrote:

Joao S. O. Bueno wrote:

My idea is that in the end, the custom layer formulas get recorded in a gimp directory, just like brushes and patterns.

How are they recorded in the XCF file? (I may have missed that part of the thread.)

Parasites. So the only difference to current XCF files would be anm extra layer_mode number.

So, a set

ofrather itneresting formulas would be shipped with the Gimp (or with the patch).

Users won't apply patches -- I doubt that more than a couple of percent of users are even actually building from source (especially for 2.0).

yes..that is why I'd be very pleased to see it in 2.0 (but even if I get it ready, it will be so close to freeze date, that maybe the mainteners reject it), or at least for 2.2 .

Hey, maybe you can fit into it effect layers. ;] Well, probably not, they are not simple operations to layers below them. Depends if you want to apply filter to the result, which is just the call idea, or to the layer data only,

Actually, thta already happens.
The formulas are simply. The input operands are the letters describing a channel, followed by "1" if the channel belongs to the image bellow, or "2" if it belongs to the actual layer. And letter+D makes the destiantion channel. So something like:
RD=R2*R2; GD=G2*G2; BD=B2*B2;
will actually square the values of each channel. Since they are treated as normalized (i.e. from 0 to 1), it's akim to using the curves tool to enhance contrast sharply.

(Well, contrast enhancement would be more like a sigmoid function -- what you describe here is basically gamma adjustment for a fixed gamma value.)

Ok, gamma them. Sorry, I am not versed in the mathematic fundamentals of thes corrections. However I will implement an exponentiatio operand - so one may use other gammas as well. But itŽwill have to use F.P. so expect it to be _slow_ .

I think that what GSR is really asking for in effect layers is stuff like 'blur layers', 'pixelize layers', etc, which basically is what everyone really wants. :) These require a decorrelation between the positions of pixels of different drawables though -- I made a working prototype of this during 1.1.x and it wasn't pretty.

Yes...no way to do taht just hacking in the paint-funcs already existing.

On the technical side - I will need to code in some string manipulation now.
Are there API's for string deeply hidden ing gtk/gimplib?

Not as such -- but if you're using GTK/gimplib then you're already using glib, which has some great string manipulation functions (go look them up).

Thanx. I will. :-)

--Adam

JS
->
--

Este e-mail é, exceto pelas partes citadas de outros e-mails, copyright(c) de João Sebastião de Oliveira Bueno. Nenhuma cópia deste e-mail ou parte do mesmo pode existir nas dependências de, ou em posse de funcionários, de associações protetoras de direitos autorais Brasileiras, dos Estados Unidos da América, ou de outros países. Em particular essa exceção do direito de leitura e posse deste e-mail se extende à ABRA, ABPI, ABES, BSA, RIAA e MPAA. Violadores estão infringindo as leis internacionais de direitos autorais e sujeitos às penalidades cabíveis. Você pode re-utilizar, emendar, acrescentar suas palavras e citar e re-enviar qualquer parte do mesmo, desde que essa nota seja preservada e se não pertencer a alguma das entidades supracitadas.

-------------------------------------------------------