Re: [Gimp-developer] Bring Back the Keyboard!
Hi, Joao S. O. Bueno Calligaris [EMAIL PROTECTED] writes: Actually, my problems begun in gedit - I was editing a python script, and certainly, for people on GNU/Linux for the first time, EMACS would not be a suitable option. emacs is using the GTK+ file chooser as well. At least the later CVS snapshots of emacs are. GIMPwise, Sven's suggestions are ok. I like more the idea of actually unhiding the gimp profile directory. Because a separate interface to save images that are to be saved as patterns or brushes, IMHO, would only break things even more. A bookmark to the gimp profile would also work. Of the things accessible through other interfaces, I think there is little left to be done. Could you explain how this would break things? GIMP 2.3 allows you to save the clipboard as brush or pattern, so I am somewhat curious what you consider broken about such an approach. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] [PATCH] Cleanup and speed-up of Gaussian Blur (RLE)
Hi, I sent a email last week but it never made it to the list. It is probably stuck in a moderator mailbox so if you see one with the Speeding up Gaussian Blur (LRE), you can just ignore it. Last week I was chatting with a Photoshop user asking information about Gimp. He mentionned that Gimp was slower and he came up with that example: 11s versus 2s for the RLE Gaussian Blur on a 6MP digital camera picture. So I decided to have a look and I came up with a faster version of plug-ins/common/gauss.c from 2.3.7. There was quite a few changes and the patch is too big to be posted here without moderator approval (40K) so you can pick it from my web site: http://www.chauveau-central.net/gauss.c On my PC, my version is usually 2 to 4 times faster than the original on large photos. On large bitmaps, it is usually a bit faster (~25%). I won't list all the changes but here is a summary: - IIR and RLE are now separated in two different functions. That does not improve the speed but this is cleaner. The IIR algo was not modified significantly (I looked at it and I think that it should be possible to speed it up by 25% at least). - the function run_length_encode() was cleaned and should be faster. This is not where most of the time is spent so the effective gain is small. - for each row/column, the function run_length_encode() now provides additionnal information: (a) extended borders on the pixel vector and on the rle vector. (b) the number of repeating pixels. - the modification (a) makes run_length_encode a bit slower but as a side effect, the following gauss loop is faster since the special border cases do not have to be considered anymore. The overall gain is significant. - the modification (b) allows to detect which rows or columns have enough repeating pixels to be efficiently processed using their run-length-encoding. RLE has an intrinsic cost ( more complex loop versus less computation ) and is really interesting if, on average, more than 2 or 3 identical pixels can be treated simultaneously. If the row/columns does not show enough repeating pixels (that is usally the case in digital camera photos), then a more simple loop is used. This is where most of the speed-up comes from. - I reduced the frequency of the updates of the progress-meter. It was originally performed every 5 rows or columns. On a typical 6MP image (3000x2000) it was done (3000+2000)/5 = 1000 times. Some crude mesurements seemed to indicate that between 10% to 20% of the total time was spent in the progress update. This adaptative approach makes the RLE algorithm efficient on all types of images. On large photos, it is even faster than the current IIR for a radius up to 30. A lot Gimp plugins implement their own version of the gaussian blur (dog, unsharp, softglow, ...) so, if the patch is accepted, I think that it would make sense to move the core functions to a separate C file that could be reused by those plugins. Stephane Chauveau ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Image size limit of GIMP Image SDK
Hi, I am not sure if it is suitable to ask this question here. But itmakes me crazy for many days. I am looking for an image SDK which can process an image of size, for example, more than 1GB. I tried to open an image file(*.tiff) of size 800MB GIMP on my computer, WinXP,PIV 2.4GHZ, and 1GB memory. It istoo slow. It is impossible to edit it.Since tiled tiff can be used to store/process large image, I am wondering if GIMP makes use of it. If not, can anyone do me a favor to let me know what SDK I can use? Sorry for the spam Thanks a million in advance Limin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Image size limit of GIMP Image SDK
Hint- buy some more ram. - I have edited some 1.8gig images on a PC with 4gig of ram using the gimp, its not that fast- but it was useable. I know you probably want an sdk that can handle images bigger then your physical memory- but you cant have the best of all worlds. Large images + Low Ram + Fast editing just isnt that possible- unless the operations can be edited on tiles as you suggest. not all func's can be tiled, so probably to save your self some time - buy a 1gig chip. Limin Zhang wrote: Hi, I am not sure if it is suitable to ask this question here. But it makes me crazy for many days. I am looking for an image SDK which can process an image of size, for example, more than 1GB. I tried to open an image file(*.tiff) of size 800MB GIMP on my computer, WinXP, PIV 2.4GHZ, and 1GB memory. It is too slow. It is impossible to edit it. Since tiled tiff can be used to store/process large image, I am wondering if GIMP makes use of it. If not, can anyone do me a favor to let me know what SDK I can use? Sorry for the spam Thanks a million in advance Limin ___ 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
Re: [Gimp-developer] [PATCH] Cleanup and speed-up of Gaussian Blur (RLE)
Hi, Stephane Chauveau [EMAIL PROTECTED] writes: So I decided to have a look and I came up with a faster version of plug-ins/common/gauss.c from 2.3.7. There was quite a few changes and the patch is too big to be posted here without moderator approval (40K) so you can pick it from my web site: http://www.chauveau-central.net/gauss.c Can you please file a bug report for this change and attach a unified diff to it? I will then make sure your changes go into CVS as soon as possible. A lot Gimp plugins implement their own version of the gaussian blur (dog, unsharp, softglow, ...) so, if the patch is accepted, I think that it would make sense to move the core functions to a separate C file that could be reused by those plugins. Perhaps it should go into libgimpmath? Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
