Re: [Gimp-developer] Color management: conclusions?
Hi, "Alastair M. Robinson" <[EMAIL PROTECTED]> writes: > Finally, a question: How is a plugin supposed to go about storing > persistent data between sessions (i.e. in my case, the filenames of > the profiles last used)? The plug-in can attach a persistent parasite to gimp. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management: conclusions?
Hi Sven, Sven Neumann wrote: I wrote this in an earlier mail already but perhaps you didn't notice, so here's my question again: Sorry, yes I did miss that... I wonder if we should add the separate plug-in to the GIMP tarball for GIMP 2.2. Would you like to see that happening? I'd be delighted - though there are a few bugs I'd like to fix first! If it's going to become semi-official, though, I guess some discussion is needed about various points: 1. Where in the menus it should live. Currently, my functions are in Image->Separate. The separation is, however, performed on the current layer, not the whole image. The separation functions themselves are really not much more than a colour-profile-aware version of the compose/decompose code that's there already, so maybe alongside those would be the best place. Alternatively, depending on how far we get with colour-management in general, a new top-level Colour Management menu might be a better option? 2. Should the saving function be left with the separation functions, or be moved into the TIFF plugin. 3. How about adding support to the TIFF plugin for loading CMYK images into individual greyscale layers, thus solving the biggest limitation that the separate plugin currently has, i.e. not being able to load its own images back in. (This would have to be an alternative option to converting the CMYK data to RGB using lcms, if we implement that, or using libtiff's own Everything->RGBA converter.) Does anyone else want to bring up any further points? Finally, a question: How is a plugin supposed to go about storing persistent data between sessions (i.e. in my case, the filenames of the profiles last used)? All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] filetype plug-in to get type of entity (file/directory)
Greetings, Markus. At 05:05 PM 07/22/2004, you wrote: I was not aware of all the useful extensions you are incorporating into Tiny-Fu. There are only two extensions for the TinyScheme interpreter I'm using them both since they each add something useful for scripts. I have used the extensions to create a script that creates contact sheets. Just point it at a directory and it will create as many 1024x768 image sheets as are needed to show all images in the directory. Each image sheet will hold up to 36 images each. By the way: I favour the current convention (used throughout GIMP scripts) of parenthesizing [for example, instead of: [example snipped] I write: [example snipped] because it has become the de-facto standard for Scheme (also used in TinyScheme's "init.scm", in Emacs etc.) and it is recommended in all books and tutorials I could find in print and on the web, so apart from the fact that I use this style habitually by now, maybe sticking to it will help both newcomers (being accustomed to the style from the tutorials) and professional Lisp coders (having seen more braces, so to speak) to follow the code. We will have to agree to disagree about the formatting of Scheme code. I would not treat the method used to format code as shown in a book as THE recommended guideline for how code should be formatted. Not unless they come right out and say "thou shalt format thy code thusly". :-) Books format code to save space and paper. I first learned C from K&R and I just copied their style until I became aware of a better way to format my code. I am formatting the Scheme code in a way that befits the language it is. In C, you don't put all the closing braces on one line so I don't see why a script written in Scheme should do the same with the closing parenthesis. I was aware of LISP from some articles in early issues of BYTE magazine. I was never taught LISP or Scheme in any classes. My first experience with Scheme was with the scripts for Script-Fu. I could make some simple changes but sometimes after copying/moving a line or two, I would get problems with loops or complaints about the brackets not matching up. I'm formatting the scripts which come with Tiny-Fu in a way that should make it much easier for someone totally new to Scheme to see and learn the syntax of the language. Something I wish had been done to the scripts I first looked at. To someone who already knows LISP or Scheme the format won't affect them as they already know the basic syntax and placement of brackets. 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] Color management: conclusions?
Hi, David Neary <[EMAIL PROTECTED]> writes: > > I wrote this in an earlier mail already but perhaps you didn't notice, > > so here's my question again: > > > > > I wonder if we should add the separate plug-in to the GIMP tarball > > > for GIMP 2.2. Would you like to see that happening? > > I would. I assumed you were asking Alastair, though. I do, that's why I sent my mail To: "Alastair M. Robinson". Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management: conclusions?
Hi, Sven Neumann wrote: > I wrote this in an earlier mail already but perhaps you didn't notice, > so here's my question again: > > > I wonder if we should add the separate plug-in to the GIMP tarball > > for GIMP 2.2. Would you like to see that happening? I would. I assumed you were asking Alastair, though. Also, I found another color management plug-in for the GIMP (pretty old, and I haven't looked at it in depth yet, but it's someone else who has looked into the issue and might save us some work): http://www.khk.net/color/color_manager.html 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
[Gimp-developer] preparing the 2.0.4 release
Hi, there are two problems that warrant doing a 2.0.4 release soonish. One is a change in glib-2.4.4 that breaks opening files with non-ASCII characters on file-systems which are not in UTF-8 encoding (bug #148484). This will need to be fixed in glib and we expect a glib-2.4.5 release any day now. I guess however that we will also have to do some changes to our code (see bug #148140). The other problem is that I messed up EXIF handling in the JPEG plug-in when I backported a fix from the HEAD branch. See bug #148632 for more details). OK, so while we are on it, we could as well attempt to fix one or two of the other bugs remaining on the 2.0.4 milestone. These are: 123888 PSD images gets wrong "modulo" 128594 Rotating layer more wide than 16000 pixels causes problem on pixel higher than 16000 129867 Sync regex files with latest GNU grep to pull in possible fixes 136713 Select contiguous region in imagemap not fully functional yet. 138103 unable to begin selection from absolute lower right hand corner of image 141977 PDB layer name entry not checked. 142074 Paste into 1x1 pixel image from buffer crashes GIMP 2.01 148140 2.0 does not decode URLs dropped from DFM 148601 Using "Paste from clipboard" causes the layer preview to get corrupted So if you have some spare time, it would be nice if you could help to fix some of these issues. You could also check Bugzilla if there are other bugs in 2.0 that should have the target milestone set and should thus appear in above list. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management: conclusions?
Hi, I wrote this in an earlier mail already but perhaps you didn't notice, so here's my question again: > I wonder if we should add the separate plug-in to the GIMP tarball > for GIMP 2.2. Would you like to see that happening? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
