Re: [Gimp-developer] gimp plugin and gdb?
Joseph Heled wrote: But the real problem is that by the time the plugin dialog is up lots of interesting stuff has already happened. So, how can I debug run() itself in a reasonable way? (I can think of several ugly hacks to make run() stop and wait until I attach to it, but I still hope there is something I overlooked and there is a simple solution for that). Please read http://developer.gimp.org/debug-plug-ins.txt . This file is also contained in the devel-docs/ directory in the source tree. Philip ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp plugin and gdb?
On Fri, Jul 23, 2004 at 06:15:03PM +1200, Joseph Heled wrote: > > While starting each plugin as a separate process has it's advantages, gdb > interaction is certainly not one of them. > > For example, right now I bring the plugin dialog up, then look up in the > process list for it, and attach it to the gdb session. Is there an easier > way? > > But the real problem is that by the time the plugin dialog is up lots of > interesting stuff has already happened. So, how can I debug run() itself in > a reasonable way? > > (I can think of several ugly hacks to make run() stop and wait until I > attach to it, but I still hope there is something I overlooked and there is > a simple solution for that). Check out the developer FAQ: http://developer.gimp.org/faq.html#id2778982 So yes, you overlooked some key things. ;) -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] gimp plugin and gdb?
While starting each plugin as a separate process has it's advantages, gdb interaction is certainly not one of them. For example, right now I bring the plugin dialog up, then look up in the process list for it, and attach it to the gdb session. Is there an easier way? But the real problem is that by the time the plugin dialog is up lots of interesting stuff has already happened. So, how can I debug run() itself in a reasonable way? (I can think of several ugly hacks to make run() stop and wait until I attach to it, but I still hope there is something I overlooked and there is a simple solution for that). -Joseph ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] 16 bit Gimp?
(repeat) I am developing a plugin which loads raw images from digital cameras (CRW,NEF etc). There is actually lots of the functionality I need support (and some I need to do) in the gimp already, if only the gimp was 16 bits ready. So, I wonder, any estimate how far in the future it is? -Joseph ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Developing a GIMP plugin (2 questions)
Hi, "javi palau" <[EMAIL PROTECTED]> writes: > Hi, I'm a student who's developing a GIMP plug-in. > I've been reading the API's documents but i haven't found the solution. I strongly suggest you look at some of the plug-ins distributed with GIMP and also get your hands on the gimp-plugin-template [1]. That should answer your questions. Sven [1] http://developer.gimp.org/plug-in-template.html ___ 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: "William Skaggs" <[EMAIL PROTECTED]> writes: So at the most concrete possible level, here is a suggestion on how to start: Step 1: Add a "Color Management" page to the Preferences. Step 2: Add "enable/disable color management" and "working colorspace" options to the page. To start with, sRGB will be the only option for the latter, but the infrastructure should not build in any assumption that this will always be true. GIMP really won't care what this working space is; as far as the core is concerned it's just a filename, so why limit it to sRGB even temporarily? Step 3: In the file-loading code, after an image has been loaded, check for the presence of parasites called either "icc-profile" or "colorspace". If one of these is found, execute the color management plug-in. Step 4: Write a color management plug-in. Sounds good except that Step 4 should be first. Sure, but the plugin will depend on the implementation of the other stages. The guts of the plugin, thanks to lcms, will be pretty trivial - far simpler than the separate plugin; the most important factor will be the design of its user interface, and supporting factors, e.g. do we support tagging images both with an actual profile, or with the filename of a profile, and such like. There are a couple of other issues that might warrant discussion with the developers of lcms; how to go about comparing profiles for equality for instance (we want to be able to avoid converting between an embedded profile and the working space if they are in fact the same profile!) 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: conclusions?
Hi, "William Skaggs" <[EMAIL PROTECTED]> writes: > So at the most concrete possible level, here is a suggestion on > how to start: > > Step 1: Add a "Color Management" page to the Preferences. > > Step 2: Add "enable/disable color management" and "working > colorspace" options to the page. To start with, sRGB will > be the only option for the latter, but the infrastructure > should not build in any assumption that this will always > be true. > > Step 3: In the file-loading code, after an image has been > loaded, check for the presence of parasites called either > "icc-profile" or "colorspace". If one of these is found, > execute the color management plug-in. > > Step 4: Write a color management plug-in. Sounds good except that Step 4 should be first. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] compose - decompose nitpicking
Hi, "William Skaggs" <[EMAIL PROTECTED]> writes: >A) "Compose" would allow you to use any set of equal-sized > grayscale layers to assemble into an RGB layer. (One of > the annoyances of "compose" now is that it only works on > layers that were produced using "decompose".) Huh? At the moment compose doesn't know anything about decompose. Why shouldn't it work on layers not produced by decompose? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A few website ideas
On Sat, Jul 17, 2004 at 01:40:16AM +0200, Niklas Mattisson wrote: > New things: > > * User-FAQ - This needs to be added to the website as soon as possible. > I do not think we have problems with questions but problems with how to > design the FAQ. Yeah - i collected some questions because i thought about a FAQ in the user manual. The website is the better place, so if you want to have my docbook xmlised FAQ ;) > * Documentation - Is needed to provide users and developers with the new > documentation, we also need to have the different languages on the > website. This should be able to be done by using some sort of script or > buildsystem for the documentation. > > Anyone that has any good ideas about how to do this in a really good way > so that we can update it easily? > And so that the languages gets updated also? Maybe be able to update > language by language also? Yosh want to give me an account and i'll put the documentation frequently on this one. This should solve the problem I guess... > Website style: > --- > * Hidding submenus - The menu is starting to grow and it would be good > to make it hide some of the submenus. As soon as you enter the main > section of the link you click on, the submenus will appear. This might > help a little in improving the view also to where you are in the menu. > > This idea also gives us a little problem, the menus need to be named in > a way that is understandable and straightforward to the user. Example: > > Documentation > '-> Tutorials > > Having Documentation as the main section name is not really telling me > that "here you can get a lot of different help" instead it is telling me > that "here you will find some cool documentation". But if we name it: > > Help > |-> Documentation > '-> Tutorials > > It should say that "here you can get some help". Maybe I am > wrong, but > this is some of the things I am looking at right now. Well.. i would assume that the "Help" menupoint gives me help if I'm stuck in the website or need some to know what some words mean. I think Documentation is the better main point. You can then specify which documentation you mean: Documentation |-> Developer |-> User Manual '-> Tutorials (or whatever fits better in the left menu) Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Gimp-developer] Developing a GIMP plugin (2 questions)
On 22.07.2004, at 23:19, Simon Budig wrote: We use the gettext library to determine what language the text in our user interface should be. In fact gettext does all the hard work for us. Not quite but almost. :) The choice of language is expressed by setting environment variables. Those are picked up by the i18n environment which is hosted either by the libc or in a on some systems in freestanding library called libintl. What is called gettext is on one hand the library call which will do the translation[1] and on the other hand a set of userland tools[2] to extract strings from the sourcecode, convert human readable text into machine optimized binary form and do other manipulations on catalogs. [1] iff the language is set, differs from the default English and a catalog in one of the choosen languages with a matching translation string is available [2] also the name of one particular tool within the set Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [Gimp-developer] Selecting new constants for '(file-type file)'?
On Thu, 2004-07-22 at 17:17, Markus Triska wrote: > Maybe I have not given this enough thought, but I would opt for > FILE_TYPE_NONEXISTANT (although this can hardly be called a "file" type) so > there is some well-defined behaviour if the path to check points nowhere. I have decided to use FILE_TYPE_UNKNOWN as the default value if the other checks fail. This handles situations where the file might be (for example) a node, or the user doesn't have the permissions necessary to access the file. I just have to double check I have documented this in the function list for tsx. -- 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] Developing a GIMP plugin (2 questions)
javi palau ([EMAIL PROTECTED]) wrote: > 2ºHow i can know the language used by GIMP?. I've been searching in the > "gimprc" file, but i haven't found anything. We use the gettext library to determine what language the text in our user interface should be. In fact gettext does all the hard work for us. You can also use it for your plugin and you'll automatically have the same language as the rest of the GIMP. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Selecting new constants for '(file-type file)'?
> I want to define some constants related to file type for use in Tiny-Fu. My
> current thinking is to use FILE_TYPE_FILE (0), FILE_TYPE_DIR (1), and
> FILE_TYPE_LINK (2). The last one being for *nix systems only. Are
> there any other file types that should be handled (ie. nodes on *nix
> systems)?
Maybe I have not given this enough thought, but I would opt for
FILE_TYPE_NONEXISTANT (although this can hardly be called a "file" type) so
there is some well-defined behaviour if the path to check points nowhere.
Also, what happens with access permissions ("not readable")? The call should
be well-defined in this case, too, so maybe (to cover both cases), there
should be some "FILE_TYPE_ERROR" and other predicates to check for
existence/permission.
Markus.
___
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)
On Wednesday 21 July 2004 08:07 pm, Kevin Cozens wrote: > This is just a taste of the possibilities for scripting in GIMP using > Scheme based scripts with Tiny-Fu. What would you like to do today? :-) Thank you for your explanation, Kevin. I was not aware of all the useful extensions you are incorporating into Tiny-Fu. I'm really looking forward to seeing (and implementing?) many scripts that will then become easy and, most of all, possible (it is now only a matter of time until someone implements all the functionality of GIMP in some Scheme script, oh wait - that's Emacs already). By the way: I favour the current convention (used throughout GIMP scripts) of parenthesizing [for example, instead of: (let* ( (dir-stream (open-dir-stream dir)) (file) ) (mycode) ) I write: (let* ((dir-stream (open-dir-stream dir)) (file)) (mycode)) ] 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. It also saves many lines containing only ")" and thereby allows to grasp more code at once. Maybe you also find it advantageous (or even, more beautiful?) if you try it some day (well, it can't hurt to try both for some time and see which one is more appealing). Markus. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Developing a GIMP plugin (2 questions)
Hi Javi, javi palau wrote: > Two questions: > 1º When i execute my plug-in for 2nd time, i'd like to configure the > parameters like the user introduce the first time. Is there any "gimp > memory" to save the values introduced by the user? You can tell when a plug-in is re-run by testing the run mode (parameter 0 of the input parameters of every plug-in). If it is GIMP_RUN_WITH_LAST_VALS, the plug-in has been run with that menu item, if it's run GIMP_RUN_INTERRACTIVE it has been run through a menu entry. The usual way that you get back last used values is to call gimp_set_data(plug_in_name, pointer_to_option_struct, sizeof(option_struct)); So the first thing that you can do after starting the plug-in is to call gimp_get_data(plug_in_name, pointer_to_option_struct); > 2ºHow i can know the language used by GIMP?. I've been searching in the > "gimprc" file, but i haven't found anything. The GIMP is written in C, primarily, but you can write plug-ins in any language which wraps libgimp (if it wraps gtk+ as well, all the better). That currently includes perl, python and scheme (script-fu), but there is no reason not to have others. The gimprc file format is a readable serialisation of internal configuration stuff, I don't think you could call it a language. 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] Developing a GIMP plugin (2 questions)
Hi, I'm a student who's developing a GIMP plug-in. I've been reading the API's documents but i haven't found the solution. Two questions: 1º When i execute my plug-in for 2nd time, i'd like to configure the parameters like the user introduce the first time. Is there any "gimp memory" to save the values introduced by the user? 2ºHow i can know the language used by GIMP?. I've been searching in the "gimprc" file, but i haven't found anything. Thanks a lot. PD: Forgive me for my english. ;P _ Descarga gratis la Barra de Herramientas de MSN http://www.msn.es/usuario/busqueda/barra?XAPID=2031&DI=1055&SU=http%3A//www.hotmail.com&HL=LINKTAG1OPENINGTEXT_MSNBH ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Howto: store comments in image from plugin?
Joseph Heled writes: > It turned out to be as simple as attaching a "gimp-comment" and > "jpeg-exif-data" parasites to the image. Note that in Gimp 2.1 the exif data parasite has been renamed "exif-data", because it is not specific to jpeg files. 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] Selecting new constants for '(file-type file)'?
FYI, Windows 2000 and XP both (partially) support variaties of hard and symbolic links under NTFS in certain scenarios. Then of course there are also the half-ass implemented Windows shortcut files (*.lnk). Finally, software also exists that allows Windows to access a *nix based file system where regular *nix style links might exist. Depending on your exact needs and purposes, I just thought those might be worth mentioning. Don't believe these impact your constants at all, but would hate to see link support omitted for Windows if only due to lack of familiarity with these features. s/KAM - Original Message - From: "Kevin Cozens" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, July 21, 2004 3:10 PM Subject: [Gimp-developer] Selecting new constants for '(file-type file)'? > Greetings, all. > > I want to define some constants related to file type for use in Tiny-Fu. My > current thinking is to use FILE_TYPE_FILE (0), FILE_TYPE_DIR (1), and > FILE_TYPE_LINK (2). The last one being for *nix systems only. Are > there any other file types that should be handled (ie. nodes on *nix systems)? > > Comments? > > 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 > ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] OT: noise equivalence in HSV components
Joseph Heled writes: > How (or can you) combine errors/noise in HSV into one error/noise > figure which reflects the total "human visual" error perception. HSV is the wrong colorspace to use for this purpose. The LA*B* colorspace was designed to do what you are trying to accomplish: supposedly, equal distances in LA*B* coordinate space correspond to equal distances in human perceptual space -- although I understand that there is debate about whether this is really true. (Of course, you have to be careful about what you are trying to do. If you shift an entire image one pixel to the right, it will probably look identical to a human although it may be quite different on a pixel-for-pixel basis. In general, integrating pixel-by-pixel color differences will not give you a very accurate picture of how much difference people perceive between two images.) The "decompose" plug-in in Gimp will decompose an image into LAB coordinates -- however, I looked at the source code recently in connection with a bug report (bug #147603), and it seems that the LA*B* algorithm is not correctly implemented by the plug-in, so you should be cautious in using it for anything important. 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] photoshop like variations Gimp plugin proposal
Hi, I don't understand what you want... GIMP's "Filter Pack" plug-in is apparently the same as photoshop's "Variations"... What exactly do you miss? ciao, --mitch khiraly <[EMAIL PROTECTED]> writes: > Im wondering, how powerfull is the plugin variations from photoshop. > Its really usefull for face drawing. (My friend have showed it to me. > And equally I have a video tutorial of this) > How its accessible from the menu: > http://www.pvvbitech.hu/fotok/variationMenu.png > How it is look like: > http://www.pvvbitech.hu/fotok/variationMain.png > > I have searching something similare in the Gimp, > I have found a plugin what have similar interface: > Filters->colors->filter pack > > I have created a test image: > http://www.pvvbitech.hu/fotok/variationDebug.png > I have launched the variation plugin, and clicked only at the 'More > Yellow' thumbnail. > Here is the sequence of this: > http://www.pvvbitech.hu/fotok/variationYellow1.png > http://www.pvvbitech.hu/fotok/variationYellow2.png > ... > http://www.pvvbitech.hu/fotok/variationYellow9.png > And the first 'more green' result: > http://www.pvvbitech.hu/fotok/variationGreen1.png > > The plugin operate with the layer effect in mode 'color'.(I suppose) > I have followed the 'More yellow' process. > (the variationYellow images) > The process of gray color: > On the original picture: > R: 65%, G:65%, B:65% (a7a7a7) > 1. step (More Yellow) > R: 68%, G:76%, B:47% (aec279) > 2. step > R: 73%, G:85%, B:19% (bbd930) > 3. step > R: 80%, G:85%, B:9% (cdda18) > 4. step > R: 90%, G:95%, B:0% (e6f200) > 5. step > R: 96%, G:98%, B:0% (f4fb00) > 6. step > R: 98%, G:99%, B:0% (fafd00) > 7. step > R: 99%, G:100%, B:0% (fdfe00) > 8. step > R: 100%, G:100%, B:0% (fefe00) > > I have written this in hope, perhaps if somebody is interessing of > writing this usefull plugin. What can I contribute? I can take many > photoshop's screenshot, and I can contribute results of test images. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] new gimp-based app?
Hello all, Short version: I am looking for a very simple utility for annotating graphics. I can't find anything suitable so I may have to make one. I think a sub-set of the Gimp might work. If there are any persons who would be interested in discussing this I would like to hear from you. Long version: I make my living as a mechanical designer and my job involves a lot of passing drawings back and forth. We have gotten pretty good about computerized text files but pictures and drawings are a problem. Usually the best I can do is make a png or a gif of a screen shot. Then the recipient can telephone me and we can try to verbally describe changes etc. Or they can print out a copy of my screen shot, draw circles and arrows on it and fax that back to me. Or scan the marked-up hard copy and email the result. Or jump in the car and drive over or carrier pigeon, mule train, etc. What we have needed for a long time is a very simple application that can take any kind of graphical data: png, gif, jpeg, xdm, tif, powerpoint, excel, whatever, annotate it and sent the annotated version back to the originator. NB I am not kidding about excel-I often receive elaborate graphics made from spreadsheets. This application has to be very very simple if it is going to be useful. The gimp may already be able to do all the above but there is exactly zero probability that the marketing and engineering types that will have to use this are going to fool with anything that takes more than ten minutes to learn. I see this as browser-based because everyone has a browser today. Able to grab anything that can appear on the user's computer screen. The user could draw lines, circles, boxes and text on the image and save the result in a format that is easy to email. I would give the user a choice of red ,yellow, green, blue, black and white lines and two line weights-period. I do not anticipate supporting a fill mode for circles and boxes. Tif files are a tough call. They are the default format for large engineering drawings. It would be very nice to be able to mark these drawings up and return them to the originator. I am not sure that the benefit would outweigh the added complexity. In this case simple is good, very simple is very good and very very simple is very very good. A versioning system that was transparent to the user might be worth it. That is, an audit trail that showed: This is my original, this is the markup of the original, this is my corrected version, this is the markup of corrected version1 .. this is the final approved version. OK, that's it. That's what I need. I'm thinking that a very stripped down version of the gimp might do the job. Agree? Disagree? Dumbest idea you've ever heard? Does what I need already exist? Suggestions? Thanks, Dave Driscoll ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] compose - decompose nitpicking
On 21 Jul 2004, Sven Neumann wrote: > Dave Neary <[EMAIL PROTECTED]> writes: > > I think it would be even more useful to set the compose mode to the > > last used decompose mode, rather than the last used compose mode (if > > you get my meaning). > > Well, this is doable but it would require closer interaction between > the two plug-ins. compose could read the last-used-parameters set by > decompose. A prerequisite for this would be to let the two plug-ins > share a common header. Why not put a parasite on the images created by decompose saying what mode the image was decomposed with, and which layers (or images, depending on the options when you decomposed) corrispond to which channels? Then there would be no need for guessing, and you could work with more than one decomposed image (or layer, for that matter) at once. You would still want to allow the user to switch to some other layer for the recompose, of course, but it would be nice to default to the way it was decomposed. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] removing gimp toys, second opinion please?
> > If you still reject the idea I would ask you to keep the toys in mind when > > it comes to menu reorganisation. (Wiki is still down otherwise I'd add > > this to the menu reorganisation document we had there). > > The Gnome HIG recommends: > > > > http://developer.gnome.org/projects/gup/hig/1.0/menus.html#menu-type-submenu > > Do not create submenus with fewer than three items, unless the items are > > added dynamically (for example the File->New Tab submenu in gnome-terminal). > > Looks as if we need a third Toy then. Any volunteers? Putting them somewhere else in the menus would be easier. (Misc? Distort?) - Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] OT: noise equivalence in HSV components
This is not a gimp question, but perhaps there is someone here who can shed light on this issue, How (or can you) combine errors/noise in HSV into one error/noise figure which reflects the total "human visual" error perception. I am sure this is not a good formulation of the question. Here is another way to put it, Take a picture I. Decompose to HSV. Now add noise Nh to H and recompose to get image I(h). Do the same for Ns to S and Nv to V. Now, what should the relation be between Nh,Ns,Nv so that a human would say "All three images I(h). I(s) and I(v) look like they had the same amount of corruption relative to the original I. Now I am not necessarily asking for a rigorous answer. Any reasonable heuristic would do. -Joseph ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] compose - decompose nitpicking
Here is what I would do, and it wouldn't be very hard to code up: 1) Make decompose attach a parasite called "decompose-info" to each layer it produces, specifying the type of decomposition and listing the source layer and the layers that are created. 2) Split compose into two PDB functions, called "compose" and "recompose". A) "Compose" would allow you to use any set of equal-sized grayscale layers to assemble into an RGB layer. (One of the annoyances of "compose" now is that it only works on layers that were produced using "decompose".) B) "Recompose" would look for a "decompose-info" parasite in the active layer. Not finding one, it would pop an error message and exit. Finding one, it would use the information there to assemble an RGB layer, and substitute the result for the layer that was originally decomposed. This could all happen automatically, without popping a dialog. 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: conclusions?
So at the most concrete possible level, here is a suggestion on how to start: Step 1: Add a "Color Management" page to the Preferences. Step 2: Add "enable/disable color management" and "working colorspace" options to the page. To start with, sRGB will be the only option for the latter, but the infrastructure should not build in any assumption that this will always be true. Step 3: In the file-loading code, after an image has been loaded, check for the presence of parasites called either "icc-profile" or "colorspace". If one of these is found, execute the color management plug-in. Step 4: Write a color management plug-in. 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] removing gimp toys, second opinion please?
On Wed, 21 Jul 2004, Alan Horkan wrote: > > http://bugzilla.gnome.org/show_bug.cgi?id=148027 > > Given that some less used file formats have been removed in recently > releases on the basis of less code to maintain and less general clutter I > suggested that the old Toys be removed from the Gimp for version 2.2. To > my surprise Mitch rejected the idea (without much explanation), Adam who > wrote the toys didn't seem to think it was a terrible idea so I'm asking > onlist to try and get a second opinion. If Excel had a flight simulator, Gimp can have a few toys. :) > If toys like Gee-Zoom were built on top of a useful plugin (eg some sort > of a kaleidescope plugin for example) I wouldn't even be asking but they > toy are not useful at all sso users are just presented with eye-candy and > left wondering how they can get that effect on their actual image but they > cannot. I guess it wouldn't be impossible to have Gee-Zoom render individual frames as layers, but that ignores the real question, which is why we don't have some cool effect like gee-slime on the splash screen. > If you still reject the idea I would ask you to keep the toys in mind when > it comes to menu reorganisation. (Wiki is still down otherwise I'd add > this to the menu reorganisation document we had there). > The Gnome HIG recommends: > http://developer.gnome.org/projects/gup/hig/1.0/menus.html#menu-type-submenu > Do not create submenus with fewer than three items, unless the items are > added dynamically (for example the File->New Tab submenu in > gnome-terminal). Fortunately, this is only a recommendation. Since the toys are rarely used, I think the uniformity of the Filters menu having just submenus and the usefullness of having the Toys being explicitly labeled as such is better overall. If we broke out all the menus that have only two items, I don't think the menu would fit on the screen. :) Besides, the best solution is to add another toy. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] compose - decompose nitpicking
On Wednesday 21 July 2004 09:20 pm, you wrote: > For a start, I'm attaching a patch that makes "compose" use the layers in > reverse order (if the image has more than MIN_COMPOSE_LAYERS = 3 layers, > otherwise use old behavior). No attempt is currently made to guess the > mode. Sorry, should read "...has *at least* MIN_COMPOSE_LAYERS = 3 layers". This solution is not perfect either, but arguably not worse than before, and in many cases much better. Markus. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] photoshop like variations Gimp plugin proposal
Hi! Im wondering, how powerfull is the plugin variations from photoshop. Its really usefull for face drawing. (My friend have showed it to me. And equally I have a video tutorial of this) How its accessible from the menu: http://www.pvvbitech.hu/fotok/variationMenu.png How it is look like: http://www.pvvbitech.hu/fotok/variationMain.png I have searching something similare in the Gimp, I have found a plugin what have similar interface: Filters->colors->filter pack I have created a test image: http://www.pvvbitech.hu/fotok/variationDebug.png I have launched the variation plugin, and clicked only at the 'More Yellow' thumbnail. Here is the sequence of this: http://www.pvvbitech.hu/fotok/variationYellow1.png http://www.pvvbitech.hu/fotok/variationYellow2.png ... http://www.pvvbitech.hu/fotok/variationYellow9.png And the first 'more green' result: http://www.pvvbitech.hu/fotok/variationGreen1.png The plugin operate with the layer effect in mode 'color'.(I suppose) I have followed the 'More yellow' process. (the variationYellow images) The process of gray color: On the original picture: R: 65%, G:65%, B:65% (a7a7a7) 1. step (More Yellow) R: 68%, G:76%, B:47% (aec279) 2. step R: 73%, G:85%, B:19% (bbd930) 3. step R: 80%, G:85%, B:9% (cdda18) 4. step R: 90%, G:95%, B:0% (e6f200) 5. step R: 96%, G:98%, B:0% (f4fb00) 6. step R: 98%, G:99%, B:0% (fafd00) 7. step R: 99%, G:100%, B:0% (fdfe00) 8. step R: 100%, G:100%, B:0% (fefe00) I have written this in hope, perhaps if somebody is interessing of writing this usefull plugin. What can I contribute? I can take many photoshop's screenshot, and I can contribute results of test images. Best regards, Khiraly ps: sorry for my ugly english ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New feature inquiry.
On Sun, 18 Jul 2004 17:47:05 +0200, Daniel Egger <[EMAIL PROTECTED]> wrote: > ... with the integration of GEGL and more flexible data > types it might be worth to look into that again. I'd certainly > enjoy the idea of doing the composition using the GPU and > shader programs. The problem might be when you have some operations that you can accelerate with the GPU, and some operations that you need to perform using the CPU. As long as you can assume memory transfers in both directions are free there is no problem, apart from this hurdle, there is no reason not do gradually start porting GEGL nodes to use optional,. hardware acceleration,. sacrificing some quality for speed. Each node ported would be a separate change,. a wider change would be to specify the "glitz'ness" as a property of the pixel representation,. and somehow attempt using that special "blessed" pixel representation throughout the pipeline,. this is rather unfeasible IMO /Øyvind K, ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Selecting new constants for '(file-type file)'?
Greetings, all. I want to define some constants related to file type for use in Tiny-Fu. My current thinking is to use FILE_TYPE_FILE (0), FILE_TYPE_DIR (1), and FILE_TYPE_LINK (2). The last one being for *nix systems only. Are there any other file types that should be handled (ie. nodes on *nix systems)? Comments? 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] filetype plug-in to get type of entity (file/directory)
Greetings, Markus (and everyone else). At 07:47 PM 07/16/2004, you wrote: this is a trivial plug-in that implements one single call: file-get-type [snip] I'm giving this another shot (after bug #145370, taking your feedback into account - TinyScheme currently lacks a similar feature), because it seems to me that batch-processing is the single most often asked issue on the comp.graphics.apps.gimp NG, and it would be great if we could just give people a script similar to the sample I'm attaching, tell them to copy it to ~/.gimpXY/scripts/ and let's rock, without the need to download and compile a separate plug-in. Users of GIMP 2.0.x may find your scripts useful, Markus. It could also fill a gap in the current Script-Fu plug-in. The Tiny-Fu plug-in, while not making your work obsolete, will provide an alternative approach to batch processing. The following code snippet (shown without the 'tiny-fu-register' block) demonstrates how a script written for Tiny-Fu would be able to handle batch-processing. When called up from the GIMP menus, you would get a dialog box where you could enter (or browse for) a directory. The script will then open up the directory and generate a list of all entries (including . and ..). With the use of the 're' extension, pattern matching could be applied to the file names and only the ones that match a supplied pattern could be listed. Once I add a 'file-type' routine to one of the extension packages, it will be possible to only list files of a given type. (define (tiny-fu-listfiles dir) (let* ( (dir-stream (open-dir-stream dir)) (file) ) (if (not dir-stream) (gimp-message (string-append "Unable to open directory " dir)) ( (do ( (file (read-dir-entry dir-stream) (read-dir-entry dir-stream)) ) ( (eof-object? file) ) (display file) (newline) ) (close-dir-stream dir-stream) ) ) ) ) Also, the new file handling routines available allow for a file to be deleted (assuming you have the permissions necessary to do so). When I mentioned on #gimp that a script should be written to demonstrate the new possibilities for scripts, schumaml suggested a contact sheet. Tiny-Fu makes such a script a very real possibility. I have already started to plan out how such a script should behave and the information a user would need to provide. This is just a taste of the possibilities for scripting in GIMP using Scheme based scripts with Tiny-Fu. What would you like to do today? :-) 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] Howto: store comments in image from plugin?
Thanks for all the people who answered. It turned out to be as simple as attaching a "gimp-comment" and "jpeg-exif-data" parasites to the image. (of course generating jpeg-exif-data is not trivial. Only implemented for my Nikon D70 at the moment. I guess others who like more formats will have to implement their own) -Joseph ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] removing gimp toys, second opinion please?
Hi, Alan Horkan <[EMAIL PROTECTED]> writes: > If you still reject the idea I would ask you to keep the toys in mind when > it comes to menu reorganisation. (Wiki is still down otherwise I'd add > this to the menu reorganisation document we had there). > The Gnome HIG recommends: > > http://developer.gnome.org/projects/gup/hig/1.0/menus.html#menu-type-submenu > Do not create submenus with fewer than three items, unless the items are > added dynamically (for example the File->New Tab submenu in gnome-terminal). Looks as if we need a third Toy then. Any volunteers? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] compose - decompose nitpicking
On Wednesday 21 July 2004 09:42 am, Sven Neumann wrote:
> Sure, the plug-in is far from perfect. There's some code in compose.c
> that tries to guess some useful default values for the layers it
> preselects. This code could certainly be improved. I am not sure
> though if it makes sense to attempt to guess the compose mode from the
> given layer names. It's probably more useful to remember the last used
> mode (which is what the plug-in does already).
For a start, I'm attaching a patch that makes "compose" use the layers in
reverse order (if the image has more than MIN_COMPOSE_LAYERS = 3 layers,
otherwise use old behavior). No attempt is currently made to guess the mode.
Markus.
*** oldcompose.c Wed Jul 21 17:34:11 2004
--- compose.c Wed Jul 21 21:18:52 2004
***
*** 105,110
--- 105,112
/* Maximum number of images to compose */
#define MAX_COMPOSE_IMAGES 4
+ /* Minimum number of layers necessary to compose from layers */
+ #define MIN_COMPOSE_LAYERS 3
/* Description of a composition */
***
*** 1069,1074
--- 1071,1078
GtkWidget *image;
GtkWidget *image_option_menu, *image_menu;
GSList*group;
+ gint32 *layer_list;
+ gint nlayers;
gint j, compose_idx;
gboolean run;
***
*** 1087,1092
--- 1091,1098
gimp_ui_init ("compose", TRUE);
+ layer_list = gimp_image_get_layers (gimp_drawable_get_image (drawable_ID), &nlayers);
+
dlg = gimp_dialog_new (_("Compose"), "compose",
NULL, 0,
gimp_standard_help_func, "plug-in-compose",
***
*** 1148,1154
GTK_FILL, GTK_FILL, 0, 0);
gtk_widget_show (label);
! composeint.select_ID[j] = drawable_ID;
composeint.channel_menu[j] = image_option_menu = gtk_option_menu_new ();
image_menu = gimp_drawable_menu_new (check_gray,
image_menu_callback,
--- 1154,1160
GTK_FILL, GTK_FILL, 0, 0);
gtk_widget_show (label);
! composeint.select_ID[j] = ((nlayers >= MIN_COMPOSE_LAYERS) ? layer_list[nlayers - (j + 1)] : drawable_ID);
composeint.channel_menu[j] = image_option_menu = gtk_option_menu_new ();
image_menu = gimp_drawable_menu_new (check_gray,
image_menu_callback,
***
*** 1161,1166
--- 1167,1173
gtk_option_menu_set_menu (GTK_OPTION_MENU (image_option_menu),
image_menu);
}
+ g_free (layer_list);
/* Set sensitivity of last menu */
gtk_widget_set_sensitive (composeint.channel_menu[3],
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] New Tiny-Fu tarball and a clarification about it
Greetings, everyone. Before I get to todays announcement I need to clear up a possible misunderstanding about the Tiny-Fu plug-in. One person on #gimp thought they might lose the ability to use Script-Fu if they installed Tiny-Fu. Applying the patch file to hook Tiny-Fu in to a copy of the GIMP 2.1.x source tree DOES NOT remove the existing Script-Fu plug-in. Script-Fu and Tiny-Fu will happily co-exist with each other. The two plug-ins have different file names and use their own set of script files. And now to todays announcement... The third public release of a tarball for the Tiny-Fu plug-in for GIMP 2.1.x is now available. With this release, Tiny-Fu is essentially complete (ie. all of the core features are in place). The work on this plug-in now shifts mainly to testing, bug-fixing, and some changes/enhancements to the tsx extension. The Tiny-Fu tarball is available for at: http://www.interlog.com/~kcozens/software/gimp/tiny-fu.html Changes since the July 14, 2004 release: o Added preliminary support for GIMP parasites. o Added the re extension (regexp style pattern matching) to the build and install of Tiny-Fu. o Added a page to the web site for FAQ's about Tiny-Fu. I will be renaming the tsx extension shortly since I will be deviating from the original version of the extension. The plan is to include just the date/time and file related routines, use routines from glib to make the extension more portable to different platforms, rename some of the routines to be more in keeping with the PDB API naming system, and adding any missing routines (such as 'file-type') that are necessary or particularly useful. 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
