Monday, July 31, 2006

More blurring

Jani Huhtanen was kind enough to let me know that he's got another blurring algorithm that works even faster than Mario Klingemann Stack Blur algorithm. It seems to produce results that are a little further from gaussian blur than Stuck Blur but it works about 3-4 times faster which makes it a fantastic algorithm for people who just want to blur :) Thanks go to Jani for sending me his code.
I figured the code deserves a demo of its own so I quickly whipped out another sample app. Now we have a lens that does selective blur on our image (the code is not optimized because I wanted to see how it performs before optimizations - like for example for a real app you wouldn't blur the whole image as I am right now but only the part obscured by the lens). To show in screenshots:
Roberto with a unblurring lens on top:

Roberto blurred a little:

And blurred a little more:

The code is available at:

Today I also worked on Qt's OpenGL engine a bit, just cleaning things up. It would be so simple to do OpenVG implementation on top of our OpenGL engine that I'm tempted to just do it.
We got a new demo device from ATI as well today. It's very nice. Now to get Qtopia core running on it... First of all we need to get rid of all the glBegin/glEnd calls and switch things to vertex arrays and buffer objects which is something we should have had done a lot sooner but now it's really important as we want to be running on OpenGL ES natively.


Anonymous said...

I wonder if you had a look at libagg (

Zack said...

Yes, of course, it uses recursive blur and stack blur, why?

Jani Huhtanen said...

It's true that the exponential kernel does not produce very good results visually, when compared to "true" gaussian blur. However, subsequently blurring the image, ad infinitum, with the exponential kernel is equal to gaussian blur.

In practice, 3 to 4 subsequent blurs will be quite close to Gaussian blur. Thus one can trade speed for quality given the expblur algorithm. Ideal for adapting graphical effects for the given platform. Low quality for slow hardware, high quality for fast hardware.

Anonymous said...

I don't know if this is relevant, but you may find those interesting:

Best regards,
Bogdan Nicula