Re: Lists, Arrays and Vectors [was Re: [Gimp-developer] Re: Tiny-Fu: A new plug-in for GIMP]
At 01:38 PM 07/09/2004, you wrote: Now since there is essentially a one-to-one correspondence between Tiny-Fu's vectors and Script-Fu's "arrays", it might be worth considering adding compatibility definitions to "init.scm" (similar to gimpcompat.h for plug-ins), that would, depending on a certain "compatibility"-switch in a configuration file (or in "init.scm" itself, but I don't know if every user will get a copy or you will install the file in /usr/gimpsomething...), "define " the current array operations and map them to corresponding vector functions. You could then (depending on said switch) also re-define set! to use "define" if a variable is not "defined?". I don't really want a "compatibility"-switch. Instead, old Script-Fu scripts should be updated so they do things the way they are supposed to be done in Scheme rather than how the old SIOD interpreter let script writers get away with some things (ie. not defining variables). It forces a review of the code. For example, I noticed that one script defined an internal routine to compute a least common multiple rather. I deleted the routine and used the standard Scheme routine 'lcm'. I am planning on putting together a Perl script that will take a Script-Fu script and update as much of it as possible for use with Tiny-Fu. I know of quite a few mappings from SIOD to TinyScheme that can be applied. Pre-defining variables and changing while loops to do loops will still have to be done by hand. Cheers! Kevin. (http://www.interlog.com/~kcozens/) Owner of Elecraft K2 #2172|"What are we going to do today, Borg?" E-mail:kcozens at interlog dot com|"Same thing we always do, Pinkutus: Packet:[EMAIL PROTECTED]| Try to assimilate the world!" #include| -Pinkutus & the Borg ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] rearranging Xtns Menu
On Sat, Jul 10, 2004 at 12:43:47AM +0200, Sven Neumann wrote: > Carol Spears <[EMAIL PROTECTED]> writes: > > > so the link to the documentation should go directly to whatever > > scripting documentation came with the gimp. > > Is there any? And how would gimp know where it is installed? > i have read some documentation. it is on web sites more stable than our own. > > bookmarks go to online sources of information. > > For reasons I outlined already, bookmarks should be kept on the > gimp.org web-site. > and i am certain that roman read this opinion and asked his question anyways. > IMHO we shouldn't add more Help entries to the menus. There should be > continue to be a single Help entry to get you to gimp-help. If people > need help for a particular plug-in, the F1 key should get them there > quickly. The help pages for the scripting languages can then point to > a collection of links that is maintained on www.gimp.org. > what does H stand for again? these links are more maintained that any gimp site ever. carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] rearranging Xtns Menu
Hi, Carol Spears <[EMAIL PROTECTED]> writes: > so the link to the documentation should go directly to whatever > scripting documentation came with the gimp. Is there any? And how would gimp know where it is installed? > bookmarks go to online sources of information. For reasons I outlined already, bookmarks should be kept on the gimp.org web-site. IMHO we shouldn't add more Help entries to the menus. There should be continue to be a single Help entry to get you to gimp-help. If people need help for a particular plug-in, the F1 key should get them there quickly. The help pages for the scripting languages can then point to a collection of links that is maintained on www.gimp.org. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] rearranging Xtns Menu
hello Roman, On Fri, Jul 09, 2004 at 02:03:26PM +0200, Roman Joost wrote: > On Tue, Jul 06, 2004 at 08:47:14AM -0700, Carol Spears wrote: > > the bug report suggests this rearrangement of the Xtns menu (which is a > > huge mess if you install all of the difference scripting options that > > the linux gimp has): > > > > The New Structure /Xtns/: > > > > Module Manager > > DB Browser > > Plugin Details > > Unit Editor > > * Perl --> > > Browser > > Console > > Server > > > > * Help --> > > * Documentation --> > > * Bookmarks --> > Correct me if I'm wrong, but do you refer here to the normal Help which > is now in /Help? If not, should the help entry only cover > documentation for the plugins or what is the help thingy doing there? > i thought it would be nice to have everything one might need while scripting all in one place in the menu. so the link to the documentation should go directly to whatever scripting documentation came with the gimp. bookmarks go to online sources of information. i hope this clears things up. what do you think of the idea? carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
It really isn't all that complicated. Here is all you need to do (this is basically what Sven outlined with a couple of extra details.) 1) Gimp uses the same color space internally for all images. This could be either sRGB or a user-selected one (in which case it is specified by a preference). 2) Gimp permits the use of a monitor profile to color-correct the display. A conversion is done between the working colorspace and the monitor colorspace -- the user is asked to choose the intent of the conversion as a preference (the normal choice would be "perceptual", but people setting things up for printing would sometimes make other choices). 3) When you open an image, if it does not have any color profile info, it is assumed to be in Gimp's working colorspace. If it does, then you are asked to choose between two options: a) convert it to Gimp's working colorspace. If you choose this, then you are asked to choose the conversion intent. b) use the RGB values from the image, without any correction. Whatever is done, a parasite is attached to the image describing it. 4) When you save an image, you have the option of converting it to a different colorspace and/or attaching a color profile if the file format supports it. It is a bad idea to change the working colorspace based on the image. Users need to be able to form an understanding of the relationship between what they see on the screen and the pixel values in the image. It will drive people nuts if 255,255,255 looks gray at one time and white at another. That's what will happen if the working colorspace is flopping around all the time. Best, -- Bill __ __ __ __ Sent via the KillerWebMail system at primate.ucdavis.edu ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
Hi Dave, David Neary wrote: So say I open an image with a color profile, and then load a second image with a different profile. If I now decide to do the above, what do we do to the first image? 1) We stop using the profile for the first image (and if the image window is open, this will obviously change the visual representation of the image), but keep it attached to the image so that we can re-save it with the image at save time I think this is the best bet - disable the colour-management filter for any images that don't use the current working profile. 2) We stop using the profile and propose the dialog with the 4 options the next time the image is activated (basically allowing us to change the working colorspace on demand, but this could get annoying, I guess) The easiest option is to provide a simple plugin that adds a couple of menu entries - for example: Image -> Colour Management -> Convert to working profile and Image -> Colour Management -> Use as working profile That sounds sane. I'm not quite sure how it would be implemented, but it probably involves having a color profile parasite attached to an image, with some kind of configuration parameter for the working colorspace and the monitor profile. I'm not 100% sure, but I think the TIFF plugin already attaches embedded profiles as a parasite, so they're preserved when the image is saved again. If so, we have a lead to follow! All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
Hi, Sven Neumann wrote: > David Neary <[EMAIL PROTECTED]> writes: > > 1) We stop using the profile for the first image (and if the > > image window is open, this will obviously change the visual > > representation of the image), but keep it attached to the image > > so that we can re-save it with the image at save time > > That doesn't sound feasible to implement. How would the other image > get notified about this change? There isn't any notification about > parasite changes. Yeah - fair point. The changing colorspace has to get taken into account next time we activate the image, then - and we're back to option 2. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
Hi, David Neary <[EMAIL PROTECTED]> writes: > So say I open an image with a color profile, and then load a > second image with a different profile. If I now decide to do the > above, what do we do to the first image? > > 1) We stop using the profile for the first image (and if the > image window is open, this will obviously change the visual > representation of the image), but keep it attached to the image > so that we can re-save it with the image at save time That doesn't sound feasible to implement. How would the other image get notified about this change? There isn't any notification about parasite changes. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
Hi Alastair, Alastair M. Robinson wrote: > Given the limitations we're trying to work within, I think the best > compromise is likely to be something like this: > - Change the GIMP's working profile to match this image. This will > leave the image data untouched. (This should disable the display filter > for existing images, since they are presumably using a different profile.) So say I open an image with a color profile, and then load a second image with a different profile. If I now decide to do the above, what do we do to the first image? 1) We stop using the profile for the first image (and if the image window is open, this will obviously change the visual representation of the image), but keep it attached to the image so that we can re-save it with the image at save time 2) We stop using the profile and propose the dialog with the 4 options the next time the image is activated (basically allowing us to change the working colorspace on demand, but this could get annoying, I guess) 3) Something else I hadn't thought of? > - the user just needs to be made aware that colour-space transformations > are a destructive change, and have an opportunity to avoid them. That sounds sane. I'm not quite sure how it would be implemented, but it probably involves having a color profile parasite attached to an image, with some kind of configuration parameter for the working colorspace and the monitor profile. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
Hi Sven, Sven Neumann wrote: Well, it got to be doable in the file plug-ins since we don't want to have the core depend on lcms. Applying the embedded profile at load time could very well happen in the file plug-ins though. If the core needs to perform colorspace transformations then we should postpone this whole thing and do it properly with GEGL. Given the limitations we're trying to work within, I think the best compromise is likely to be something like this: - GIMP uses a user-selectable working profile. - If a user loads an image tagged with a different profile, she is presented with the following options: - Convert from the image's profile to the working profile, and accept the degredation that will result. - Change the GIMP's working profile to match this image. This will leave the image data untouched. (This should disable the display filter for existing images, since they are presumably using a different profile.) - Load the image without colour management, disabling the display filter for this image. - If a use loads an image with no profile, the display filter should be disabled. - A simple plugin should be available to fill in the gaps, i.e. tagging an image with a specific profile (for images with no profile), or converting an image to the current working space if it has changed. For the majority of users, this should suffice; I suspect compositing images with different profiles won't be a particularly common occurrence - the user just needs to be made aware that colour-space transformations are a destructive change, and have an opportunity to avoid them. All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
Hi David, David Neary wrote: I'll conduct some tests some time and try and figure out just how bad these quantisation errors could be. Great - quantitative data will really help. I've done some testing - I wrote a little program that puts every possible 8-bit RGB colour through an lcms transform. A frequency table is kept of every colour that comes out the other side, which gives us some idea of how many codes are "lost" - how badly the dynamic range is reduced. First, as a control subject, I analyzed the gamma function at 1.1 and 0.6. The results are as follows: Gamma 1.1 Code use tally: 00: 1707993 01: 13481272 02: 1529388 03: 0 04: 57834 05: 0 06: 0 07: 0 08: 729 09: 0 In other words, 13,481,272 colours are mapped with a 1:1 ratio, so can be transformed back again without loss. 1,707,993 colours are missing from the destination set, and just under 1,600,000 colours are arrived at from multiple source colours. Gamma 0.6 Code use tally: 00: 7647887 01: 4251528 02: 3700404 03: 0 04: 1073574 05: 0 06: 0 07: 0 08: 103823 09: 0 Gamma 0.6 is considerably more destructive, only 1/4 of the codes maintain a 1:1 mapping. Now for AdobeRGB <-> sRGB: sRGB -> AdobeRGB1988 Code use tally: 00: 8102616 01: 4172676 02: 3175714 03: 438068 04: 538838 05: 66267 06: 124002 07: 23117 08: 48831 09: 87087 AdobeRGB1988 -> sRGB Code use tally: 00: 8012181 01: 8325155 02: 156167 03: 54498 04: 10468 05: 58725 06: 15054 07: 2108 08: 2129 09: 140731 This isn't as bad as I'd feared, but still considerably worse than either of the gamma tests. In both cases nearly half the codes in 8-bit RGB space are lost! This in effect reduced 24-bit RGB to 23-bit RGB. As I said, this isn't as bad as I'd feared - I was expecting to see a loss of nearly 1-bit per channel; in fact we lose only approximately 1-bit over the whole image. If anyone's curious enough to want the source of my test program, just ask :) All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: Lists, Arrays and Vectors [was Re: [Gimp-developer] Re: Tiny-Fu: A new plug-in for GIMP]
> By using vectors I was able to very quickly update the portion of those > scripts which used SIOD array functions. I have not changed the Tiny-Fu > marshalling code yet but I will do that soon and release a new tarball. Now since there is essentially a one-to-one correspondence between Tiny-Fu's vectors and Script-Fu's "arrays", it might be worth considering adding compatibility definitions to "init.scm" (similar to gimpcompat.h for plug-ins), that would, depending on a certain "compatibility"-switch in a configuration file (or in "init.scm" itself, but I don't know if every user will get a copy or you will install the file in /usr/gimpsomething...), "define " the current array operations and map them to corresponding vector functions. You could then (depending on said switch) also re-define set! to use "define" if a variable is not "defined?". Markus. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] rearranging Xtns Menu
Hi Carol, On Tue, Jul 06, 2004 at 08:47:14AM -0700, Carol Spears wrote: > the bug report suggests this rearrangement of the Xtns menu (which is a > huge mess if you install all of the difference scripting options that > the linux gimp has): > > The New Structure /Xtns/: > > Module Manager > DB Browser > Plugin Details > Unit Editor > * Perl --> > Browser > Console > Server > > * Help --> > * Documentation --> > * Bookmarks --> Correct me if I'm wrong, but do you refer here to the normal Help which is now in /Help? If not, should the help entry only cover documentation for the plugins or what is the help thingy doing there? Cheers, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Gimp-developer] color management
Hi, Dave Neary <[EMAIL PROTECTED]> writes: > > point that we are discussing is how file plug-ins should handle > > embedded color profiles, i.e. whether to attach the profile to the > > image or not. > > I may be listening to a different conversation. The other point was > whether embedded profiles should be applied at load time or be > factored into the projection. In this scheme, the core would have to > be at least aware of color profiles attached to images. It's not > simply a question of attach or apply, since one has implications for > the core, and the other doesn't. So this isn't just about the file > plug-ins. Well, it got to be doable in the file plug-ins since we don't want to have the core depend on lcms. Applying the embedded profile at load time could very well happen in the file plug-ins though. If the core needs to perform colorspace transformations then we should postpone this whole thing and do it properly with GEGL. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
Hi, Quoting Sven Neumann <[EMAIL PROTECTED]>: > All we are discussing here is > whether it makes sense to use display filters to color-correct the > image display (and optionally color selector displays). I don't think there is any argument about that. It does make sense to apply the monitor's profile as the last step in the projection. > The other > point that we are discussing is how file plug-ins should handle > embedded color profiles, i.e. whether to attach the profile to the > image or not. I may be listening to a different conversation. The other point was whether embedded profiles should be applied at load time or be factored into the projection. In this scheme, the core would have to be at least aware of color profiles attached to images. It's not simply a question of attach or apply, since one has implications for the core, and the other doesn't. So this isn't just about the file plug-ins. Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
