Re: [Gimp-developer] Code cleanup in unsharp-mask.c and possible speed enhancement
Dang. I wish I knew that before I coded up the box blur... Does this mean that I would have to code up a new plugin from scratch, or is there a GEGL version of it out there already? (Sorry, I'm totally unfamiliar with this GEGL stuff.) -Winston On Thu, Jan 15, 2009 at 1:43 AM, Martin Nordholts wrote: > Winston Chang wrote: > > I took a look at the svn history of unsharp-mask.c (I'm the original > > author) and saw that the fix for bug #166406 stopped using a lookup > > table called ctable. This was because it slowed things down a lot for > > large values of radius, due to cache overloading. > > http://bugzilla.gnome.org/show_bug.cgi?id=166406 > > > > After the fix, the lookup table is no longer being used for the > > blurring algorithm, but it's still being generated and traversed > > during the blur, so I have a patch that removes all that useless code, > > without affecting functionality at all. What's the best way to submit > > it, as I can't commit to the SVN repository? > > > Hi! > > I want to mention that since we are in the progress of migrating to GEGL > we generally prefer that people make sure the GEGL counterpart works > well rather than maintaining the legacy 8 bpc code. A patch for GEGL is > much more attractive than a patch for an old GIMP plug-in. > > That being said, the best way to submit patches is to open a bug report > at bugs.gimp.org and attach it there. > > BR, > Martin > ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Code cleanup in unsharp-mask.c and possible speed enhancement
Winston Chang wrote: > I took a look at the svn history of unsharp-mask.c (I'm the original > author) and saw that the fix for bug #166406 stopped using a lookup > table called ctable. This was because it slowed things down a lot for > large values of radius, due to cache overloading. > http://bugzilla.gnome.org/show_bug.cgi?id=166406 > > After the fix, the lookup table is no longer being used for the > blurring algorithm, but it's still being generated and traversed > during the blur, so I have a patch that removes all that useless code, > without affecting functionality at all. What's the best way to submit > it, as I can't commit to the SVN repository? Hi! I want to mention that since we are in the progress of migrating to GEGL we generally prefer that people make sure the GEGL counterpart works well rather than maintaining the legacy 8 bpc code. A patch for GEGL is much more attractive than a patch for an old GIMP plug-in. That being said, the best way to submit patches is to open a bug report at bugs.gimp.org and attach it there. BR, Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Code cleanup in unsharp-mask.c and possible speed enhancement
> > Also, I've read recently that a three-pass box blur is close to a true > gaussian blur (within 3% when std_dev>2.0) so I'm considering implementing > that for the unsharp mask. It should be much faster while still looking very > good. > > More info on the 3-pass box blur here: > http://www.w3.org/TR/SVG/filters.html#feGaussianBlur > The algorithm listed here, d = floor(s * 3*sqrt(2*pi)/4 + 0.5), doesn't > have infinite precision; the smallest step (in standard deviations, AKA > radius) it can take is 0.42 pixels, so I think maybe it would be best to use > the triple-box-blur for values of s that are, say, 10 and higher, and use > the true gaussian for smaller values. But if there's a good reason to use a > different threshold value, please let me know. > > Thoughts on all this? Well, I'll answer my own question... It works pretty well. I still have to run some more tests to make sure I don't have weird off-by-one errors or things like that. Notes: I used a threshold of 10 pixels to switch from the original gaussian method to the new boxblur method. The smallest steps with the new method is about .42, as mentioned in my previous post. Speed: I used a timer that I had coded into the plugin ages ago. I tested this on my Core 2 Quad 2.4GHz. All these tests were run with amount=0.50 and threshold=0, on a 554x841 RGB image (a photograph), and there might be a little randomness in the results (on the order of hundredths of seconds). I compared the new triple-box-blur to the original true gaussian method. radius=11 boxblur: .40s gaussian: .65s radius=24 boxblur .38s gaussian 1.02s radius=80 boxblur 0.42s gaussian 2.30s radius=105 boxblur 0.41s gaussian 2.87s The algorithm is close to constant time, with respect to radius. It should be O(n) with respect to the number of pixels. Correctness: I did an unsharp mask with the new and old algorithms, overlaid them on top of eachother and used difference blending. Running the eyedropper over the image showed that the difference in each channel was between 0 and 3 for almost all pixels. I did see a handful of 4's. That's close enough for me... I have some ideas about how to optimize the code a bit more using pointer arithmetic instead of indexing into arrays the usual way. I recall this having a big effect when I originally wrote the plugin a decade ago, but perhaps compilers have improved a lot since then, making this unnecessary. Anyone out there know about this? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Code cleanup in unsharp-mask.c and possible speed enhancement
I took a look at the svn history of unsharp-mask.c (I'm the original author) and saw that the fix for bug #166406 stopped using a lookup table called ctable. This was because it slowed things down a lot for large values of radius, due to cache overloading. http://bugzilla.gnome.org/show_bug.cgi?id=166406 After the fix, the lookup table is no longer being used for the blurring algorithm, but it's still being generated and traversed during the blur, so I have a patch that removes all that useless code, without affecting functionality at all. What's the best way to submit it, as I can't commit to the SVN repository? Also, I've read recently that a three-pass box blur is close to a true gaussian blur (within 3% when std_dev>2.0) so I'm considering implementing that for the unsharp mask. It should be much faster while still looking very good. More info on the 3-pass box blur here: http://www.w3.org/TR/SVG/filters.html#feGaussianBlur The algorithm listed here, d = floor(s * 3*sqrt(2*pi)/4 + 0.5), doesn't have infinite precision; the smallest step (in standard deviations, AKA radius) it can take is 0.42 pixels, so I think maybe it would be best to use the triple-box-blur for values of s that are, say, 10 and higher, and use the true gaussian for smaller values. But if there's a good reason to use a different threshold value, please let me know. Thoughts on all this? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: Re: Gimp license]
gg wrote: > I've always thought the ".. or later" clause in some gpl wording to be a > bit of an odd way to licence something. > > While FSF seems to be doing a solid job until now I always worry about > future GPLs getting knobbbled the way PGP did. > > If GIMP project decides to move to v3 would it be wisest to state > specifically v3 rather than some arbitary unknown "or later"? This seems > an unnecessary risk. > Without the "or later clause" it wouldn't really be a GNU project which isn't much of an alternative. In the worst case, if it turns out the GPLv4 will be a terrible licence someone will just have to fork GIMP when we move to GPLv4+ and maintain a GPLv3 version of GIMP. - Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Artificial limitation to script fu ?
On Mon, 2009-01-12 at 19:00 -0500, saulgo...@flashingtwelve.brickfilms.com wrote: [...] > Perhaps I am misunderstanding; if so, it might be helpful if an actual > change were proposed. How about a new package, gimp-goodies, that contains these scripts, maybe more, and maybe some brushes and textures. Advantages - mainline gimp package is smaller; release cycles can be different... people perceive that there's an extra package of goodies... Disadvantages - it's work to do the separation, and to make a new package. The goodies package would need to be kept in sync for translation purposes, too. Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: Re: Gimp license]
2009/1/14 gg : > I've always thought the ".. or later" clause in some gpl wording to be a > bit of an odd way to licence something. > > While FSF seems to be doing a solid job until now I always worry about > future GPLs getting knobbbled the way PGP did. > > If GIMP project decides to move to v3 would it be wisest to state > specifically v3 rather than some arbitary unknown "or later"? This seems > an unnecessary risk. Consider that if they hadn't used this language for the current v2 or later license, it would be largely impossible to switch to v3 at this point, as formal permission would need to be gotten from _all_ copyright owners (or parts of GIMP would have to be rewritten). Henk ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Roadmap for 2.7 / 2.8 ?
Eckhard M. Jäger wrote: > > Dear Gimp Developers, > > the opensource mag T3N asked me about writing an outlook about GIMP in > 2009 and what users > can expect this year. Hi I here talk a little about what we would like to get into 2.8: http://jcornuz.wordpress.com/2008/12/27/an-exclusive-interview-with-martin-nordholts/ But to be honest I think it is best if this magazine does not write about what GIMP will get in 2009 simply because there is no way to make guarantees. If they write about it they should emphasize that everything is preliminary and not a promise, and that probably won't make the article as exciting as they want. Note that the magazine is free to do what they like though, I just wanted to give my thoughts on it. BR, Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] [Fwd: Re: Gimp license]
--- Begin Message --- Marcus Heese wrote: > I've just contributed a few lines, too. However, I'm fine with GPLv3, too... > I > was wondering a long time that the GIMP hasn't changed the license yet. > > And I hope that the GIMP will stay with GPL in the future, too. Otherwise the > developers should think about the name again! ;) ... *IMP > > best regards > Marcus > ___ > Gimp-developer mailing list > Gimp-developer@lists.XCF.Berkeley.EDU > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer > > I've always thought the ".. or later" clause in some gpl wording to be a bit of an odd way to licence something. While FSF seems to be doing a solid job until now I always worry about future GPLs getting knobbbled the way PGP did. If GIMP project decides to move to v3 would it be wisest to state specifically v3 rather than some arbitary unknown "or later"? This seems an unnecessary risk. /gg --- End Message --- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Roadmap for 2.7 / 2.8 ?
Dear Gimp Developers, the opensource mag T3N asked me about writing an outlook about GIMP in 2009 and what users can expect this year. I can't find any save information or a roadmap about 2.7/ 2.8. Is there a vision/ definition ehat will come this year? Could you help me with it? It mustn't be much detailed. Thanx for your help. Best regards. ___/\___ Ich darf die Kletterstange nicht einfetten. |\/\/\/| | |Bart. | (O)(O)b...@neeneenee.de C _) | ,_/ Linux for Designers - http://my.opera.com/area42/blog/ | / SweeTS delicious Typo3 development - http://typo3.area42.de/ / \ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] a question about hsl saturation calculation.
I tried to go through the source code of hsl saturation calculation. In the file there is a function : void gimp_operation_hue_saturation_map (GimpHueSaturationConfig *config, const GimpRGB *color, GimpHueRange range, GimpRGB *result) it has three step to change saturation. 1.convert RGB into HSL 2. HSL mapping 3. HSL into RGB My question is how does map_saturation() function work, I tried to look into the code and it turn out too complicated for me to understand. Is there any one can explain it to me. Thank you in advance. Chiyu Wang -- Joe E. Lewis - "There's only one thing money won't buy, and that is poverty." ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] R: Gimp-developer Digest, Vol 76, Issue 21
> > I stopped reading here. Please describe your level of > knowledge in Script-Fu before you do continue in this > thread. Maybe what has to be described is the concept of "same", maybe you give to the word "same" a sense to me a bit peculiar but technically much more correct then mine Using "glossy logo.scm" From File /create Logo i see 1 GUI, if i call the same £glossy.logo.scm" from Filter/Alpha to Logo i see a very different GUI The 2 GUI of the "same " glossy.scm script different for the option they offer i.e from GUI 2 are removed option to chose font and text for my Logo...no way to access to that option. But you are right better stop with words i may clear my proposal much better with few images then with words Even if i know a bit of script fu i am much more a artist then a developer so i may explain much better the point with visual examples, So i will took 2 screenshoots to the 2 different GUI of the "same" glossy.scm script. And i will add a mock up of the ideal "glossy.scm" GUI Not sure if i will also able to edit the glossy.scm" for give a even more clear example, should be not too hard add a text selector and a option to export the output on a new imagine to the Filter/Alpha to Logo/glossy script...but this would take me much more time then a mockup ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Artificial limitation to script fu ?
Original-Nachricht > Datum: Wed, 14 Jan 2009 00:53:46 + (GMT) > Von: "Alchemie fotografiche" > An: gimp-developer@lists.XCF.Berkeley.EDU > Betreff: Re: [Gimp-developer] Artificial limitation to script fu ? > > > From: "Michael Schumacher" > > > Just to make sure: does everyone know that it is the same > > script that does register both menu entries? > > > Michael > Not exactly the same script > Same".scm" file for Logo-related script contains 2 script I stopped reading here. Please describe your level of knowledge in Script-Fu before you do continue in this thread. Michael -- Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Excellent review of GIMP 2.6.4 at Ars Technica
Ars Technica has made an excellent review [1] of the fourth bugfix release of GIMP 2.6 that among other things discusses what we are good at and what we can do better. We are aware of most things mentioned but it is very well presented and from the point of view of a professional freelance graphic designer and is my opinion well worth the read for anyone interested in GIMP development. BR, Martin [1] http://arstechnica.com/reviews/apps/gimp-2-6-review.ars ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
