Re: [Gimp-developer] easy questions
Hi Zack, Quoting Zack [EMAIL PROTECTED]: The first is, how intimately is the GIMP tied to GTK+? Very. Although the GUI code has been separated out from the internals, the GIMP depends on GTK+ to a huge extent. It is inextricably linked to glib and gobject too. The second is, I haven't looked at the code at all, but is the GIMP multithreaded and/or does it absolutely require a multitasking OS? I wouldn't say so. I don't believe there is threading code in the GIMP, but I am not sure. Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Lists, Arrays and Vectors [was Re: [Gimp-developer] Re: Tiny-Fu: A new plug-in for GIMP]
On Wednesday 07 July 2004 05:05, Kevin Cozens wrote: On Tue, 2004-07-06 at 19:45, Sven Neumann wrote: The fact that the PDB uses arrays doesn't necessarily mean that a language binding such as Tiny-Fu needs to represent them as arrays. One of the most annoying bits of Script-Fu is that it forces you to work with arrays even though the natural choice for a scheme dialekt would be lists. If Tiny-Fu cannot provide backward-compatibility, then it should overcome this mistake and map the PDB API to lists. Tiny-Fu makes no attempt to provide backwards compatability with the SIOD Scheme interpreter way of doing things. It expects scripts to follow the current Scheme standard as defined in the R5RS document. Since the R5RS does not define an array type, any script which uses arrays either internally or when dealing with PDB calls needs to be modified to use a list. The marshalling code of Tiny-Fu converts between PDB *ARRAY and Scheme lists as needed. The alternative would be to use a Scheme vector but instead of a list. Using a list seemed like the simplest approach. Are you sure using lists instead of vectors is the right thing to do? Lists are linked lists and as such accessing the i'th element is O(i). In vectors it is O(1). This can cause an order of complexity increase in handling them. Are you certain that all the scripts initialize the arrays, one element after another in sequential order? Or are there scripts with random access? In any case, this may not be an issue, because a programmer can temporarily use a vector, and convert it to a list before calling the PDB entries. (It reminds me that in Visual Basic the built-in array is implemented as a linked list, and so random access to it is slow as hell. What serious programmers do is implement the array logic in C and bind it to their VB programs) Regards, Shlomi Fish -- - Shlomi Fish [EMAIL PROTECTED] Homepage:http://shlomif.il.eu.org/ Knuth is not God! It took him two days to build the Roman Empire. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
Hi, (Second try, this time sent to the list at large. Brains where art thou!) Sven Neumann wrote: Well, we have only one internal color space. We just need to agree on what we want to call it... My two-penneth (as author of the separate plugin, and a day-to-day user of the GIMP in a pre-press environment): There are as I understand it, two possible ways of dealing with colour profiles. In the first method, is what I believe is what PhotoShop uses (and what I think Sven proposed): When an image is loaded, scanned or whatever, it is converted from its source colour space into a working colour space (sRGB, AdobeRGB, etc.). Of course, the source colour-space and working colour-space can be the same. The advantage of this method is that the working data is always normalised, so plugins and the like have perceptually identical results, whatever the image's native colour space. The workflow for an sRGB Image might be: Image (AdobeRGB) - Working data (convert to sRGB) - Editing - Save (convert back to AdobeRGB) Personally, I don't think this method is appropriate for the GIMP until such time as we have support for 16-bit or float pixels, because if we convert from the source space to a working space with only 8 bits per sample we're going to lose some information through quantization errors. The second method, which I think we should use for the time being, is just to keep track of the source profile for each image (and have a user-selectable default profile - sRGB, AdobeRGB or whatever). This source profile should be user-changable (so the user can tag a scanned image with the scanner's profile, for example), and just needs to be accessible to the proof and image-saving code. The equivalent workflow would be: Image (tagged with AdobeRGB) - Working data (8-bit RGB, unmodified) - Editing - Save (AdobeRGB) The advantage is that the image data doesn't have to be transformed between profiles (so we need the facility to do this manually, should the user need it), but there are some disadvantages: The effects of some plugins will look different depending on the image's colour space. (GFlare's flares, for example, will look slightly different applied to an sRGB image compared with an AdobeRGB image...). Colour-choosing is less-predictable (though no less than at present), since the RGB values selected are in a variable colour space. Since we're unlikely to get a PanTone colour-selector any time soon, this shouldn't be an issue. The ultimate solution here is to have a colour-profile attached to the colour-selector, and simply transform the selected colour to the current image's profile. The colour-selector's profile is probably as close as we need to get at the moment to a working profile. You would have to convert between colour spaces when copying and pasting between images with different profiles. (Ideally a warning with yes/no buttons. I personally wouldn't want this done silently, because again it would introduce quantization errors with 8-bit data). In short, though, if we use this method, we don't need to agree on what to call our working space, because it will simply be whatever is appropriate for the image being edited! Hope this little essay is some help! All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: Re: [Gimp-developer] start perl server
On Thu, 17 Jun 2004, Seth Burgess wrote: I'd recommend putting the call inside an 'eval' block, so that it failing doesn't stop the execution of the script. Sorry, I'm here again... ;-) If I run the attached script without parameters, then I can see that gimp appears and I can generate my needed image. But with parameters (without the appearing gimp window), I get the following: [EMAIL PROTECTED]:/home/wmi/cvs/wmi/ui ./oval-0707.pl -output_file FILENAME \ -font_size_pixels 11 -text_string TEXT oval-buttons.pl: gimp_text_get_extents_fontname: procedural database execution failed at ./oval-buttons.pl line 64 (DIE) I cannot 'eval' it out, because I need the data captured in line 64. Could you please help? TIA, Zoltan oval-0707.pl Description: Perl program ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] OSCon attendance
Hi all, As everyone knows (hopefully), the GIMP won an OSI award recently. Part of the results of that is that the GIMP is one of the candidates for the annual golden award (with a large cash prize) which will be presented to the winning project in Portland at the O'Reilly Open Source Conference in a couple of weeks. Is anyone here planning to go to OSCon already? And to answer the question before it's asked, there will be no cash to pay for travel or accommodation expenses. But if someone were already going they could be our official representative at the awards dinner. Alternatively, there are several GNOME developers going and presenting papers that I noticed - if no-one here wants to go, I suggest that we ask one of them to represent us and pick up the prize (if we get one). What do people think? Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] easy questions
On Wed, Jul 07, 2004 at 10:06:58AM +0200, David Neary wrote: Hi Zack, Quoting Zack [EMAIL PROTECTED]: The first is, how intimately is the GIMP tied to GTK+? Very. Although the GUI code has been separated out from the internals, the GIMP depends on GTK+ to a huge extent. It is inextricably linked to glib and gobject too. The second is, I haven't looked at the code at all, but is the GIMP multithreaded and/or does it absolutely require a multitasking OS? I wouldn't say so. I don't believe there is threading code in the GIMP, but I am not sure. You won't be able to use any plugin without a multitasking OS... Regards, DindinX -- [EMAIL PROTECTED] Celibacy is not hereditary ___ 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]
At 05:17 AM 07/07/2004, Shlomi Fish wrote: Are you sure using lists instead of vectors is the right thing to do? Lists are linked lists and as such accessing the i'th element is O(i). In vectors it is O(1). This can cause an order of complexity increase in handling them. No, I'm not sure. For the few scripts I looked at (and for ease of implementation), using a list was the easier route to have something functional during the early development stages. Using vectors instead of a simple list would mean the ability to use functions which would provide rough equivalents to the SIOD interpreters array manipulation functions. In any case, this may not be an issue, because a programmer can temporarily use a vector, and convert it to a list before calling the PDB entries. Conversion is simple through the use of vector-list and list-vector. I will take a closer look at using vectors. It will simplify the work needed to update old Script-Fu scripts for use with Tiny-Fu. I will start by converting between list and vector. If the approach works well, I will bit the bullet and update the marshalling code to use vectors for the *ARRAY types. 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 disclaimer/favourite | -Pinkutus the Borg ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] plugin to put points on top of each other
Hi, I think, a very common problem is to put particular points of two (or more) different pictures/drawables on top of each other. This could be done by a perspective transformation and is useful, if you for example want to create an animated gif out of many slightly different pictures (consider unwanted waggling of the camera) you took with your digicam. If you use the raw source pictures, there might be small jumps in the flow, but if you use a transformation to put particular points on top of each other, there is a smooth effect of motion. I need this feature to create stereooscopic-images, using the stereoscopic-plugin. The output-image could be viewed using red/green glasses. With stereoscopic-images it is very important to adjust the two images (right, left) so that at least the points of the focused object are exact on top of each other. Is there already a plugin which provides the needed feature? My recherche in the registry was negative, but may be I overlooked something. Despite of the fact there might be a already existing plugin, I wrote a plugin which implements the following algorithm: - You provide three source points in the left-eye-image/drawable which should be exact on top of the corresponding three points in the right-eye-destination-image/drawable. - The plugin calculates a matrix for a affine transformation out of this data and performs the transformation. Unfortunately, for the moment, the plugin is not very comfortable to use: you have to provide 6 points (x and y-value) in 12 spin-buttons and you have to enter all values by hand. Since I am not very firm with gtk and the gimp-tools, there is no way to enter these values just by clicking on the points in the displayed images. Could your help me in that point? I just need to know how to grab the point-coordinates of a click to an image! I want to take these coordinates and fill the spin-buttons with these data to provide more comfort. From the context of my plugin (the run-function), I don't know anything of the diplayed image (and the events that are activated in it), isn't it? All I know is the image_id and the drawable_id. Any hints are very welcome!! My algorithm works very similar to the perspective-transformation in the toolbox. The main difference is that with perspective-transformation it is not possible to provide the source-points which are fixed to the corner points. You may only change the 4 destination points. Regardless, the user-interface of perspective-transform is very comfortable (grid-preview, move points in the picture) and I would be happy if my plugin could provide the same comfort. thanks, Christoph ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Script-fu-server and queuing
Because the Gimp was not originally designed as a server, it does not follow some conventions that are necessary for such a mode. This includes the issue of managing shared resources among different threads of execution. A few of the resources that are not 'thread-safe' include the current foreground/background color and brush shape. Your can work around this problem by using Gimp::lock until it is solved. -- The choice of a | -==- _GNU_ | ==-- _ generation Marc Lehmann +-- ---==---(_)__ __ __ [EMAIL PROTECTED] |e| --==---/ / _ \/ // /\ \/ / http://schmorp.de/ --+ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE| | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] OSCon attendance
On Wed, Jul 07, 2004 at 04:06:38PM +0200, Dave Neary wrote: As everyone knows (hopefully), the GIMP won an OSI award recently. Part of the results of that is that the GIMP is one of the candidates for the annual golden award (with a large cash prize) which will be presented to the winning project in Portland at the O'Reilly Open Source Conference in a couple of weeks. awesome. Is anyone here planning to go to OSCon already? And to answer the question before it's asked, there will be no cash to pay for travel or accommodation expenses. But if someone were already going they could be our official representative at the awards dinner. who are the people who live in this area? Alternatively, there are several GNOME developers going and presenting papers that I noticed - if no-one here wants to go, I suggest that we ask one of them to represent us and pick up the prize (if we get one). lets look to find a gimp person first. carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] easy questions
Hi, Quoting David Odin [EMAIL PROTECTED]: The second is, I haven't looked at the code at all, but is the GIMP multithreaded and/or does it absolutely require a multitasking OS? You won't be able to use any plugin without a multitasking OS... Won't the plug-in just become modular over the main app? Oh, no - we use shared memory, so the two apps need to be running at the same time... Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] OSCon attendance
Hi, Quoting Carol Spears [EMAIL PROTECTED]: On Wed, Jul 07, 2004 at 04:06:38PM +0200, Dave Neary wrote: Part of the results of that is that the GIMP is one of the candidates for the annual golden award (with a large cash prize) which will be presented to the winning project in Portland at the O'Reilly Open Source Conference in a couple of weeks. awesome. We're a long way from winning - we're up against the Valgrind guy, Pango, VideoLAN, GNU arch and a couple of other really good projects. We have a shot, though. who are the people who live in this area? Do people live near Portland? (Joke!) AFAIK, no-one is actually here and living in Portland. yosh is in the bay area, and has said he will be able to go if the conference registration fee is waived (which I think it should be). So I guess our search is over :) lets look to find a gimp person first. That was the point of mailing here. Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] plugin to put points on top of each other
Christof Lutz writes: Could your help me in that point? I just need to know how to grab the point-coordinates of a click to an image! If you go into the plug-ins/common directory of the source and grep for GDK_BUTTON_PRESS, you will find plenty of examples that will quickly show you how to do it. There are three main steps involved: (1) requesting to receive button press events, (2) connecting a callback for them, and (3) handling them in the callback. 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
[Gimp-developer] what's required to develop GIMP
Hi, I am completly new to GIMP development. And I would like to be a gimp developer. Please give me information on the following quetion. 1. What is the programming language used to develop gimp. 2. What are the tools and compilers that i need to compile gimpe source code. 3. What is the latest version of GIMPs source code. Thanks a lot, Chamal. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] plugin to put points on top of each other
Hi, William Skaggs [EMAIL PROTECTED] writes: Christof Lutz writes: Could your help me in that point? I just need to know how to grab the point-coordinates of a click to an image! If you go into the plug-ins/common directory of the source and grep for GDK_BUTTON_PRESS, you will find plenty of examples that will quickly show you how to do it. I guess that Christof is asking for a way to get the coordindates of a click into a GIMP image window, not a click on a widget in the plug-in dialog. If that is the case, then the answer is that plug-ins can't do that. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] what's required to develop GIMP
On Wed, 7 Jul 2004 09:41:48 -0700, Chamal De Silva [EMAIL PROTECTED] wrote: I am completly new to GIMP development. And I would like to be a gimp developer. Please give me information on the following quetion. 1. What is the programming language used to develop gimp. Most of it is written in C, some parts of the build system use a bit of Perl. A quick look at the source code would have allowed you to answer your own question easily. In addition to the gimp core written in C, you can also have the various scripting extensions written in Scheme (Script-Fu or the newer Tiny-Fu), Perl and Python. 2. What are the tools and compilers that i need to compile gimpe source code. Please have a look at: http://www.gimp.org/source/ (stable version) http://developer.gimp.org/ (development version) That will give you all the necessary information. In addition, once you have a look at the source code, please read the README and INSTALL files. If you get the code from CVS, you can also have a look at the HACKING file. 3. What is the latest version of GIMPs source code. The latest version of the source code is in CVS. If you want tarballs, then the latest stable version is 2.0.2 and the latest unstable version is 2.1.1, available from ftp.gimp.org and its mirrors. This information is also available from the web sites listed above. Please have a look at them. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] plugin to put points on top of each other
Sven Neumann wrote: Hi, William Skaggs [EMAIL PROTECTED] writes: Christof Lutz writes: Could your help me in that point? I just need to know how to grab the point-coordinates of a click to an image! If you go into the plug-ins/common directory of the source and grep for GDK_BUTTON_PRESS, you will find plenty of examples that will quickly show you how to do it. I guess that Christof is asking for a way to get the coordindates of a click into a GIMP image window, not a click on a widget in the plug-in dialog. If that is the case, then the answer is that plug-ins can't do that. yes, that's true and it's a pity that there is no way :-) So what do you suggest: I want to mark particular points in one or more images and use the marked coordinates in my plugin-dialog. Do you think it's the best to create picture-buttons with more or less small thumbnails of the images and read the coordinates of the corresponding GDK_BUTTON_PRESS? The smaller the thumbnail, the more unprecise the coordinates I get. Is this way possible actually? How can I get reasonable results in respect to the precision of the corrdinates? I always had in mind to do it that way (create a picture-button), but I felt the results may be better if I click into the GIMP-image itself which is unfortunately not possible. Christoph Sven ___ 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
[Gimp-developer] the gnome foundation and board
someone should say something nice about the gnome foundation and their help in getting the gimp conference to eh, be. they were also very nice to have visit in that one meeting. the very best thing i can say about the event and the gnome foundations influence on it is that Tim Ney was a pleasure to communicate with. i remember relaxing and enjoying everything and a nifty wireless keyboard which should have been collecting notes carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] plugin to put points on top of each other
Christof Lutz writes: yes, that's true and it's a pity that there is no way :-) So what do you suggest: I want to mark particular points in one or more images and use the marked coordinates in my plugin-dialog. Do you think it's the best to create picture-buttons with more or less small thumbnails of the images and read the coordinates of the corresponding GDK_BUTTON_PRESS? The smaller the thumbnail, the more unprecise the coordinates I get. Is this way possible actually? How can I get reasonable results in respect to the precision of the corrdinates? My apologies for misunderstanding the question. I am doing something very much like this in gfig, using the following code (simplified a little bit): if (! back_pixbuf) back_pixbuf = gimp_image_get_thumbnail (image_id, preview_width, preview_height, GIMP_PIXBUF_LARGE_CHECKS); if (back_pixbuf) gdk_draw_pixbuf (preview-window, preview-style-fg_gc[GTK_STATE_NORMAL], back_pixbuf, 0, 0, 0, 0, gdk_pixbuf_get_width (back_pixbuf), gdk_pixbuf_get_height (back_pixbuf), GDK_RGB_DITHER_NONE, 0, 0); Here preview is a GtkDrawingArea. You can create a thumbnail up to 512 x 512 in this way. (Incidentally, thanks to Sven for improving the code I originally wrote to do this.) 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] plugin to put points on top of each other
Hi, William Skaggs [EMAIL PROTECTED] writes: if (back_pixbuf) gdk_draw_pixbuf (preview-window, preview-style-fg_gc[GTK_STATE_NORMAL], back_pixbuf, 0, 0, 0, 0, gdk_pixbuf_get_width (back_pixbuf), gdk_pixbuf_get_height (back_pixbuf), GDK_RGB_DITHER_NONE, 0, 0); Any particular reason that you use GDK_RGB_DITHER_NONE here instead of GDK_RGB_DITHER_NORMAL? GdkRGB dithering is rather fast and it yields a much better visual appearance on 16bit displays. Or did I write it this way? Sven ___ 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]
Are you sure using lists instead of vectors is the right thing to do? Lists are linked lists and as such accessing the i'th element is O(i). In vectors it is O(1). This can cause an order of complexity increase in handling them. This is true, but not much of a problem, since most scripts only use either the first 1 or 2 elements of arrays or work on typically very short arrays, or want to pass a (short) array to PDB, where there is no difference between list-construction and setting every element of a vector explicitly (the latter possibly being even more inefficient). No, I'm not sure. For the few scripts I looked at (and for ease of implementation), using a list was the easier route to have something functional during the early development stages. Using vectors instead of a simple list would mean the ability to use functions which would provide rough equivalents to the SIOD interpreters array manipulation functions. As I understand it, there are even *exact* equivalents to the current array type. No wonder, since a Lisp vector is a special case of an array (one-dimensional). In Script-Fu, arrays are indeed vectors. I will take a closer look at using vectors. It will simplify the work needed to update old Script-Fu scripts for use with Tiny-Fu. I will start by converting between list and vector. If the approach works well, I will bit the bullet and update the marshalling code to use vectors for the *ARRAY types. I also opt for vector because apart from being the natural Scheme equivalent to PDB's one-dimensional arrays, it makes writing plug-ins easier for people that have no to little practice in converting common for/while loops using tail-recursion, and current scripts would work practically unmodified, without explicit conversions list-vector that would only cost time (with everybody ending up calling these instead of working on lists most of the time). Markus. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] CVS updates?
Is Gimp anonymous CVS on a delayed copy? I'm assuming so based on the fact that I can't seem to get at the most recent commits through a cvs up -dP or cvs log. If there's something in the developer FAQ which is explicit about this, please point me to it so I can feel stupid. I did look! Also, the RSS changelog (http://wilber.gimp.org/~rss/gimp-cvs.rdf) has links to the GNOME bonsai on cvs.gnome.org which are all dead links. The only thing running on cvs.gnome.org seems to be viewcvs, which does at least seem to be more up to date than anon cvs, and diffs can be dug out of it. Would it be possible to fix the RSS changelog to point at viewcvs, which works, instead of bonsai, which doesn't? -- brion vibber (brion @ pobox.com) signature.asc Description: OpenPGP digital signature