[Gimp-developer] Re: Custom layer mode combination
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. --- -- 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. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Custom layer mode combination
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.) > 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). 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.) 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. 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). --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 That gum you like is going to come back in style. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Custom layer mode combination
On Friday 25 July 2003 1:36 pm, Guillermo S. Romero / Familia Romero wrote: > [EMAIL PROTECTED] (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 -><- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Custom layer mode combination
[EMAIL PROTECTED] (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. 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). 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, 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. In any way, all are interesting ideas to explore. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
