On 07/13/10 19:52, Sven Neumann wrote:
> On Tue, 2010-07-13 at 10:49 +0200, Martin Nordholts wrote:
>> On 07/13/2010 10:28 AM, Przemysław Zych wrote:
>>> As a part of my student project for "Optimizing Open-Source
>>> Applications" at Warsaw University I have speed up despeckle plug-in for
>>> Original version of the plugin run 56seconds for 1024x768 image with
>>> despeckle radius 30 and adaptive flag turned off (on my Intel Macbook
>>> 2.1GHz). My optimized version with the same settings completes the task
>>> in 3.5 seconds with the same image quality :-)
>>> Sources for this optimized plug-in can be downloaded from here:
>>> What should I do to get this to the gimp repository?
>>> Should I change the copyright header?
>> That sounds great.
>> To maximize chances of getting this into GIMP:
>> 1. Create a regression test for the despecle plug-in that is run
>> with 'make check'. This is a great way to convince us that
>> your optimization in fact does not change the output, only
>> improves performance.
> Well, as far as I can see the current implementation of the despeckle
> plug-in does not match the expectations. IMO it is buggy. Thus we should
> not absolutely require that the result does not change. But it would be
> desirable to get fixes to the algorithm submitted separately from
> It would also help a lot if the patch followed the GIMP coding style.
> Please see the file HACKING in the GIMP source tree.
I agree. I had to clean up some photos recently and ended up doing most
of it by hand.
If you code produces the same kind of results with that much of a speed
increase a patch would be worth providing. Kudos for achieving that
level of speed up.
I guess by now you must have got a good feel for the way that part of
the code base works so if you can write a despeckle routing that does
despeckle that would be a worthwhile contribution as well.
Thanks for you efforts.
Gimp-developer mailing list