Re: [Gimp-developer] GPU-accelerated Image Filtering w/ CUDA
Alan, You're code certainly sounds very useful, and I would love to see it open sourced. May I suggest, as was already stated, that you decide upon a license, find a name for your library, and then open a github ( http://github.com) account (or any other free hosting) where you upload the code. Whether it will be made part of gimp or not is a different issue, and I agree that you should introducing closed source dependencies for such a project is not a good idea. Btw, there is an open standard for CUDA-like operations being developed, called OpenCL, but it is not very supported yet. See: http://en.wikipedia.org/wiki/OpenCL . Pehaps you want to investigate whether there is NVIDIA support for the operations that you use, and if so, recode the algorithms in OpenCL? But again, I would do the work in a separate repository in github. Regards, Dov On Mon, Aug 30, 2010 at 01:46, Øyvind Kolås pip...@gimp.org wrote: On Sun, Aug 29, 2010 at 11:40 PM, Alan Reiner etothe...@gmail.com wrote: I forgot that CUDA is not OSS. We don't have to worry about that because we only use it for in-house simulations. I only remembered it was free for such use. I know that similar stuff can be done with OpenGL, but that's a completely different beast. There's also OpenCL but I don't know anything about that either. At least those two solutions should work on both NVIDIA and ATI, but I believe the code still needs to be tailored specifically for each architecture. As for portability, I don't see that as a concern for any of these. For various platforms, it would be preprocessed out. For everything else it can detect and disable itself if it won't work on the resident card. I might look a little bit into the OpenGL solution to see if that's feasible, but my understanding is that it's more archaic and not as powerful. And I personally don't have a reason to learn it. Perhaps one day when I have time to contribute directly to an OSS project. Doing image processing on the GPU using OpenGL and GLSL for GIMPs next generation engine is planned and the initial proof of concept of such a system deeply integrated with GEGL exist in a branch of the git repository at http://git.gnome.org/browse/gegl/log/?h=gsoc2009-gpu , The approach taken there is to implement automatic migration of tiles between cpu and gpu. /Øyvind K. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Idea for data flow in gimp and or plug-ins
Hello, When reading about the ideas for the SoC, I was reminded of an idea I got when looking at a collegue showing me the L*bVi*w code development environment. By interactively dragging out various blocks with a different set of inputs and outputs and connecting these with connectors he basically created a dataflow. In LV these are usually used for reading input from various HW sensors and displaying them in dials etc. As I was thinking about other uses for the same idea, I thought of two uses in Gimp. Either as what was mentioned on this list as effect layers or as an alternative way of creating scripts. The layer paridigm seems to be quite limited since it is effectively one-dimensional. I believe that creating a canvas containing effect boxes and connecting wires through which images and parameters would flow, would be an easier interface to comprehend. Sorry for these somewhat disconnected thoughts. Should I write it up more organized in bugzilla? Regards, Dov ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Patterns -- things we could do to make their manufacture much easier
Don't forget the fantastic resynthesizer plug-in as part of the tool chain for creating tilable plug-ins. It is certainly usually much better than any alpha-blending. See: http://www.logarithmic.net/pfh/resynthesizer Regards, Dov On 12/29/05, Leon Brooks [EMAIL PROTECTED] wrote: On Thursday 29 December 2005 07:20, Carol Spears wrote: the one other thing that would make them useful as patterns is if they can be made tileable. there is at least one plug-in that does this. OK... having a stab at doing this manually for one herringbone pattern of brick pavers now, and it ain't as easy as it looks. (-: This would be a really handy thing to have a dedicated tool (or at least plugin) to do. The following comments apply to real-world objects being converted to patterns; they may not apply to computer-generated patterns. Each potential tiled texture will probably need some fisheye correction, which Dave Hodson's Telephoto plugin does reasonably well -- thanks, Joao, for reminding me that the plugin existed. This is made a little easier by lining image features up against guides, but it's still very much trial-and-error. Being able to do it on the main image in real-ish time would help a lot. Many of them will also require keystone correction to make them square (or at least symmetrical across the X and Y axes). Those which require both would be a lot easier to deal with if both this and the fisheye correction could be done interactively, realtime(ish) and full-scale on a single set of sliders. Next, we need to isolate (crop to) a section of the subject which is suitable for one of the algorithms below. Interactivity would help this a lot as well, see discussion for each. Having made the subject basically rectangular, the next step is to make it repeatable. There are two techniques that I've looked at so far. One consists of replicating the original rectangle in each direction, flipping the image over its edge to achieve an image twice as large in each direction but which matches exactly along the edges. This does not work well for asymmetrical subjects, such as those containing text or lit predominantly from one side. Being able to tweak the corrections and cropping on the fly and have it displayed as an endless pattern would make achieving near-perfect results considerably easier. Storing a single copy of the basic pattern rather than a fourfold-larger copy woulod be good, but would require the addition of a different tiling mode rather than simple repetition, call it flip-tiling if it doesn't already have a name. The other method consists of overlapping the original image with itself and alpha-blending the edges of each copy to smooth over differences between each edge of the image. This does not work very well if the subject is not consistent from edge to edge, but does handle asymmetries such as sunlight coming from one side reasonably well. There is already a plugin to do something like this, but it is *very* clumsy and only works acceptably with very complicated, fine-grained subjects, or with very near-featureless subjects. Even then, there is rectangular meta-pattern visible at larger scales because of the unsubtle blending at the edges of the image. Real-time interactivity would greatly help this mode as well. It would also benefit from being able to do gradiented corrections of at least brightness across the subject, possibly automatically or semi-automatically by selecting tiles along each edge and adjusting the intensity gradient so that they are equal, then another pass to smooth the gradient. Another pair of useful features would be the ability to draw the alpha-blending border on each edge of the image freehand and/or with beziers, and to adjust the slope (or possibly even curve) of the blending. This would allow the operator to better duck around anomalies. A final useful feature would be the ability to arbitrarily deform areas of the subject, PowerGoo(tm)-style, in order to better match up the edges of random/chaotic patterns like waves or gravel. Cheers; Leon -- http://cyberknights.com.au/ Modern tools; traditional dedication http://plug.linux.org.au/ Member, Perth Linux User Group http://slpwa.asn.au/Member, Linux Professionals WA http://osia.net.au/ Member, Open Source Industry Australia http://linux.org.au/Member, Linux Australia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Image scrolling
Hi Glenn, This answer has nothing to do with gimp, but as the author of the GtkImageViewer widget who has dealt with a similar problem - the display of 600MB pbm images - I thought I would tell you about my solution. The solution only works for uncompressed images. I did not load the whole image into memory at all, but used the view_changed signal callback of the GtkImageViewer for fetching a rectangle of data from the disk which is then immediately displayed. Zoomed out data was created on the fly as well by reading from the disk and downscaling in one go. Even smooth scrolling worked surprisingly fast. There is a small delay as the disk is accessed, but it is a lot less annoying then the swapping and paging that will take place if you try to read the whole image at once into memory. Hope this helps. If you want to hear more about this solution, perhaps we should move the discussion to gtk-app or privately, as it has nothing to do with gimp. Regards, Dov ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Running a batch script, failing under cron
We are running a conversion script in gimp 1.2 under RedHat Enterprise Edition 3. If we run the perl script interactively, it works. However, when run in cron, it does not, though it worked under cron on another production server running RedHat 7. It appears that the reason is that cron fails to find the script, but I cannot prove that. It simply doesn't do anything in gimp, and returns without any displayed error message. Perhaps we should be using 2.0, but installation has always been a massive headache, and we get incomplete installs due to failures in the print libraries, the only solution that I got a response about was building without printing, so I'd prefer to make this work with our existing setup, unless someone is feeling like being particularly helpful and resolving this ongoing problem with gimp builds for us. While we're at it, if you notice any massive inefficiencies in our script, I'd love to make it run faster, since it is executed 3000 times a day, soon to be 6000, then 24000. The following file is the gimp script, which works both under gimp-2.0 and gimp-1.2: (define (dl-png2transindexed2 file) (let* ( (img (car (file-png-load 1 file file) ) ) (d (car (gimp-image-active-drawable img))) ) (gimp-layer-add-alpha (car (gimp-image-get-active-layer img))) (gimp-by-color-select d '(255 255 255) 0 2 0 0 0 0) (gimp-edit-clear d) (gimp-convert-indexed img 0 0 255 0 0 ) (file-png-save 1 img d file file 0 6 0 0 0 1 1) (gimp-image-delete img) ) ) (script-fu-register dl-png2transindexed2 Toolbox/Xtns/Script-Fu/png2transindexed2 png2indexed2 Dov Kruger Elena Zagrai (c) 2004 Stevens Institute of Technology 2004-02-25 SF-FILENAME File file.png ) A test shell script that illustrates the problem with cron: #!/bin/sh echo 'foo' /usr/bin/gimp --no-splash --console-messages --no-interface -b '(dl-png2transindexed2 T26nyharaspeedtop.png)' '(gimp-quit 0)' echo bar ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Gimp-developer Digest, Vol 26, Issue 44
I can't subscribe so as to submit a contest entry, probably because of massive beating on the site Hopefully later on it will come back Better to just send all submissions to Sven via email ;-) ok, just a small joke. D On Tue, 2004-11-30 at 15:02, [EMAIL PROTECTED] wrote: Send Gimp-developer mailing list submissions to [EMAIL PROTECTED] To subscribe or unsubscribe via the World Wide Web, visit http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than Re: Contents of Gimp-developer digest... Today's Topics: 1. Re: 2.2 splash screen competition (David Neary) 2. Re: Re: 2.2 splash screen competition (Sven Neumann) 3. Re: Re: [Gimp-user] Re: [Gimp-announce] 2.2 splash screen competition (Carol Spears) 4. Re: Re: [Gimp-user] Re: [Gimp-announce] 2.2 splash screen competition (Manish Singh) 5. Re: 2.2 splash screen competition (David Neary) 6. Re: 2.2 splash screen competition (Manish Singh) 7. Re: 2.2 splash screen competition (David Neary) 8. Re: 2.2 splash screen competition (Manish Singh) -- Date: Tue, 30 Nov 2004 15:34:04 +0100 From: David Neary [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [Gimp-developer] Re: 2.2 splash screen competition Message-ID: [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-15 MIME-Version: 1.0 Precedence: list Message: 1 Hi all, After a false start, the GIMP Splash Contest is now officially open! The contest runs until next Sunday, Midnight. Splash screens should be the same size as jimmac's logo and have a pale band across the bottom roughly the same size. Otherwise, knock yourselves out! Competition entries should be attached to the live.gnome.org wiki page at http://live.gnome.org/GnomeArt_2fGimpSplashContest - you will need to create a wiki account. We will definitely have some kind of (small) prize sponsored, details will follow during the week (but the real reason you are doing it is the glory, right?) Good luck to everyone! And don't forget, spread the news! Cheers, Dave Neary. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ -- Date: Tue, 30 Nov 2004 16:06:03 +0100 From: Sven Neumann [EMAIL PROTECTED] To: David Neary [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Gimp-developer] Re: 2.2 splash screen competition Message-ID: [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] (David Neary's message of Tue, 30 Nov 2004 15:34:04 +0100) References: [EMAIL PROTECTED] [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Precedence: list Message: 2 Hi, David Neary [EMAIL PROTECTED] writes: The contest runs until next Sunday, Midnight. Splash screens should be the same size as jimmac's logo and have a pale band across the bottom roughly the same size. Otherwise, knock yourselves out! Actually, the band at the bottom doesn't necessarily have to be pale. GIMP 2.2 checks the color of the bottom area of the splash and chooses a suitable level of gray for the text overlay. The area at the bottom should however not have too much contrast or the text will become unreadable. Your best bet is that you try to use your image as a splash with a GIMP-2.2 pre-release. http://www.gimp.org/about/splash/ tells you how to do that. Sven -- Date: Tue, 30 Nov 2004 09:13:23 -0800 From: Carol Spears [EMAIL PROTECTED] To: Sven Neumann [EMAIL PROTECTED], GIMPDev [EMAIL PROTECTED] Subject: Re: [Gimp-developer] Re: [Gimp-user] Re: [Gimp-announce] 2.2 splash screen competition Message-ID: [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Precedence: list Message: 3 On Tue, Nov 30, 2004 at 11:11:21AM +0100, Sven Neumann wrote: I wouldn't wait for this to happen if I was you. The news system hasn't been resurrected for several months so I am pretty sure that the contest section has a similar unsolveable problem. We should use what's available but sorry, the mailing-lists won't work. from the Changelog. 2004-11-29 Helvetix Victorinox [EMAIL PROTECTED] * Cut over to the new (old) news system. let me see if i can sum up what has happened. please correct
[Gimp-developer] Re: High-performance gimping
Thanks to all who responded with useful comments. It isn't entirely clear from the comments when gimp starts up, but the tiling cache should indeed be almost as large as physical memory, allowing some for other uses (such as the OS). Increasing to 1500Mb on a 2G system was a huge improvement. I have not sought to tune that number, not doing enough of these to make that worthwhile. The undo suggestion of Alastair Robinson is also probably very good for continued manipulation. As I think the original posting indicated, allowing virtual memory to do the work, is for whatever reason not the answer. I suggest modifying the documentation to read something like: Increasing tile memory cache will continue to yield benefits until you totally saturate physical memory. If you can afford to give nearly all your physical memory to gimp while you are running it, and you need to process large images, then do so. thanks, Dov If the OS has better virtual memory than what available to gimp, then you would want to use that one. In Linux, I think in most cases, you would want to use the (often in multiple disks) swap partitions/files available to the OS. Evidently not, as in my first post. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] comparing gimp speed
I noticed that gimp is very slow for large images compared with Photoshop. We were recently processing some 500Mb images, and on a fast machine with 2Gb, gimp is crawling along, while on a slower machine with only 512 Mb, photoshop is considerably faster. I attributed it to a massive amount of work in photoshop, using sse instructions, etc. but then noticed that the default viewer in redhat allows me to load images far faster even than adobe, and zoom in and out with the mouse wheel in realtime. Granted, because you are editing the image, not just displaying it, there has to be some slowdown, but I wondered if there is any way I can tweak gimp, do I somehow have it massively de-optimized. When I first set up gimp-2.0, I tried both 128 and 512 Mb tile cache sizes. 512 seems to work a lot better, but it's still pretty bad. Any idea as to the area of the speed advantage of Adobe? thanks, Dov ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] error in code....
Based on advice from this forum, the script now reads: (define (dl-png2transindexed2 file) (let* ( (img (car (file-png-load 1 file file) ) ) (d (car (gimp-image-active-drawable img))) ) (gimp-layer-add-alpha (car (gimp-image-get-active-layer img))) (gimp-by-color-select d '(255 255 255) 0 2 0 0 0 0) (gimp-edit-clear) (gimp-convert-indexed img 0 0 255 0 0 ) (file-png-save 1 img d file file 0 6 0 0 0 1 1) ) ) This yields the following error: Error while executing (dl-png2transindexed2 /home/dkruger/dev/matlab/sdv4/longislandsaltL10T24.png) ERROR: too few arguments (see errobj) First of all, since it's probably obvious what I'm doing wrong, an answer is always appreciated, but I'd like to know if there is any mini-debugger available, or any way of seeing which line is the cause of the error. The error message says to see errorobj but I didn't see anything on the console, or a menu in the fu section that would show me the underlying cause. thanks to all! ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] error in script-fu code....
Carol suggested that removing the interactive flag from png-save might help. If I do that, I get an error that directly says that a parameter is missing from png-save, which is at least perfectly understandable. The script, with Carol's suggestion commented out, is below. Anyone else with an answer, or with a good way to see where bugs in fu-scripts are in general? thanks, Dov (define (dl-png2transindexed2 file) (let* ( (img (car (file-png-load 1 file file) ) ) (d (car (gimp-image-active-drawable img))) ) (gimp-layer-add-alpha (car (gimp-image-get-active-layer img))) (gimp-by-color-select d '(255 255 255) 0 2 0 0 0 0) (gimp-edit-clear) (gimp-convert-indexed img 0 0 255 0 0 ) (file-png-save 1 img d file file 0 6 0 0 0 1 1) ;(file-png-save img d file file 0 6 0 0 0 1 1) ) ) (script-fu-register dl-png2transindexed2 Toolbox/Xtns/Script-Fu/png2transindexed2 png2indexed2 Dov Kruger Elena Zagrai (c) 2004 Stevens Institute of Technology 2004-02-25 SF-FILENAME File file.png ) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] correct parameters for select-color?
As per Sven's suggestion, instead of plugin color to alpha, I want to try replacing every occurrence of white pixels with transparent. The documentation in the browser suggests something like the following: (gimp-by-color-select d '(255 255 255) 0 2 0 0 0 0) This should select color white, but I don't know how to make the selection transparent. Searching the calls in the browser for functions containing alpha and trans didn't yield anything obvious. Also, with apologies for my ignorance, Sven suggested looking at the interactive menu, but I don't understand how to select color white interactively, much less replace it. If I select menu selection-color the tool changes on the main gimp window, but I don't see a way to request color white, or make the selection, and once that's done, how do I make it transparent? I have seen functions that take the alpha layer and turn it to color, but how do I programmatically make the alpha layer? I searched for a while on color selection, but most selections out there seem to involve selecting a region and doing some photo retouching. Any pointers would be greatly appreciated. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] re: color to alpha is slow
Hello fellow gimpers, Apologies if this is not the correct group, but the users email seems geared towards people who use menus, not code. We are using gimp to batch process 3000 or so images per day generated from an oceanographic forecasting system. We need to make the background color of a 24bit png image transparent, and turn it into an 8 bit image because Internet Explorer can't handle alpha transparency evidently, more reason to use Mozilla. You might ask, why are we doing this? Answer: by pulling static background out of our maps, we achieve a massive bandwidth reduction on our forecast website, see http://onr.dl.stevens-tech.edu/webnyhos3 for the original, and http://onr.dl.stevens-tech.edu/wwwnyhos1/index3.html for the experimental transparent version. We currently execute a script-fu that turns all white pixels transparent, then turns the 24-bit-per-pixel image into indexed mode with 255 colors, setting color 0 transparent. It seems to take approximately 1 second per image, and the images are not all that big (some are as little as 15k, though the bigger maps, like Long Island, are as big as 150k). We do 100 at a time in a script, because the command line literally gets too long after a while -- we could probably increase that number to 500 or even decrease it, but the dominant factor seems to be the time it takes to do these operations. The machine is a 2.6Ghz P4 with 2Gb of RAM, the raw CPU should be capable of a lot more than this, and I allocated 500M in the gimp configuration, could some garbage collection problem be an issue? I suspect that color-to-alpha is the slow part. Is there anything we can do to speed this up, like convert the image to indexed, and just make color 0 transparent? Any help with code to programmatically make color entry n transparent would be great, we didn't find any reference to that. Oh, and to everyone who works on gimp, you guys kick serious butt! What a tool! thanks, Dov ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ANNOUNCE: Pre-releases for Perl bindings, Help pages and GAP + Win32 installer
I have just tested this release and updated my tutorial so that it works with it. You may see the result at: http://imagic.weizmann.ac.il/~dov/gimp/perl-tut-2.0/ . I have also fixed my two scripts in the examples directory, namely tex-to-float and gimp-make-img-map . Is it ok if I just put back the changes into cvs? Thanks for the good job! Regards, Dov ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ANNOUNCE: Pre-releases for Perl bindings, Help pages and GAP + Win32 installer
You will first need to install Gtk2 and all its prerequisites. ExtUtils::Depends is one of these. See the gtk2-perl home page. Regards, Dov On Sun, Mar 28, 2004 at 08:57:31AM +1000, Owen wrote: On Sat, 27 Mar 2004 23:47:22 +0200 [EMAIL PROTECTED] wrote: I have just tested this release and updated my tutorial so that it works with it. You may see the result at: http://imagic.weizmann.ac.il/~dov/gimp/perl-tut-2.0/ . I downloaded from ftp://ftp.gimp.org/pub/gimp/plug-ins/v2.0/perl/ but it wouldn't configure/make ERROR from evaluation of /home/owen/Gimp-2.0pre1/UI/Makefile.PL: Can't locate object method add_define via package ExtUtils::Depends at ./Makefile.PL line 42 In fact a grep of all modules could not locate add_define so I was wondering if that routine has been replaced with something else? -- Owen ___ 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] PDB Named Parameters
Great. Now, when you say it I remember Sven mentioning it in the past. But I guess that this new interface is not exported yet to any of the language bindings? Is that correct? Any plans when this API will become active? Regards, Dov FYI: the version of libpdb in CVS already uses named parameters instead of positional ones. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: PDB named and default parameters (was Re: [Gimp-developer] TheMark Shuttleworth offer)
One of the ideas that I believe Sven raised on irc, was that there should be a minimal and trivial interface to the PDB that is not based on any particular language but just consists of: gimp_foo -bar 3 -baz yellow Having such an interface to the PDB has several advantages: 1. It would take care of the quoting problems from the shell. E.g. gimp -nodisplay -cmd my_logo -text foo -bg_color yellow \ -cmd save_image -img 1 -filename foo.png 2. We could easily do recording and save into this format. 3. The format could easily be translated into script-fu, python, guile, etc. Possibly I misunderstood Sven though, in which I take all the blame. ;-) Regards, Dov On Sat, Mar 20, 2004 at 08:09:56AM -0600, Kevin Myers wrote: As Tor reminded me later, --batch doesn't work in gimp 1.2 under Windows, so that was the reason I couldn't use it. - Original Message - From: Sven Neumann [EMAIL PROTECTED] To: Kevin Myers [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, March 20, 2004 6:00 AM Subject: Re: PDB named and default parameters (was Re: [Gimp-developer] TheMark Shuttleworth offer) Hi, Kevin Myers [EMAIL PROTECTED] writes: Hmmm, I wonder why using the --batch option wasn't suggested when I ran into the problems that I mentioned previously... I guess that people assumed you knew about it. After all, googling for gimp batch leads you directly to Adrian's nice batch tutorial which is a bit outdated but still valid in the important parts: http://adrian.gimp.org/batch/batch.html 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 mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: PDB named and default parameters (was Re: [Gimp-developer] TheMark Shuttleworth offer)
On Sun, Mar 21, 2004 at 12:56:32PM -0800, Manish Singh wrote: On Sun, Mar 21, 2004 at 10:01:26PM +0200, [EMAIL PROTECTED] wrote: One of the ideas that I believe Sven raised on irc, was that there should be a minimal and trivial interface to the PDB that is not based on any particular language but just consists of: gimp_foo -bar 3 -baz yellow Well, we ship a scheme engine already, so writing and including yet another syntax parser seems kind of silly. I actually forgot one advantage. A meta-character void syntax has the advantage of being friendly for command line interactive use. After all, who many people do you know who are using either perl or scheme for their default shell. ;-) Dov ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The Mark Shuttleworth offer
On Fri, Mar 19, 2004 at 08:56:36AM +0100, Henrik Brix Andersen wrote: [stuff deleted] The only thing that struck me as missing was the work involved with porting the plug-ins to the new API, but Raphaël already pointed that out in another reply to this thread. I very much hope that at least this time around, since so much is anyhow changed, the PDB will finally get the face lift and use named parameters instead of positional ones. Regards, Dov Sincerely, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] image processing
Hi Gianluca, This question has really nothing to do with Gimp unless you want to use already existing gimp functionality. You may e.g. read an image into memory though the gdk_pixbuf functions, and then access the pixel data through gdk_pixbuf_get_buf(). Working with the gimp API is more complicated as the data may be stored tiled, and your algorithm will need to do special case treatement of the boundries. You might also want to have a look at GEGL that provides a graph paradigm for image processing, and which will be used in future versions of GIMP. Whether someone has written optimized algorithms for it, I don't know. Regards, Dov On Thu, Mar 18, 2004 at 10:12:02AM +0100, Mattiroli, Gianluca wrote: Hi to all, I am interested in doing some filtering on an image stored in memory as a Pixmap, with particular attention to the time constraints. Could someone give me some advice about the resources available for this purpose? Thank you. Gianluca ___ 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] Dicom plug-in for gimp
Hello, I have written a Dicom format plug-in for gimp. Dicom is a standard for medical apparatus and includes an image format which this plug-in partially supports for reading and writing. Here are some links about Dicom: http://medical.nema.org/ http://www.psychology.nottingham.ac.uk/staff/cr1/dicom.html I have attached the source for it to bug report #126521 . Sven wanted to have a discussion whether this plug-in should be included by default in gimp. So, the question is, do you want to improve your X-Ray images (and in the process change your name to Wilber Doe, which is the value for the Patient name tag of all dicom files written by the plug-in) ;-)? Regards, Dov ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Suggestions + Patch, Redo - Part 1
On Sat, Jun 28, 2003 at 12:20:26PM +0200, Jakub Steiner wrote: On Sat, 2003-06-28 at 01:13, [EMAIL PROTECTED] wrote: Then this looks like a serious issue, since this feature is probably not used often by advanced users, but often by beginners, while the dynamic shortcuts are used as quick-assign-keys by advanced users. The feature will be quite often used by very advanced users who run out available shortcuts and will start using mnemomics for common functions (there can be a lot more mnemonics than shortcuts - they are multi-dimensional; gaussian blur could be accessed with a sequence alt+f,b,g for example). Wouldn't it be nice if you could do: Meta-x ^h to popup a window of available combinations. Or Meta-x gausstab-blurenter and of course Meta-x Meta-p to rerun the last plug-in. Beginner users would probably not use these combinations, but for power users emacs is the sky. ;-) Regards, Dov [rest of email deleted] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: red-eye-removal (was: Debugging?)
I just had a look at the two plug-ins for fun of it and they doing part of the problem differently, which means that the perl program looks more complicated than necessarry. The scheme plugin uses the plug-in plug-in-colors-channel-mixer to do the actual color mixing, whereas the perl plug-in accesses the pixels itself. Accessing pixels always gets dirty, because of the tile based approach of gimp. Actually, I think that Marc Lehmann's use of PDL for the job is very elegant. But I'm sure that it can be confusing to have to learn another huge sublanguage (which PDL is). So if you want to compare syntax, please compare the same approach in the different languages. I'm curious, does the python plug-in allow you to access the pixels? Regards, Dov On Mon, Jun 16, 2003 at 02:04:52AM -0400, Carol Spears wrote: On 2003-06-15 at 2031.16 -0700, Jeff Trefftzs typed this: Debugging: you might try firing up the script-fu console in the GIMP and testing code snippets there. I've found this to work fairly well. My main problem is getting my head back into lisp space ... Eeek! Jeff, just say no! all three versions of gimp i have used, 1.0 1.2 and 1.3 have a nifty python plug-in complete with browser and console as well. today i read two plug-ins for red-eye removal. the script-fu just looked like gibberish: http://cs.uhh.hawaii.edu/~jeschke/photography/articles/gimp/RedEye2/red-eye.scm this one. this was the saddest thing i ever read. i never want to read something this sad again. please. it is not the authors fault. it is not the fault of the person who ported gimp to it. nor the gtk guy that did it. not the original authors of this scripting language either. i don't know why it is so sad. you have to stop making me try to read this. mercy! http://fmg-www.cs.ucla.edu/fmg-members/geoff/digicam/redeye i would like to read it written in python. it is direct and the modular part is starting to make sense to me. it makes me angry (okay frustrated) not sad. that is better. please someone write this in python quick so we can compare before i forget! carol -- The sooner you fall behind, the more time you have to catch up. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer -- ___ ___ / o \ o \ Dov Grobgeld ( o o ) o | The Weizmann Institute of Science, Israel \ o /o o / Where the tree of wisdom carries oranges | | | | _| |_ _| |_ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Preview widget name
While we are at it. The two characters Fu to represent A uniform interface that allows setting parameters for the execution of a sequence of gimp functions where each type of parameter has a fixed GUI mapping is much weirder, imho. And that is exposed to the user, which Prevue would not be... Regards, Dov On Wed, Apr 02, 2003 at 05:48:44PM -0600, Brian Mullin wrote: I do see those sorts of spellings from time to time, yes. The same thing with prevu. But, to answer your question... Yes, GimpPrevue does look kind of weird. It does to me, at any rate. :) Brian Mullin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ernst Lippe Sent: Wednesday, April 02, 2003 5:24 PM To: Gimp-developer Subject: Preview widget name My Webster's lists prevue as a synonym for preview (to me this appears to be the original French root of the word). Does GimpPrevue sound very weird for native English speakers? greetings, Ernst Lippe ___ 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 -- ___ ___ / o \ o \ Dov Grobgeld ( o o ) o | The Weizmann Institute of Science, Israel \ o /o o / Where the tree of wisdom carries oranges | | | | _| |_ _| |_ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-user] Opening Photoshop Files
Hebrew with vowel positioning has also been ported by me to ft2. See http://imagic.weizmann.ac.il/~dov/Hebrew/pango-hebrew.html http://imagic.weizmann.ac.il/~dov/freesw/paps for some screen shots and utilities. Regards, Dov On Sun, Feb 10, 2002 at 07:22:09PM +0100, Sven Neumann wrote: Hi, Dov Grobgeld [EMAIL PROTECTED] writes: yes, it will use Freetype2 but somewhat hidden behind a Pango layer. The advantage of using Pango on top of Freetype2 is that it takes care of all the ugly details of glyph positioning and shaping. And you get all the beautiful rendering of lots of exotic scripts! Imagine, now you will be able to render your APL programs in Gimp with comments in Chinese and Runes intermixed. 8-) This is really the way to go! Keep it up. uhm, yes, that's the plan. The reality is however that PangoFT2 at the moment has the basic shaper which works well for lots of scripts but not so well for the more exotic ones. Then there's an arabic shaper that's been added in the latest release and that's it. If we want all the exotic scripts to render correctly, someone needs to port more PangoXft shaper modules to PangoFT2. Fortunately the porting is pretty straightforward. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
