> > 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?

## Advertising

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