How does RBF denoise settings work?

[ilia3101]

Is it just the recursive bilateral filter applied on RGB channels, then mixed with original image in YUV(or whatever we use) space?

How does range slider affect it, does a lower range value mean it is only applied in the shadow areas?

Also @masc4ii I remember you said this RBF was faster than my crappy box blur? Do I remember that correctly? Quite impressive...

[masc4ii]

There are two general features realized with RBF:

• Shadows / Highlights / Clarity
• Denoiser

The function itself has two parameters: sigma_spatial, sigma_range. The denoiser range slider changes the second one, while the first is hardcoded to 0.0005f for Shadows/Highlights/Clarity and to 0.0025f for the denoiser. (Please don't ask why... I played around and decided it this way.) If you want a more detailed information what this parameter does, I recommend to read a paper. But the result of the range slider looks like a kind of radius when comparing with box blur.

For Shadows / Highlights / Clarity, the function is applied on RGB values (all 3 at the same time) while for the denoiser, the function is applied on Y (Luma slider) and UV (Chroma slider). For the denoiser intensity sliders: 100 is 0% original and 100% filtered, while 0 is the opposite.

The main advantage of a RBF is that it preserves edges, while a box blur doesn't. This way you get better results for the features where we use it. The main disadvantage is its processing speed - it is a singlethreaded algorithm which is slow, especially for large image resolutions, while box blur can be multithreaded.

[ilia3101]

The main advantage of a RBF is that it preserves edges, while a box blur doesn't. This way you get better results for the features where we use it.

Agreed. Shadows/highlights adjustments look great since we started using RBF.

The main disadvantage is its processing speed - it is a singlethreaded algorithm which is slow, especially for large image resolutions, while box blur can be multithreaded.

I see. I am quite sure a standard bilateral filter could be multithreaded. Maybe it's a little harder with "RBF" but I think it is possible.

[masc4ii]

I see. I am quite sure a standard bilateral filter could be multithreaded. Maybe it's a little harder with "RBF" but I think it is possible.

That idea is funny. The same I tried in the last days - at least single threaded (as starting point). But it felt like a hundred times slower. Maybe we find a better implementation for it. There also exists an optimized RBF version. But it just works for 3x8bit, not 3x16bit. This one would be really fast (factor ~10)! https://github.com/Fig1024/OP_RBF Maybe this gives you some idea...

[ilia3101]

I remember those optimised versions. Ridiculous speed. The graph also mentions threading, so mgiht be possible even for the unoptimised one.

What are the "pipelined" versions? Do you know?

[masc4ii]

The plain (single threaded) version is very optimized. For changing it to multithreading, it would be neccessary to implement some overhead (there are some "variable++" in for loops, which doesn't work for opemMP multithreading).

If I remember right, the 3 (or 4) channels are processed in one step using 64bit architecture (4x8bit=64bit) in pipelined version.

[masc4ii]

@ilia3101 : Did you ever try openCL? Here are two implementations of biliteral filter on openCL: https://github.com/xidexia/Bilateral-Filtering https://github.com/honeygupta/bilateralfilter

[ilia3101]

Ah yes, we never quite got that OpenCL stuff working :(

Or maybe bouncyball had something working at some point. Don't quite remember.