Re: [Gimp-developer] The Mark Shuttleworth offer
On Fri, Mar 19, 2004 at 08:56:36AM +0100, Henrik Brix Andersen wrote: [stuff deleted] The only thing that struck me as missing was the work involved with porting the plug-ins to the new API, but Raphaël already pointed that out in another reply to this thread. I very much hope that at least this time around, since so much is anyhow changed, the PDB will finally get the face lift and use named parameters instead of positional ones. Regards, Dov Sincerely, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The Mark Shuttleworth offer
Hi Dan, Daniel Rogers wrote: More details have come forward about the Mark Shuttleworth offer. Mark Shuttleworth made up his mind and decided to fund myself and Calvin to work on GEGL and GIMP/GEGL integration. Congratulations! :) Also, I want to prepare a press release about this, and would like some help with that. I can write the content, but those current press releases are so purty, and I'd like any new one to look like them. Can I suggest that you talk to Mark? He has more PR experience than any of us, and I'm sure that he would have some ideas to offer for a press release. 3. begin gimp integration () Time for completion: about a month -- a. replace tile manager with data compatible GeglBufferedImage. This involves modifying the existing gimp-compositing system to use GeglImage, as well as modifying GimpImage and GimpColor to use GeglImage and GeglColor. 4. start adding deep paint () time for completion: about 4-6 months -- a. modify GimpImage and GimpLayer to use a set of GeglOps. -- a. design a new file format (this has already begun), and start converting all the plug ins, core, and paint to use high bit depth (16 bit or float). If you started 3 after 2.2, that would have a 3.0 milestone somewhere around here. Can I check, then, what exactly will get done here? Do we keep a PDB compat layer around so that plug-ins that don't get changed still work, but only on 8 bits per channel? Do we declare teh milestone complete when the core has support internally for floating point, so that only tools get converted first, and we start working on plug-ins afterwards? I think that you're probably underestimating 4 by a bit, particularly since we will want a stable release at this point, which will mean (probably) a 3 month pre-release cycle like the one we've just had. Completion in 6 months is possible (with all plug-ins, I'm not sure), but that would make the 3.0 release next Summer - does that sound reasonable? We could even consider having a quickish stable release after 2.2 with just GeglImage replacing GimpLayer, which would give us a chance to work out any wrinkles in that milestone before we start really relying on it... 6. The big ones () Goal: start adding some long wanted features. a and b probably need to take place at the same time. () time for completion: about 6 months -- a. build the CMYK painting system. This will involve figuring out all the equivalent CMYK and RGB operations, and modifying the GIMP to use CYMK equivalent operations in place of RGB operations. -- b. add color management to the gui. -- c. add layer effects -- d. add layer groups. -- e. add clone layers. Cool - this sounds like a plan. At what stage do we turn plug-ins into nodes and replace the PDB with a node handler? I know that corba's a bad word, but how will plug-ins work after that? Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] l10n warning
On Fri, 19 Mar 2004 02:17:06 -0300, Joao S. O. Bueno [EMAIL PROTECTED] wrote: Other (%s) ... Is copyed from another one (as fuzzy) by gettext as a _Other (%d:%d) from somewhere else. That means that in a lot of languages we will have a %d %d in a printf-like string that will get just a string as a parameter. Let's see the good side of that: the opposite would have been much, much worse. ;-) Trying to use %s in a printf-like statement when two integers are supplied as parameters could have some consequences on the stability of the GIMP... Nonetheless, better be safe than sorry. I agree. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] l10n warning
Hi, Joao S. O. Bueno [EMAIL PROTECTED] writes: I am updating the translation because some strings had changed on the last couple days. I thought it is interesting to mention that the string: #: app/gui/image-menu.c:1744 Which is Other (%s) ... Is copyed from another one (as fuzzy) by gettext as a _Other (%d:%d) from somewhere else. That means that in a lot of languages we will have a %d %d in a printf-like string that will get just a string as a parameter. Translations marked as fuzzy are not used. Also, if a translator would remove the fuzzy marker, 'msgfmt -c -v' would bail out with a fatal error. Running this check is a prerequisite before committing a changed po file. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The Mark Shuttleworth offer
Dave Neary [EMAIL PROTECTED] writes: We could even consider having a quickish stable release after 2.2 with just GeglImage replacing GimpLayer, which would give us a chance to work out any wrinkles in that milestone before we start really relying on it... GeglImage can't replace GimpLayer, it can only replace TileManager. GEGL's scope is not to provide a replacement for GIMP's highlevel object system (GimpImage, GimpDrawable etc) but only for the lowlevel pixel storage buffers and the operations on/between them. ciao, --mitch ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The Mark Shuttleworth offer
Raphaël Quinet wrote: On Thu, 18 Mar 2004 16:38:55 -0800, Daniel Rogers [EMAIL PROTECTED] wrote: More details have come forward about the Mark Shuttleworth offer. Mark Shuttleworth made up his mind and decided to fund myself and Calvin to work on GEGL and GIMP/GEGL integration. Until today, I didn't have any specific details on the offer. You are bringing very good news here. Congratulations! The final thing I want to do here is to seek out what people think about putting a sponsors section on the new webpage, and devoting some space to thank Mark Shuttleworth for this (and hell, our past sponsers too). Do you think that it should be on developers.gimp.org, or www.gimp.org? Maybe both? Anyway, I think that it would be nice to mention our sponsors somewhere. Maybe this should be discussed on the gimp-web list? Probably on the gimp-web list yes. I think it should be on www.gimp.org. Sponsers are important and affect everyone. [...] The ones I really need to run past everyone are 3, 4, 5, and 6 as those involve core gimp and I need to make sure that I am not going to be working on anything that would be outright rejected by the gimp developers. 1 and 2 are gegl territory, and I know I'll accept that work :-) Most of the milestones seem reasonable, but I have some questions about how the GIMP integration would take place, especially regarding the plug-ins. Many of the current plug-ins are making more or less the same assuptions as the core regarding the bit depth of the images, etc. There is a lot of code to be re-written in the plug-ins and I expect them to be broken as soon as the format of the tiles is changed. I also expect that it would be difficult to fix them before some parts of the core become more stable. Well, my plan is to port the plugins to gegl first, then change the tile format. This would mean that, for a time, both old style and new style plugins would work. I also mean a complete review of the plugins, with refactoring of the plugins into a gegl-node + gimp-gui, with a standard set of classes that each plugin is a sub-class of. I suppose that you did not include the plug-ins in your activity planning because that would be too much work for a single programmer (but maybe I am underestimating you? ;-)) So I am wondering how we will be able to coordinate the work and update the plug-ins. Will there be a phase during which there would be a call for volunteers for updating all of the plug-ins once the new interfaces to the core become more mature? Or would it be possible to provide some kind of backwards compatibility so that the transition could be spread over a longer period, with some plug-ins using the new API while some others would still use the old one through a compatibility layer? A transition period is certainly possible. I don't think I will be able to port all the plugins quickly (though I could probably nail 80% of them in a short time, some of them are quite complicated and/or broken). There is also no reason why volunteers can't work on any of this stuff. I am not claiming every piece of this as my territory, only saying I will work on it. That doesn't mean other people can't. And backwards compatability should be possible. There is no reason to make the old plugins stop working (at least for 8 bits per channel, RGB). However the plugins will be more or less broken in that, unless they are ported, they won't work with high bit depths, or different color spaces. What I really meant to say on #4 anyway is that I expect to port most, if not all of the plugins. There is really no other way to do it. I don't believe deep paint will be a useful feature unless at least 95% of our core plugins support it. Let me put a revised #4 4. add deep paint () Goal: to start allowing The GIMP to handle high bit depths. The initial integration should not take long, but I foresee unforeseen problems, so I am setting this estimate high. () time for completion: about 4-6 months -- a. modify GimpImage and GimpLayer to use a set of GeglOps (this is equivlent to adding high bit depth to the core and paint). -- b. design a new file format (this has already begun) -- c. convert all the plug ins to have a class structure and use gegl-ops. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The Mark Shuttleworth offer
Kelly Martin wrote: Dave Neary wrote: We could even consider having a quickish stable release after 2.2 with just GeglImage replacing GimpLayer, which would give us a chance to work out any wrinkles in that milestone before we start really relying on it... Unless the code has changed a lot and I haven't noticed it (and looking I see it hasn't), you should be redesigning GimpDrawable (not GimpLayer) to inherit from GeglImage. Actually, yes. Though GimpDrawable, GimpLayer and GeglImage all need to be touched. I'm not sure whether having GimpImage inherit from GeglNode, or contain a member GeglNode, makes more sense. I believe GimpImage is a set of GimpLayers. It might even be able to stay that way. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The Mark Shuttleworth offer
Michael Natterer wrote: Dave Neary [EMAIL PROTECTED] writes: We could even consider having a quickish stable release after 2.2 with just GeglImage replacing GimpLayer, which would give us a chance to work out any wrinkles in that milestone before we start really relying on it... GeglImage can't replace GimpLayer, it can only replace TileManager. GEGL's scope is not to provide a replacement for GIMP's highlevel object system (GimpImage, GimpDrawable etc) but only for the lowlevel pixel storage buffers and the operations on/between them. What I mean is that everywhere it makes sense to _delegate_ to gegl structures things should be made to do so. I did misspeak about GimpImage, I know it is not similar to a GeglImage (more like a graph or somesuch). GimpImage and GimpLayer just need to be modified to do their image processing work with GeglNodes. -- Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The Mark Shuttleworth offer
Daniel Rogers [EMAIL PROTECTED] writes: From: Daniel Rogers [EMAIL PROTECTED] Subject: Re: [Gimp-developer] The Mark Shuttleworth offer To: [EMAIL PROTECTED] Date: Fri, 19 Mar 2004 06:54:34 -0800 Kelly Martin wrote: Dave Neary wrote: We could even consider having a quickish stable release after 2.2 with just GeglImage replacing GimpLayer, which would give us a chance to work out any wrinkles in that milestone before we start really relying on it... Unless the code has changed a lot and I haven't noticed it (and looking I see it hasn't), you should be redesigning GimpDrawable (not GimpLayer) to inherit from GeglImage. Actually, yes. Though GimpDrawable, GimpLayer and GeglImage all need to be touched. Actually no. GimpDrawable is a GimpItem is a GimpObject. It should *have* a GeglImage, not be one. I'm not sure whether having GimpImage inherit from GeglNode, or contain a member GeglNode, makes more sense. I believe GimpImage is a set of GimpLayers. It might even be able to stay that way. It should stat that way I'd say. ciao, --mitch ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The Mark Shuttleworth offer
Michael Natterer wrote: Actually no. GimpDrawable is a GimpItem is a GimpObject. It should *have* a GeglImage, not be one. Damn it. yes. I meant delagation, not inheritance. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The Mark Shuttleworth offer
Michael Natterer wrote: Actually no. GimpDrawable is a GimpItem is a GimpObject. It should *have* a GeglImage, not be one. Yes, this is probably correct. Tempbufs should probably also be replaced by GeglImages, and the entire paint core replaced by GeglOp-related operations. As I see it, GimpImage would contain a GeglNode, rather than inherit from it. There would be a contained GeglNode that would represent the current projection; it would be created from the existing layer channel lists. Part of the problem is that GeglNode can represent combinations that the GIMP doesn't support, and adding the UI support for those combinations is (remarkably) nontrivial. Also, there is not a one-to-one correspondence between GeglNodes and GimpLayers (some layers will generate only one GeglNode, others several, especially when layer masks are in use). Relying on decompiling the GeglNode to generate the Layers Channels dialog seems unwise. Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] l10n warning
On Friday 19 March 2004 09:56, Raphal Quinet wrote: On Fri, 19 Mar 2004 02:17:06 -0300, Joao S. O. Bueno [EMAIL PROTECTED] wrote: Other (%s) ... Is copyed from another one (as fuzzy) by gettext as a _Other (%d:%d) from somewhere else. That means that in a lot of languages we will have a %d %d in a printf-like string that will get just a string as a parameter. Let's see the good side of that: the opposite would have been much, much worse. ;-) Trying to use %s in a printf-like statement when two integers are supplied as parameters could have some consequences on the stability of the GIMP... Nonetheless, better be safe than sorry. I agree. -Raphal Ok, Currently there are these files in which this string is wrong. [EMAIL PROTECTED]:~/gimp/po$ grep -A6 #: app/gui/image-menu.c:1744 *po |grep %d ca.po-msgstr Altres (%d:%d) ... ga.po-msgstr Eile (%d:%d) ... hr.po-msgstr Drugi (%d:%d) ... lt.po-msgstr Kitas (%d:%d) ... ms.po-msgstr Lain (%d:%d) ... pt_BR.po-msgstr Outro (%d:%d) ... zh_TW.po-msgstr (%d:%d) ... [EMAIL PROTECTED]:~/gimp/po$ I had submited the changes to pt_br yesterday, I think the anoncvs just did not catch on yet. (if the gnome l10n coordinator for pt_br comitted it at all.) Someone should check again for the others just before a 2.0 final tarball. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] l10n warning
Hi, Joao S. O. Bueno [EMAIL PROTECTED] writes: Ok, Currently there are these files in which this string is wrong. This is false alarm! All these are just fuzzy translations and if translators follow the simple rule of checking their translation with 'msgfmt -c -v', it is impossible that such an error cannot happen. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] again: burn function - how does it work?
Hi.
After checking the i18n files i now know that nachbelichten is supposed to
be burn.
However, the appropriate function in app/coposite-generic.c does not seem to
behave as expected.
afaik the burn function should do nothing if the the upper (the burning) color
is white.
also a black pixel of the lower layer should remain black - whatever the upper
layer is colored.
However, this function:
while (length--)
{
for (b = 0; b alpha; b++)
{
tmp = (255 - src1[b]) 8;
tmp /= src2[b] + 1;
dest[b] = (guchar) CLAMP(255 - tmp, 0, 255);
}
if (has_alpha1 has_alpha2)
dest[alpha] = MIN(src1[alpha], src2[alpha]);
else if (has_alpha2)
dest[alpha] = src2[alpha];
src1 += bytes1;
src2 += bytes2;
dest += bytes2;
}
cannot provide this.
(e.g. upper (src1) is white (255) - tmp = 0 8 = 0; = 0 / ? + 1 = 0;
CLAMP(255 - 0, 0, 255) = 255 = white - so white will flatten anything instead
of leaving it as it is.
as a consequence, black won't remain, as soon as one of the components r,g,b =
255.
i tried to weight the effect (255-0)/255*burn + (1-(255-0)/255)*original...
but the result wasn't like what i expected.
so - does anyone know which step i missed, or where i can get more information
about the theory behind?
Thanks,
Thomas
--
Think, think different. But essentially: Think!
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer)
On Fri, Mar 19, 2004 at 10:50:23AM +0200, [EMAIL PROTECTED] wrote: On Fri, Mar 19, 2004 at 08:56:36AM +0100, Henrik Brix Andersen wrote: [stuff deleted] The only thing that struck me as missing was the work involved with porting the plug-ins to the new API, but Rapha?l already pointed that out in another reply to this thread. I very much hope that at least this time around, since so much is anyhow changed, the PDB will finally get the face lift and use named parameters instead of positional ones. A PDB revamp is planned. While on that subject, I'm wondering what a good way of representing named parameters in scheme and perl would be. Any thoughts? -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Gimp.app application bundle
Okay... I made a tweak to the 2.0pre3 bundle so it no longer assumes the /etc/fonts directory exits. I thought /etc/fonts was installed by X11.app, but apparently that's not the case. I also added a readme and a GPL license file to the dmg as well as a couple of weblink files for downloading X11.app There is now a new sourceforge project website for it. It's ready to be linked to from gimp.org. http://gimp-app.sourceforge.net If anyone has any suggestions for the website or the application bundles, let me know. l8r Aaron Commitment can be illustrated by a breakfast of ham and eggs. The chicken was involved, the pig was committed. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Gimp.app application bundle
Aaron Voisine wrote: Okay... I made a tweak to the 2.0pre3 bundle so it no longer assumes the /etc/fonts directory exits. If anyone has any suggestions for the website or the application bundles, let me know. Why not pre4? Michael ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer)
Manish Singh ([EMAIL PROTECTED]) wrote: On Fri, Mar 19, 2004 at 10:50:23AM +0200, [EMAIL PROTECTED] wrote: On Fri, Mar 19, 2004 at 08:56:36AM +0100, Henrik Brix Andersen wrote: [stuff deleted] The only thing that struck me as missing was the work involved with porting the plug-ins to the new API, but Rapha?l already pointed that out in another reply to this thread. I very much hope that at least this time around, since so much is anyhow changed, the PDB will finally get the face lift and use named parameters instead of positional ones. A PDB revamp is planned. While on that subject, I'm wondering what a good way of representing named parameters in scheme and perl would be. Any thoughts? Hmm, isn't there a perl-way to do named parameters? I bet there is (but I don't know about it). After a quick search on google the following seems to be standard: gimp_perl_foo_bar (-image = image, -drawable = drawable, -radius = 5.5, -size = 300); For scheme we could do something like this: (script-fu-foo-bar '(imageimage) '(drawable drawable) '(radius 5.5) '(size 300)) or (less clutter) (script-fu-foo-bar imageimage drawable drawable radius 5.5 size 300) that having said: I don't have much experience with scheme outside script fu, so there might be a convention out there on how to do named parameters. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer)
On Sat, Mar 20, 2004 at 12:58:25AM +0100, Simon Budig wrote:
Manish Singh ([EMAIL PROTECTED]) wrote:
On Fri, Mar 19, 2004 at 10:50:23AM +0200, [EMAIL PROTECTED] wrote:
On Fri, Mar 19, 2004 at 08:56:36AM +0100, Henrik Brix Andersen wrote:
[stuff deleted]
The only thing that struck me as missing was the work involved with
porting the plug-ins to the new API, but Rapha?l already pointed that
out in another reply to this thread.
I very much hope that at least this time around, since so much is anyhow
changed, the PDB will finally get the face lift and use named parameters
instead of positional ones.
A PDB revamp is planned.
While on that subject, I'm wondering what a good way of representing
named parameters in scheme and perl would be. Any thoughts?
Hmm, isn't there a perl-way to do named parameters? I bet there is (but
I don't know about it).
After a quick search on google the following seems to be standard:
gimp_perl_foo_bar (-image = image,
-drawable = drawable,
-radius = 5.5,
-size = 300);
Yeah, I thought of that, but I'm not sure how you'd differentiate between
named usage and positional usage.
With both
gimp_perl_foo_bar($image, $drawable, 5.5, 300)
and
gimp_perl_foo_bar(-image = $image, -drawable = $drawable,
-radius = 5.5, -size = 300)
all perl hands the function is a list of values. CGI.pm tries to guess
about this, but it's easily fooled if the actual data string you give it
starts with '-'.
One way to do it would be:
gimp_perl_foo_bar({image = $image, drawable = $drawable,
radius = 5.5, size = 300})
And check if we get a hash reference as our first arg, but that seems
a bit nonobvious.
For scheme we could do something like this:
(script-fu-foo-bar '(imageimage)
'(drawable drawable)
'(radius 5.5)
'(size 300))
or (less clutter)
(script-fu-foo-bar imageimage
drawable drawable
radius 5.5
size 300)
that having said: I don't have much experience with scheme outside
script fu, so there might be a convention out there on how to do named
parameters.
Again there is the problem of differeniating between positional
and named usage.
-Yosh
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer)
Manish Singh ([EMAIL PROTECTED]) wrote: On Sat, Mar 20, 2004 at 12:58:25AM +0100, Simon Budig wrote: For scheme we could do something like this: (script-fu-foo-bar '(imageimage) '(drawable drawable) '(radius 5.5) '(size 300)) or (less clutter) (script-fu-foo-bar imageimage drawable drawable radius 5.5 size 300) that having said: I don't have much experience with scheme outside script fu, so there might be a convention out there on how to do named parameters. Again there is the problem of differeniating between positional and named usage. Ok, thinking some more about it: What about using symbols as parameter identifiers? (script-fu-foo-bar 'imageimage 'drawable drawable 'radius 5.5 'size 300) passing symbols to the PDB doesn't make sense, so this could be used to differentiate. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer)
On Sat, Mar 20, 2004 at 01:34:02AM +0100, Simon Budig wrote: Manish Singh ([EMAIL PROTECTED]) wrote: On Sat, Mar 20, 2004 at 12:58:25AM +0100, Simon Budig wrote: For scheme we could do something like this: (script-fu-foo-bar '(imageimage) '(drawable drawable) '(radius 5.5) '(size 300)) or (less clutter) (script-fu-foo-bar imageimage drawable drawable radius 5.5 size 300) that having said: I don't have much experience with scheme outside script fu, so there might be a convention out there on how to do named parameters. Again there is the problem of differeniating between positional and named usage. Ok, thinking some more about it: What about using symbols as parameter identifiers? (script-fu-foo-bar 'imageimage 'drawable drawable 'radius 5.5 'size 300) passing symbols to the PDB doesn't make sense, so this could be used to differentiate. That's a good idea. Unless there's some other standard way of handling this in scheme (anyone?) this sounds good to me. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer)
Simon Budig wrote: Ok, thinking some more about it: What about using symbols as parameter identifiers? (script-fu-foo-bar 'imageimage 'drawable drawable 'radius 5.5 'size 300) passing symbols to the PDB doesn't make sense, so this could be used to differentiate. The more Scheme-like approach would be to add a read syntax which instantiates a parameter name type. So, something like (script-fu-f00-bar ::image image) (:: being an arbitrary syntactic marker that I just made for which an appropriate syntax macro has been defined; you can theoretically use anything not already assigned to something else), which is internally expanded to (script-fu-f00-bar #parameter image image) which is then magically converted to however the PDB handles parameter passing by the appropriate Scheme-C glue code. Not only is this more in keeping with how Scheme is generally used, it's conceptually much cleaner because it avoids overloading quoted interned symbols. Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer)
For various reasons that I don't know about or don't completely understand, several of the proposals that have already been made may be far superior to what I am about to suggest. In fact, there could easily be some reason why my suggestion is completely unworkable. Never the less, I have worked with other languages where using named items based on the following simple syntax seems to work well, and I'm wondering if it might be a better alternative than some of the other suggestions: (script-fu-foo-bar image=myimage size=300) Some languages allow unquoted parameter strings when the type can be identified based on the parameter name or value and there are no embedded blanks or other delimiters withing the parameter value. Some languages use single quotes instead of double quotes, and some languages allow both. Most languages with syntax along these lines also allow quotes characters to be doubled up in order to represent the occurance of a quote character within the parameter value. Most of you guys are probably already very well aware of syntax like this, so it may not be possible or advisable here for some reason. But I just thought that I'd throw this idea out in case it was being overlooked and might solve any of the other problems that have been discussed. s/KAM - Original Message - From: Kelly Martin [EMAIL PROTECTED] To: Simon Budig [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, March 19, 2004 7:35 PM Subject: Re: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer) Simon Budig wrote: Ok, thinking some more about it: What about using symbols as parameter identifiers? (script-fu-foo-bar 'imageimage 'drawable drawable 'radius 5.5 'size 300) passing symbols to the PDB doesn't make sense, so this could be used to differentiate. The more Scheme-like approach would be to add a read syntax which instantiates a parameter name type. So, something like (script-fu-f00-bar ::image image) (:: being an arbitrary syntactic marker that I just made for which an appropriate syntax macro has been defined; you can theoretically use anything not already assigned to something else), which is internally expanded to (script-fu-f00-bar #parameter image image) which is then magically converted to however the PDB handles parameter passing by the appropriate Scheme-C glue code. Not only is this more in keeping with how Scheme is generally used, it's conceptually much cleaner because it avoids overloading quoted interned symbols. Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer)
Kevin Myers wrote: (script-fu-foo-bar image=myimage size=300) Defining syntax macros for such a syntax in Scheme is less than straightforward, and is also very un-Scheme-like. Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer)
You seem to know what you're talking about Kelly, so I'll have to accept your word that my suggestion is un-Scheme-like. However, please verify one thing regarding your suggestion: How do you handle parameter values with imbedded blanks or other special characters? I am especially concerned about this issue, because previously I have found it almost completely impossible to pass appropriate parameter values to some otherwise very desirable gimp scripts from the Windows command prompt... Thanks, s/KAM - Original Message - From: Kelly Martin [EMAIL PROTECTED] To: Kevin Myers [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, March 19, 2004 8:11 PM Subject: Re: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer) Kevin Myers wrote: (script-fu-foo-bar image=myimage size=300) Defining syntax macros for such a syntax in Scheme is less than straightforward, and is also very un-Scheme-like. Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer)
Kevin Myers wrote: You seem to know what you're talking about Kelly, so I'll have to accept your word that my suggestion is un-Scheme-like. However, please verify one thing regarding your suggestion: How do you handle parameter values with imbedded blanks or other special characters? (True) Scheme has a quoting mechanism for this issue, which is relatively well defined. It might be tricky to quote those quotes when you're using an inferior command shell (such as Windows Explorer), but this should be considered a fault of those environments -- and is certainly no reason to abandon the R5RS standard. Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer)
Hi Kelly, I understand your basic points, but... Admittedly, the Windows command prompt (not simply Explorer) is less capable than most *nix command shells. However, there are also a very large number of Windows based GIMP users, and one of the requirements of GIMP 2.x is that it should be as usable under Windows as it is on other operating systems. I'm not familiar with R5RS, and you could certainly be right in your opinion regarding that. However, as a Windows GIMP user (and much more rarely a GIMP bug, patch, fix, and enhancement contributor), I want to make sure that there isn't excessive *nix bias that inhibits or ignores usability needs under Windows. For example, in one past case, I wanted to run a simple GIMP script from the Windows command shell, and there wasn't one single person (Sven and everyone else included), who was able to tell me how to arrange the quoting to get the script to run along with the required parameters. That level of disfunctionality is not acceptable, and should be eliminated, even if it means doing something like abandoning (or modifying) certain *nix based standards for the Windows version of the GIMP. Obviously though, I do realize the strong need to minimize any such Windows-specific behavior, and that any such differences should receive a great deal of very careful consideration before implementation. In the past however, I feel that the scale may have been tipped slightly too far against Windows on such issues. s/KAM - Original Message - From: Kelly Martin [EMAIL PROTECTED] To: Kevin Myers [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, March 19, 2004 9:07 PM Subject: Re: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer) Kevin Myers wrote: You seem to know what you're talking about Kelly, so I'll have to accept your word that my suggestion is un-Scheme-like. However, please verify one thing regarding your suggestion: How do you handle parameter values with imbedded blanks or other special characters? (True) Scheme has a quoting mechanism for this issue, which is relatively well defined. It might be tricky to quote those quotes when you're using an inferior command shell (such as Windows Explorer), but this should be considered a fault of those environments -- and is certainly no reason to abandon the R5RS standard. Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer)
Kevin Myers wrote: Hi Kelly, I understand your basic points, but... Admittedly, the Windows command prompt (not simply Explorer) is less capable than most *nix command shells. However, there are also a very large number of Windows based GIMP users, and one of the requirements of GIMP 2.x is that it should be as usable under Windows as it is on other operating systems. I'm not familiar with R5RS, and you could certainly be right in your opinion regarding that. However, as a Windows GIMP user (and much more rarely a GIMP bug, patch, fix, and enhancement contributor), I want to make sure that there isn't excessive *nix bias that inhibits or ignores usability needs under Windows. Windows inhibits its own usability in this respect. It is nearly impossible to get imbedded quotes from the Windows command line. This is a defect in the Windows shell. Getting around it would force us to use some weird character for string quoting, which would be confusing to everyone. In my opinion, the sacrifice is not worth the gain: we should not have to do something Weird and Bizarre to cope with Microsoft's inferior product. Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer)
Kelly Martin ([EMAIL PROTECTED]) wrote: Kevin Myers wrote: Admittedly, the Windows command prompt (not simply Explorer) is less capable than most *nix command shells. However, there are also a very large number of Windows based GIMP users, and one of the requirements of GIMP 2.x is that it should be as usable under Windows as it is on other operating systems. Windows inhibits its own usability in this respect. It is nearly impossible to get imbedded quotes from the Windows command line. This is a defect in the Windows shell. Getting around it would force us to use some weird character for string quoting, which would be confusing to everyone. In my opinion, the sacrifice is not worth the gain: we should not have to do something Weird and Bizarre to cope with Microsoft's inferior product. Also please consider, that scripting from the commandline is not the thing the average Windows- (and even Linux-) user needs. If a windows user really needs scripting, I'd recommend to install e.g. a bash. The other option always is to use gimp-1.3 --batch - and pass the commands to execute to stdin. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer)
Hi Kelly, Though I basically agree with your opinion of the inferior Windows command shell, IMHO that doesn't excuse important GIMP features from being completely inoperable under Windows. Inconvenient is one thing, impossible another. I can appreciate your strong desire to avoid a kludge workaround, but at this point I'm not at all certain that the only possible solutions are quite as bad as your comments would imply. Never the less, I think that we have both probably expressed our opinions adequately on these issues at this point, and may simply have to agree to disagree in some respects, and let other developers and users weigh in to help determine the best approach. I just wanted to help make sure that some concerns from the Windows side of the equation were voiced. I'll back off now and let the discussion resume between yourself and the other gimp gurus. Regards, s/KAM - Original Message - From: Kelly Martin [EMAIL PROTECTED] To: Kevin Myers [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, March 19, 2004 9:48 PM Subject: Re: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer) Kevin Myers wrote: Hi Kelly, I understand your basic points, but... Admittedly, the Windows command prompt (not simply Explorer) is less capable than most *nix command shells. However, there are also a very large number of Windows based GIMP users, and one of the requirements of GIMP 2.x is that it should be as usable under Windows as it is on other operating systems. I'm not familiar with R5RS, and you could certainly be right in your opinion regarding that. However, as a Windows GIMP user (and much more rarely a GIMP bug, patch, fix, and enhancement contributor), I want to make sure that there isn't excessive *nix bias that inhibits or ignores usability needs under Windows. Windows inhibits its own usability in this respect. It is nearly impossible to get imbedded quotes from the Windows command line. This is a defect in the Windows shell. Getting around it would force us to use some weird character for string quoting, which would be confusing to everyone. In my opinion, the sacrifice is not worth the gain: we should not have to do something Weird and Bizarre to cope with Microsoft's inferior product. Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: PDB named and default parameters (was Re: [Gimp-developer] TheMark Shuttleworth offer)
Hmmm, I wonder why using the --batch option wasn't suggested when I ran into the problems that I mentioned previously... Unfortunately, it has been so long ago now that I don't remember the details. I gave up trying after a couple of days of trial and error plus a number of related emails. I can't think of any reason at this point why that wouldn't have been a reasonable solution. s/KAM - Original Message - From: Simon Budig [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, March 19, 2004 9:59 PM Subject: Re: PDB named and default parameters (was Re: [Gimp-developer] TheMark Shuttleworth offer) Kelly Martin ([EMAIL PROTECTED]) wrote: Kevin Myers wrote: Admittedly, the Windows command prompt (not simply Explorer) is less capable than most *nix command shells. However, there are also a very large number of Windows based GIMP users, and one of the requirements of GIMP 2.x is that it should be as usable under Windows as it is on other operating systems. Windows inhibits its own usability in this respect. It is nearly impossible to get imbedded quotes from the Windows command line. This is a defect in the Windows shell. Getting around it would force us to use some weird character for string quoting, which would be confusing to everyone. In my opinion, the sacrifice is not worth the gain: we should not have to do something Weird and Bizarre to cope with Microsoft's inferior product. Also please consider, that scripting from the commandline is not the thing the average Windows- (and even Linux-) user needs. If a windows user really needs scripting, I'd recommend to install e.g. a bash. The other option always is to use gimp-1.3 --batch - and pass the commands to execute to stdin. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: PDB named and default parameters (was Re: [Gimp-developer] TheMark Shuttleworth offer)
On Fri, Mar 19, 2004 at 10:11:53PM -0600, Kevin Myers wrote: Hmmm, I wonder why using the --batch option wasn't suggested when I ran into the problems that I mentioned previously... i was part of this discussion. you were given honest answers from the linux people developing TheGIMP. we all use Image Magick to do batch processing. The manpages are some of the best written and the convert, mogrify and other image magick commands usually come with every linux distribution. if i need more than Image Magick can do, i write python scripts. All of the gimp scripts have a browser which should avoid any problems that a GIMP User on Windows(TM) should have. also, if you really like to use the command line, why ever are you using Windows? Unfortunately, it has been so long ago now that I don't remember the details. I gave up trying after a couple of days of trial and error plus a number of related emails. I can't think of any reason at this point why that wouldn't have been a reasonable solution. i have a complaint about the way emails are being formated on what should be a repectable mail list. i am sending it in a different email. carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] gimp-developer email
hi, i dont know who did it; but since TheGIMP is running on a lot of different operating systems, the quality of the email being sent to this list is pathetic. TheGIMP comes from a long line of GNU/Linux developers and even before that -- by people who wanted to share and not steal. Please review the email ettiquette before suggesting that the quality of all things GIMP go further downhill for other operating systems: http://mmmaybe.gimp.org/mail_lists.html TheGIMP has a decidedly GNU/Linux way about it. call it a bias even. get used to it. thanks, carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer)
Simon Budig writes: If a windows user really needs scripting, I'd recommend to install e.g. a bash. True, but doesn't necessarily help. The Win32 process invokation API (CreateProcess()) doesn't use a argument vector like Unix does. It uses a command line. The argv that a C or C+++ main() receives has to be constructed from the command line that the operating system passes to it. (In the Microsoft C library there are exec*()-like functions that take an argument vector, but that argument vector is then joined together into a command line that is actually passed to the CreateProcess() API.) Thus, there are many levels of quoting/unquoting/splicing/whatever going on starting from the command line you type into bash on Cygwin on Windows, ending at the argv passed to main(). If you value your sanity, you shouldn't try to pass a Scheme expression potentially requiring quotes, embedded spaces in arguments, whatever, to a program... The other option always is to use gimp-1.3 --batch - and pass the commands to execute to stdin. Unfortunately, in GIMP 1.2.x, that is explicitly disabled on Win32 in the source. I don't remember the exact reason for this, presumably because some detail in the GLib main loop Win32 implementation that would have prevented it from working anyway. It isn't disabled in the GIMP HEAD (i.e. 2.0preX) sources (and there has been some changes to the GLib main loop now and then), so it might even work. I'll have to check. --tml ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer)
Hi Carol, I/we are already users and contributors to the ImageMagick and GraphicsMagick projects as well as the GIMP. Both of those programs and the GIMP have certain key strengths and weaknesses with respect to each other, such that they are certainly not direct substitutes in *many* respects. That was certainly the case with our previous need regarding command line execution of a Gimp script under Windows. For another example, the GIMP can handle the size of our larger image files under Windows, while IM and GM still cannot. (IM and GM pixel representation in memory is always at least 40 bit (8x5), while the GIMP allows 8 bit memory representation, allowing roughly 5 times more pixels to be manipulated under Windows). It is utterly ridiculous that simply because I voiced concerns about and would like for the ability to have gimp scripts execute properly from the command line under Windows that you accuse me of making the GIMP suck. The suggestions that I offered earlier this evening were only thrown out for consideration, and I didn't try to force those down anyone's throat. All that I asked was that GIMP developers try to give adequate consideration to the needs of Windows based gimp users rather than selecting an implementation that I was worried might have an adverse impact. Some bias towards Linux and other Unix based systems is completely understandable and acceptable to everyone. We all appreciate the deficiencies of Windows and its poor record of adhering to standards (though there are *many* similar examples in the *nix world as well). We also appreciate that the Linux community is making the biggest share of contributions to the GIMP development effort. What I don't appreciate, is your apparent lack of sympathy towards users who have *no* choice but to run under Windows (for any of numerous reasons) and who simply desire to use the gimp (just as you claim to), and to help enhance it to meet *their* needs, just as you enhance it to meet your own needs under Linux. The gimp is an open source product, and is also supported and developed by Windows users, not just *nix heads. So what gives you the right to presume that only *nix developers can own and control the GIMP (as your comments seem to imply), and to ignore the needs of Windows based users and the feedback and proposals of Windows based contributors? Your statements seem to imply that any user or organization who doesn't like the lack of certain GIMP features under Windows can just switch right over to Linux at a moments notice, and that simply is NOT the case in many situations. For example, in our own situation, we use several extremely complex, industry specific technical applications that simply do not exist for Linux. Other programs that we use do have Linux counterparts, but would require numerous man years of retraining, redevelopment of supporting applications, and data conversion in order to switch over, and many are *very* expensive applications that are *not* public domain, even under Linux, which we cannot afford to replace. Also, we can't afford a bunch of duplicate hardware to run both operating systems in parallel, nor can our work flows stand the wasted time of constantly rebooting to switch between applications running under the different operating systems. From an ideological standpoint, we would *love* to switch to Linux, immediately!!! From a practicality and expense standpoint, we just can't do it, and there are many other folks in exactly the same boat. To presume otherwise is to assume that you know everyone else's business better than they do, and I guarantee that you do NOT. Our view seems to be quite different from yours. We believe that Windows based GIMP users should be able to make contributions (which BTW include comments and suggestions) that allow the gimp to work as effectively for us under Windows as it does for other folks under Linux, and *of course* at the same time not to do anything that would adversely impact Linux users. Apparently there are lots of other gimp users and contributors who feel the same way as we do. What doesn't seem right is that *some* Linux based developers don't seem to have any problem implementing features in such a way that it precludes effective use under Windows when it doesn't need to, or reject proposed development efforts by others that would benefit Windows users simply because there is no perceived benefit to the *nix community. I'm not saying at all that has happened in this specific instance regarding the issues that I raised earlier this evening and the subsequent discussion. What I am saying Carol, is that some of you appear to be having a rather knee jerk reaction against someone else who is merely trying to help the GIMP better support the operating system that they are using, no different than anyone else who might happen to be using some other OS. If the approach that I suggested won't work or will cause real problems under another OS,
Re: PDB named and default parameters (was Re: [Gimp-developer] TheMark Shuttleworth offer)
Please see below... - Original Message - From: Carol Spears [EMAIL PROTECTED] To: Kevin Myers [EMAIL PROTECTED]; GIMPDev [EMAIL PROTECTED] Sent: Friday, March 19, 2004 11:34 PM Subject: Re: PDB named and default parameters (was Re: [Gimp-developer] TheMark Shuttleworth offer) On Fri, Mar 19, 2004 at 10:11:53PM -0600, Kevin Myers wrote: Hmmm, I wonder why using the --batch option wasn't suggested when I ran into the problems that I mentioned previously... i was part of this discussion. you were given honest answers from the linux people developing TheGIMP. Absolutely. I never questioned that, and I appreciated the help. That doesn't mean that there might not be some room for improvement of gimp command line handling under Windows. we all use Image Magick to do batch processing. And so do we, *when possible*. In this case, and in many others with the extremely large images that we work with, that was *not* a possibility. The manpages are some of the best written and the convert, mogrify and other image magick commands usually come with every linux distribution. As mentioned previously, we are also IM and GM users. Yes, those are excellent applications, and the developers of those products have been very helpful and extremely considerate of the needs of Windows users. Those applications, while excellent for many purposes, and getting better all the time, would *not* handle our needs in this specific case, while a GIMP script would, if it could have been properly executed from the command line. if i need more than Image Magick can do, i write python scripts. Well, that's fine for you. You know python. We don't. And though I try to make a few contributions to the GIMP when I can, I have a full time job, and simply don't have enough time to constantly be developing stuff, reporting bugs, and suggesting fixes all of the time, just like many of the other minor contributors. All of the gimp scripts have a browser which should avoid any problems that a GIMP User on Windows(TM) should have. That's assuming that it is one of the built-in scripts. This was a script of *my own* development, which unfortunately could not be used due to the scheme argument handling problems from the gimp command line under Windows. also, if you really like to use the command line, why ever are you using Windows? Thoroughly explained in my previous email. You're assuming that everyone else's needs and situations are the same as your own, and they are *not*. Unfortunately, it has been so long ago now that I don't remember the details. I gave up trying after a couple of days of trial and error plus a number of related emails. I can't think of any reason at this point why that wouldn't have been a reasonable solution. As Tor's email reminded me, this option didn't work under Windows, so that's why I couldn't use it. i have a complaint about the way emails are being formated on what should be a repectable mail list. i am sending it in a different email. carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] again: burn function - how does it work?
Thomas Lübking wrote:
Hi.
After checking the i18n files i now know that nachbelichten is supposed to
be burn.
However, the appropriate function in app/coposite-generic.c does not seem to
behave as expected.
afaik the burn function should do nothing if the the upper (the burning) color
is white.
also a black pixel of the lower layer should remain black - whatever the upper
layer is colored.
However, this function:
while (length--)
{
for (b = 0; b alpha; b++)
{
tmp = (255 - src1[b]) 8;
tmp /= src2[b] + 1;
dest[b] = (guchar) CLAMP(255 - tmp, 0, 255);
}
if (has_alpha1 has_alpha2)
dest[alpha] = MIN(src1[alpha], src2[alpha]);
else if (has_alpha2)
dest[alpha] = src2[alpha];
src1 += bytes1;
src2 += bytes2;
dest += bytes2;
}
cannot provide this.
(e.g. upper (src1) is white (255) - tmp = 0 8 = 0; = 0 / ? + 1 = 0;
CLAMP(255 - 0, 0, 255) = 255 = white - so white will flatten anything instead
of leaving it as it is.
as a consequence, black won't remain, as soon as one of the components r,g,b =
255.
i tried to weight the effect (255-0)/255*burn + (1-(255-0)/255)*original...
but the result wasn't like what i expected.
Ok. First off you need to realize that your constants (8, 255, 0, 1)
are all integers (since they don't have a type specification after
them). Also tmp is an int. This means the chars get promoted and are
not doing 8 bit math: we are doing at least 32 bit math. This means
that 255 8 is not 0, but 65280. This also means that a black second
layer stays black and a white first layer leaves the original pixel
untouched.
Second, lets do our math in normalized RGB space so that RGB vary from
(0,0,0) (black) to (1,1,1). Lets convert the above equation to
normalized space.
tmp = (255 - src1) 8 / (src2 + 1).
dest = CLAMP (255 - tmp).
IF you want to convert to normalized form, you divide src1 by 255. Lets
call that src1'. Derive src2', tmp' and dest' in the same way. Then,
turning the bit shift into a multiply, and ignoring the clamp for a moment:
tmp' * 255 = (255 - 255 * src1') * 256 / (src2' * 255 + 1)
dest' * 255 = 255 - tmp' * 255
Factoring out 255 everywhere gives us:
tmp' = (1 - src1') * 256 /((src2' + 1/255) * 255)
dest' = 1 - tmp'
or
tmp' = (1 - src1')/(src2' + 1/255) * (256 / 255).
dest' = 1 - tmp'
I am sure that the original formula assumes 1/255 is aprox. 0 and
256/255 is 1 (since this saves a multiply, and prevents 1/src2 from
being evaluated as zero).
thus, the original formula, in normalized RGB space is:
tmp' = (1 - src1')/(src2')
dest' = 1 - tmp'
or
dest' = 1 - (1-src1')/(src2')
Also, with the condition that if src2' = 0, dest' = 0;
This is much more sane.
Now for the theory of burning.
Burning is a term from photography (the chemical and paper kind). A
burn is when you expose a portion of the paper beyond the normal
exposure time. Let me derive the formula of a real, physical exposure burn.
The aparent change in darkness of a photo as you add more light is of a
is propotional amount of light, exposure (Intensity * time), and the
current darkness of the photo. Lets make a simplification from the
begining. There is an inversion here. Bright light is a dark spot on
the photo, and dim light is a light spot on the photo, so we are going
to reverse our lights levels, so that we are referring to the
corresponding shade the light will produce on the photo. This forces
all discussion to happen in the photo colorspace. Lets call the
original photo brigness p, the new photo brightness p', and the inverted
exposure be I times delta t. The formula for the differential change in
brightness is thus:
- delta p = p * I * delta t;
Which is, once solve in closed form, an exponential decay. Exactly what
I would expect. At the very least, it is obvious that the above
equation qualitatily reflects the properties of an exponential exposure
time, assuming that a single interation represents some fixed (short)
extra exporsure time. I am not sure if this represents an actual
approximation. I don't acutally have any source material for burn,
except for the knowledge of want the process is.
On a related noted, I notice that a brush in burn mode won't burn white,
no matter how hard I try. That doesn't seem correct to me. Shouldn't a
burn darker a white area (it will darken everything up to 255)? Also,
same for dodge and black. Shouldn't a dodge lighten a black area?
--
Daniel
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
