Page MenuHome

Median Blur Node
Closed, ResolvedPublicPATCH


The patch implements a median blur node, it's particularly useful for removing noise whilst maintaining sharp edges.

Only a 'square' blur aperture is implemented, and this is done by blurring first in the x direction, then in the y direction (in the same manner as most of the current blur filters work). I borrowed heavily from the existing blur node, however integrating the median blur there seemed a little cumbersome, so it is separate for the sake of simplicity.

A few things I'm unsure about:
Since only whole number values for the radius are used, other values are currently truncated. This seemed to be the behaviour of other filters, but doesn't seem to be the best thing to do.
My line endings (I think they're right, let me know ;)

Event Timeline

Other blur nodes do two passes because they can be decomposed in such
way, and is faster. The result is the same (precission issues aside)
when done in one pass or two. Take the following small zone and
radius 3 median:

1 1 3
1 4 1
6 8 6

With one pass the result for center pixel is 3. With horizontal then
vertical, the result is 1.

I would not call it blur, just median filter, like many bibliography on
the topic. After all the purpose is denoising with minimal changes.
If you search a bit, you can find some methods that do a single pass and
are near constant time for any radius.

Although in general, one would expect the two to be the same ;)

The best algorithm that seems to exist is the one described here:
and an implementation licensed under GPLv3 is supplied; if that license is okay then I'll just plug it into Blender, but if I remember correctly, it isn't?

Also of note is that many of the very fast methods require enumerating the pixel values to create histograms – an approach that is not practical for floating point images like the ones passed between nodes.

Thanks for the input.
Back to the drawing board...

I've added a naive, but technically correct square median filter to the existing sequential one, also, the filter aperture is now rounded to the nearest pixel.

Still thinking about the faster methods: one relatively easy option would be to reduce the bit depth of the output image to 8 bits per channel, I don't know how acceptable that would be.

median_17-3-2009-b.patch aligns the filter aperture correctly, and handles filter apertures with zero radius in one direction better.

Still thinking about faster methods: histogram / maintaining sorted group -type methods won't work with a varying filter radius: in this case I think the naive, grab-the-pixels, find the median, spit it out method is the only practical one.


- Options for Circular, Cross or Square filter aperture.
- Much faster, (though not much lower in algorithmic complexity): circular aperture of radius 5 (diameter 11) on 4 channel 1920x1080 takes around 15 seconds for me. (2.4 Ghz, 667Mhz RAM)

I'm going to shelve implementing a 'fast median' option for now.

Thomas Dinges (dingto) changed the task status from Unknown Status to Resolved.Apr 1 2013, 12:47 PM