[Gimp-developer] WMF on GIMP
Hi I want to use WMF on my C/GTK application As such, when i try to open a WMF on the GIMP or on my application, the image is set to a specific size on its own and hence it gets distorted.. Can anybody give a solution for this? Thanks in advance Uma
Re: [Gimp-developer] script fu and image file support?
On 8/24/05, Michael Schumacher <[EMAIL PROTECTED]> wrote: > If you make sure that GCC can build it, use stuff that'savailable on any > platform (Hint: make heavy use of glib functions), make the plug-in > available at http://registry.gimp.org and announce new releases on the > gimp mailinglists, you won't have to worry about win32 binaries. Hmm... would this approach also let me support power pc people? If so, I think I'm happy. (Thanks) ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] script fu and image file support?
woc wrote: > On 8/24/05, michael chang <[EMAIL PROTECTED]> wrote: > >> The only "portability" issue here is that you'd need to compile it >> on all target OS's. No big deal -- that's how GIMP is made >> anyways. Use MinGW for Windows, and Linux uses the GCC and related >> tools. Easy enough. > > Which means I'd have to mess around with getting access to the right > development environment every time I needed to make a change. (And I > do anticipate needing to make changes.) If you make sure that GCC can build it, use stuff that'savailable on any platform (Hint: make heavy use of glib functions), make the plug-in available at http://registry.gimp.org and announce new releases on the gimp mailinglists, you won't have to worry about win32 binaries. HTH, Michael -- The GIMP > http://www.gimp.org | IRC: irc://irc.gimp.org/gimp Wiki > http://wiki.gimp.org | .de: http://gimpforum.de Plug-ins > http://registry.gimp.org | ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] script fu and image file support?
On Thursday 25 August 2005 00:58, woc wrote: > I'd have to mess around with getting access to the right > development environment every time I needed to make a change. > (And I do anticipate needing to make changes.) Shouldn't be a big issue. For MS-Windows, go to CygWin.com and click on the "install" link. You're only a few clicks and a big wait (seconds over ethernet from a mirror, minutes over ADSL, maybe a couple of hours of dialup) away from a complete toolkit. On most Linux distros, getting the complete development environment installed is a one-liner. On Mandrive 10.2/2005 it goes like this: urpmi gcc 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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] script fu and image file support?
On 8/24/05, michael chang <[EMAIL PROTECTED]> wrote: > I presume you mean this in the sense that you'd want to write it and > distribute it as-is for your users in this cases? Yep -- plain text is ideal, but I can deal with other formats if I have to. > If you want, you can always cross compile for Windows on > a Linux system, and develop on Linux. (Not sure about vice-versa.) As long as they're using something that runs i386, sure. Cross compiling for other architectures gets into painful issues. And, today, probably everyone I care about could run gimp on windows on a platform that'll run i386 binaries. Should I expect things to always be this way? (woc) ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] script fu and image file support?
On 8/24/05, woc <[EMAIL PROTECTED]> wrote: > On 8/24/05, Manish Singh <[EMAIL PROTECTED]> wrote: > > Yeah, and you contradicted this statement when you said that C wasn't > > portable enough for you. There are differing definitions of what > > "portability" means. > > C is definitely less portable than I'd like. I presume you mean this in the sense that you'd want to write it and distribute it as-is for your users in this cases? If you want, you can always cross compile for Windows on a Linux system, and develop on Linux. (Not sure about vice-versa.) Mac OS X, IIRC, comes with a compiler; Linux might, if you specify it, but various people use deb binaries or rpms. *sighs* If Windows compatability isn't a issue immediately (future problem) then, of course, Python would be the way to go for your circumstance. >From what I gather, many people seem to use the Python bindings. > I really do appreciate you helping me get oriented. That is quite > useful -- I'm sure you've saved me days or weeks of searching the docs > for how to make script fu work when basically I would have been wrong > to try that route. At least that got straightened out. -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] script fu and image file support?
On 8/24/05, Manish Singh <[EMAIL PROTECTED]> wrote: > Well, the python bindings are disted with GIMP, though not on Windows. > This will change with GIMP 2.4 though. > > If you care about Windows, you should've said so from the beginning. ;) > You're basically stuck with C for 2.2, script-fu won't cut it. ... and I was almost sure I mentioned that portability is a priority for me. I apologize for failng to ennumerate the current and potential future platforms I might hope to let people use. Oh well, looks like C it is, with all the non-portability that implies. I was hoping for more generic abstractions. Thanks! (woc) ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Digital Noise Reduction in GIMP
Le 24.08.2005 15:22:45, Jakub Steiner a écrit : On Wed, 2005-08-24 at 13:16 +0200, Alex Fernandez wrote: > - Is there a noise reduction technique / plugin for GIMP that I haven't found? > - Where can I upload the result of my own efforts so that people can > try it out or even improve it? Hi Alex, unsharp mask you mention is generally used for sharpening, which tends to actually increase the visibility of noise. Some techniques for getting rid of noise are described on the gimp website - http://www.gimp.org/tutorials/Reducing_CCD_Noise/ http://www.gimp.org/tutorials/Selective_Gaussian_Blur/ I have recently found an interesting way to get rid of RGB independent noise - http://jimmac.musichall.cz/weblog.php/Photos/RGBNoise.php, but weren't so lucky in replacing the median filter with gimp's despeckle. In the end, selective gaussian blur is what works for me best. The place for 3rd party gimp plugins and scripts is registry.gimp.org, it includes a few noise removal gems. You can try gaussian blur only on red and blue channels leaving green channel untouched (it is generally less affected by noise and will help to keep a raisonably sharp image after applying the blur). cheers -- Jakub Steiner <[EMAIL PROTECTED]> Jean-Luc pgpW7A3bw5mP9.pgp Description: PGP signature
Re: [Gimp-developer] script fu and image file support?
On 8/24/05, Manish Singh <[EMAIL PROTECTED]> wrote: > Yeah, and you contradicted this statement when you said that C wasn't > portable enough for you. There are differing definitions of what > "portability" means. C is definitely less portable than I'd like. Unfortunately, it looks like it's as portable as I'm going to get unless I abandon the gimp entirely or wait a few years for a better version. (Which I might, but I'll try following your recommendations first. I just wanted to make sure my priorities were understood before I jumped in blind.) I really do appreciate you helping me get oriented. That is quite useful -- I'm sure you've saved me days or weeks of searching the docs for how to make script fu work when basically I would have been wrong to try that route. (woc) ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] script fu and image file support?
On Wed, Aug 24, 2005 at 02:34:28PM -0400, woc wrote: > On 8/24/05, Manish Singh <[EMAIL PROTECTED]> wrote: > > Well, the python bindings are disted with GIMP, though not on Windows. > > This will change with GIMP 2.4 though. > > > > If you care about Windows, you should've said so from the beginning. ;) > > You're basically stuck with C for 2.2, script-fu won't cut it. > > ... and I was almost sure I mentioned that portability is a priority for me. > I apologize for failng to ennumerate the current and potential > future platforms I might hope to let people use. Yeah, and you contradicted this statement when you said that C wasn't portable enough for you. There are differing definitions of what "portability" means. > Oh well, looks like C it is, with all the non-portability that implies. > I was hoping for more generic abstractions. You could patch script-fu to do what you want, or you could deploy pygimp or gimp-perl to your users, since they are running a custom app anyway... It's up to you how much you want to constrain yourself. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] script fu and image file support?
On Wed, Aug 24, 2005 at 01:49:50PM -0400, woc wrote: > On 8/24/05, Manish Singh <[EMAIL PROTECTED]> wrote: > > You can use Perl or Python to write a file format plugin. Script-fu is a > > nonstarter, there's no way to register a load/save handler from a script > > (though there could be in the future). Script-fu sucks for this for > > other reasons, as others have told you already. > > > > You can actually do things with reasonable efficiency in both Perl and > > Python, since you get the pixel region abstraction just as you do in C. > > There's a save plugin example that comes with both the Perl and Python > > bindings. > > Hmm... in my opinion C is more portable than perl or python, in the > context of the gimp. > > If the standard gimp distribution contained those bindings, I'd probably > think differently. Well, the python bindings are disted with GIMP, though not on Windows. This will change with GIMP 2.4 though. If you care about Windows, you should've said so from the beginning. ;) You're basically stuck with C for 2.2, script-fu won't cut it. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] script fu and image file support?
On 8/24/05, Manish Singh <[EMAIL PROTECTED]> wrote: > You can use Perl or Python to write a file format plugin. Script-fu is a > nonstarter, there's no way to register a load/save handler from a script > (though there could be in the future). Script-fu sucks for this for > other reasons, as others have told you already. > > You can actually do things with reasonable efficiency in both Perl and > Python, since you get the pixel region abstraction just as you do in C. > There's a save plugin example that comes with both the Perl and Python > bindings. Hmm... in my opinion C is more portable than perl or python, in the context of the gimp. If the standard gimp distribution contained those bindings, I'd probably think differently. But thanks for the suggestion! (woc) ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [Gimp-developer] Gimp_image_delete and adding text layers
> top isn't actually a very accurate way of profiling memory usage. The > numbers you have shown so far can easily be explained by memory > fragmentation and the fact that glibc allocates memory in pools. > Smaller memory fragments are not returned to the operating system but > are being kept for reuse in the application. Please run your script a > lot more often and see if there's a significant increase in memory. > > > Sven I have a test script that does the following: Gimp::init; my $img = gimp_image_new(300, 200, 0); $img->gimp_image_undo_disable; my $layer = gimp_layer_new($img, 300,200,RGB, "Layer 2", 100, NORMAL_MODE); gimp_image_add_layer($img, $layer, -1); my $text_layer = gimp_text_fontname($img,-1,0,0,"", 0, 0, 14, 0, "Arial Bold"); gimp_image_merge_down($img, $text_layer, CLIP_TO_BOTTOM_LAYER); my $text_layer2 = gimp_text_fontname($img,-1,0,10,"2", 0, 0, 14, 0, "Arial Bold"); gimp_image_merge_down($img, $text_layer2, CLIP_TO_BOTTOM_LAYER); my $text_layer3 = gimp_text_fontname($img,-1,0,20,"3", 0, 0, 14, 0, "Arial Bold"); gimp_image_merge_down($img, $text_layer3, CLIP_TO_BOTTOM_LAYER); my $text_layer4 = gimp_text_fontname($img,-1,0,30,"44", 0, 0, 14, 0, "Arial Bold"); gimp_image_merge_down($img, $text_layer4, CLIP_TO_BOTTOM_LAYER); my $text_layer5 = gimp_text_fontname($img,-1,0,40,"555", 0, 0, 14, 0, "Arial Bold"); gimp_image_merge_down($img, $text_layer5, CLIP_TO_BOTTOM_LAYER); my $text_layer6 = gimp_text_fontname($img,-1,0,50,"6", 0, 0, 14, 0, "Arial Bold"); gimp_image_merge_down($img, $text_layer6, CLIP_TO_BOTTOM_LAYER); $img->gimp_image_undo_enable; gimp_image_delete($img); Gimp::end; This script gets run 5000 times in a loop, and it's the only script accessing the gimp instance. I see no change in the perl-server and script fu processes, but I do see an increase for gimp. I'm not sure how significant the increase is as I have to run the script quite a bit, but this is what I see after running several loops and using top after each loop: Start up: VIRT RES SHR S %CPU %MEMTIME+ COMMAND 17632 7448 13m S 0.0 1.4 0:01.14 gimp Loop 1: VIRT RES SHR S %CPU %MEMTIME+ COMMAND 21088 11m 13m S 0.0 2.2 11:45.59 gimp Loop 2: VIRT RES SHR S %CPU %MEMTIME+ COMMAND 25544 14m 13m S 0.0 2.9 23:28.40 gimp Loop 3: VIRT RES SHR S %CPU %MEMTIME+ COMMAND 27796 17m 13m S 0.0 3.5 35:11.54 gimp Loop 4: VIRT RES SHR S %CPU %MEMTIME+ COMMAND 31408 21m 13m S 0.0 4.2 46:54.84 gimp Loop 5: VIRT RES SHR S %CPU %MEMTIME+ COMMAND 35220 24m 13m S 0.0 4.8 58:35.12 gimp Loop 6: VIRT RES SHR S %CPU %MEMTIME+ COMMAND 38108 27m 13m S 0.0 5.5 70:11.92 gimp Loop 7: VIRT RES SHR S %CPU %MEMTIME+ COMMAND 42292 31m 13m S 0.0 6.2 81:51.41 gimp Thanks, Jared ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] script fu and image file support?
On Wed, Aug 24, 2005 at 12:58:35PM -0400, woc wrote: > On 8/24/05, michael chang <[EMAIL PROTECTED]> wrote: > > Perl probably has similar limitations, to a certain extent. Perl > > handles text best -- binary data, it's best at simply passing... I > > believe the term is ad verbatim or something. > > So it takes a second or two to convert an image using perl. Longer > if it's a format varient where pixels adjacent visually aren't stored adjacent > to each other, or some of those format variants. This costs what, a few > minutes out of a day? Anyone using this image format is going to have > to spend considerably longer than that just to load it into the > environment which uses these images. > > Speed is not one of my priorities. Simplicity is. You can use Perl or Python to write a file format plugin. Script-fu is a nonstarter, there's no way to register a load/save handler from a script (though there could be in the future). Script-fu sucks for this for other reasons, as others have told you already. You can actually do things with reasonable efficiency in both Perl and Python, since you get the pixel region abstraction just as you do in C. There's a save plugin example that comes with both the Perl and Python bindings. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] script fu and image file support?
On 8/24/05, Shlomi Fish <[EMAIL PROTECTED]> wrote: > While Perl has many facilities for handling text very well, it does not have > any limitations with handling binary data. It can easily segment such data, > convert it from ASCII to binary, generate it, etc. Perl strings can contain > \0 characters, and thus can represent binary data. Several functions in the > perlfunc man page can be used to manipulate binary data (like pack() and > unpack()), and often text-oriented functions that are operated on binary data > will also work. A similar functionality should be available for programming > languages that are similar to Perl. > > The main problem with using Perl for this job is that processing thousands or > millions of Pixels in Perl may be considerably slower than in C, due to the > fact executing expressions, conditionals and loops in Perl has much more > speed overhead over their C counterparts. Thus, it is recommended to write an > image loader in C. > > But handling binary data alone is not the problem here. It is not harder in > Perl than in C, albeit may be (like many other tasks) slower. Exactly. I'm using pack, unpack and substr in perl. This works quite well. And "slower" means "a second or two instead of a fraction of a second". For what I'm dealing with, this is a minor issue. My interest is in breaking new ground. There's sometimes other people who are happy to write and support fast C code -- they sometimes use what I've written as a design basis, and more power to them. That's less maintenance work for me. But I'm guessing what people are saying is that even with the gimp bindings, SIOD doesn't have enough relevant type punning features, so it'll be considerably slower than using perl to just write a different kind of image file. In other words, I can't use the "everything is a sequence of bytes" mechanism for representing image data? (woc) ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] script fu and image file support?
On 8/24/05, michael chang <[EMAIL PROTECTED]> wrote: > The only "portability" issue here is that you'd need to compile it on > all target OS's. No big deal -- that's how GIMP is made anyways. Use > MinGW for Windows, and Linux uses the GCC and related tools. Easy > enough. Which means I'd have to mess around with getting access to the right development environment every time I needed to make a change. (And I do anticipate needing to make changes.) > Script-Fu only has the "advantage" of not requiring compilation before > execution, but it doesn't handle Raw IO or pixel-based image creation > IIRC (for good reason, too, proally). > > Perl probably has similar limitations, to a certain extent. Perl > handles text best -- binary data, it's best at simply passing... I > believe the term is ad verbatim or something. So it takes a second or two to convert an image using perl. Longer if it's a format varient where pixels adjacent visually aren't stored adjacent to each other, or some of those format variants. This costs what, a few minutes out of a day? Anyone using this image format is going to have to spend considerably longer than that just to load it into the environment which uses these images. Speed is not one of my priorities. Simplicity is. > Try copying a C image format plugin that already exists, maybe (e.g. xbm)? BMP and TGA are closer than XBM (all the image formats are binary pixel formats with a short header at the front. Some of the details can get strange, but those tend to be issues unique to this format.) But I'll take a look at XBM to see if it deals with multiple layers. Sure, GIMP is written using C, but I'm not planning on building or distributing the GIMP. I suppose I can try doing this in C, but shudder at the time I'm going to have to spend, building and maintaining those binaries. (woc) ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Digital Noise Reduction in GIMP
On Wednesday 24 August 2005 06:22 am, Jakub Steiner wrote: > On Wed, 2005-08-24 at 13:16 +0200, Alex Fernandez wrote: > > - Is there a noise reduction technique / plugin for GIMP that I haven't > > found? - Where can I upload the result of my own efforts so that people > > can try it out or even improve it? > > Hi Alex, > unsharp mask you mention is generally used for sharpening, which tends > to actually increase the visibility of noise. Some techniques for > getting rid of noise are described on the gimp website - > > http://www.gimp.org/tutorials/Reducing_CCD_Noise/ > http://www.gimp.org/tutorials/Selective_Gaussian_Blur/ > > I have recently found an interesting way to get rid of RGB independent > noise - http://jimmac.musichall.cz/weblog.php/Photos/RGBNoise.php, but > weren't so lucky in replacing the median filter with gimp's despeckle. > In the end, selective gaussian blur is what works for me best. > > The place for 3rd party gimp plugins and scripts is registry.gimp.org, > it includes a few noise removal gems. > > cheers You might give the GREYCstoration plug-in a try. It also installs a standalone command line program that can do noise reduction to 16 bit images. The controls are not well documented and I have found that values that work for me are MUCH different from the values that the controls default to. Also the preview in the plug-in is next to useless. But once you figure out what setting work best it is a very powerful tool. Hal ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] script fu and image file support?
On Wednesday 24 August 2005 15:48, michael chang wrote: > On 8/23/05, woc <[EMAIL PROTECTED]> wrote: > > I do not want to write a .c plugin, because portability is more > > important to me than speed. > > Gimp itself is written in some variant of C, isn't it? > Right. ANSI C 89' with some extensions that are common enough to rely on. > The only "portability" issue here is that you'd need to compile it on > all target OS's. No big deal -- that's how GIMP is made anyways. Use > MinGW for Windows, and Linux uses the GCC and related tools. Easy > enough. Right. > > Script-Fu only has the "advantage" of not requiring compilation before > execution, but it doesn't handle Raw IO or pixel-based image creation > IIRC (for good reason, too, proally). You can theoretically draw on an image using a 1*1 pixels brush. But this would be very slow. > > Perl probably has similar limitations, to a certain extent. Perl > handles text best -- binary data, it's best at simply passing... I > believe the term is ad verbatim or something. While Perl has many facilities for handling text very well, it does not have any limitations with handling binary data. It can easily segment such data, convert it from ASCII to binary, generate it, etc. Perl strings can contain \0 characters, and thus can represent binary data. Several functions in the perlfunc man page can be used to manipulate binary data (like pack() and unpack()), and often text-oriented functions that are operated on binary data will also work. A similar functionality should be available for programming languages that are similar to Perl. The main problem with using Perl for this job is that processing thousands or millions of Pixels in Perl may be considerably slower than in C, due to the fact executing expressions, conditionals and loops in Perl has much more speed overhead over their C counterparts. Thus, it is recommended to write an image loader in C. But handling binary data alone is not the problem here. It is not harder in Perl than in C, albeit may be (like many other tasks) slower. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ Tcl is LISP on drugs. Using strings instead of S-expressions for closures is Evil with one of those gigantic E's you can find at the beginning of paragraphs. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] script fu and image file support?
On 8/23/05, woc <[EMAIL PROTECTED]> wrote: > I do not want to write a .c plugin, because portability is more > important to me than speed. Gimp itself is written in some variant of C, isn't it? The only "portability" issue here is that you'd need to compile it on all target OS's. No big deal -- that's how GIMP is made anyways. Use MinGW for Windows, and Linux uses the GCC and related tools. Easy enough. Script-Fu only has the "advantage" of not requiring compilation before execution, but it doesn't handle Raw IO or pixel-based image creation IIRC (for good reason, too, proally). Perl probably has similar limitations, to a certain extent. Perl handles text best -- binary data, it's best at simply passing... I believe the term is ad verbatim or something. Try copying a C image format plugin that already exists, maybe (e.g. xbm)? -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Digital Noise Reduction in GIMP
On Wed, 2005-08-24 at 13:16 +0200, Alex Fernandez wrote: > - Is there a noise reduction technique / plugin for GIMP that I haven't > found? > - Where can I upload the result of my own efforts so that people can > try it out or even improve it? Hi Alex, unsharp mask you mention is generally used for sharpening, which tends to actually increase the visibility of noise. Some techniques for getting rid of noise are described on the gimp website - http://www.gimp.org/tutorials/Reducing_CCD_Noise/ http://www.gimp.org/tutorials/Selective_Gaussian_Blur/ I have recently found an interesting way to get rid of RGB independent noise - http://jimmac.musichall.cz/weblog.php/Photos/RGBNoise.php, but weren't so lucky in replacing the median filter with gimp's despeckle. In the end, selective gaussian blur is what works for me best. The place for 3rd party gimp plugins and scripts is registry.gimp.org, it includes a few noise removal gems. cheers -- Jakub Steiner <[EMAIL PROTECTED]> Novell, Inc. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Digital Noise Reduction in GIMP
Hi list, I'm interested in noise reduction using GIMP. A little (skippable) background first. I recently bought a digital camera, a very nice Canon IXUS 40. One big plus over traditional "chemical" photography is that you can change sensitivity for poor light conditions. However, this increases noise in the resulting image. Digital noise tends to be uglier than its analog counterpart, I'm not sure why; maybe we will get used to it eventually, or maybe not. In the meantime, digital noise is quite annoying. Since the picture is already in the computer, I tried to GIMP the noise off, but had no luck. People seem to use "unsharp mask", but the results are frankly quite poor. I have found several programs that seem to do the trick more or less, but all of them proprietary and all of them for Mac / PC (I'm on Linux). Of course, none work with GIMP. So after many offroads (like improving on Remi's excellent FFT plugin), and being of the geek persuasion, I tried to create my own GIMP plugin. It has been a very interesting process, and results are not bad even at this preliminary stage. I have used several algorithms (stdev discrimination, linear regression); right now I'm trying out a combination of median and interquartile range which is promising, but still not perfect. Now, let's go to the questions. - Is there a noise reduction technique / plugin for GIMP that I haven't found? - Where can I upload the result of my own efforts so that people can try it out or even improve it? - Do you know any algorithms that work really well for noise reduction? I came across this message: http://www.mail-archive.com/gimp-developer@lists.xcf.berkeley.edu/msg08651.html so if someone can point me to the paper mentioned or similar, I would be most grateful. Thanks, Alex. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] script fu and image file support?
Hi, woc <[EMAIL PROTECTED]> writes: > Can someone point me at: > > * gimp 2.2 load/save support for some type of file written in > script-fu? Or, > > * a concise reference work describing the data types I'd need to deal > with and their fundamental support routines? Or, > > * a faq which is specific to this topic (script fu support for > load/save)? Or, Script-Fu isn't designed to access images at the pixel level. It is probably not impossible to write an image loader in Script-Fu but it would be teribly slow. In other words, I wouldn't even attempt to do that. C is a very portable language, I don't understand why you aren't willing to use it. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
