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@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
