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