Fast gaussian blur appears brighter when blurred object's only partly visible #25543

New Issue

Thomas Fehrenbach · 2011-01-08T14:56:33+01:00

Thomas Fehrenbach commented

2011-01-08 14:56:33 +01:00

%%%There seems to be a problem with the fast gaussian blur (blur node). As long as the object's only partly visible, the blur appears much brighter. Just render the blend file enclosed. There are two (sun alike) objects (duplicates) on the same render layer, the partly visible one shows the issue.

Blender version is 2.56a beta on ubuntu 10.04, graphic card is intel gm45.
Thanks in advance....
Greets
Tom%%%

%%%There seems to be a problem with the fast gaussian blur (blur node). As long as the object's only partly visible, the blur appears much brighter. Just render the blend file enclosed. There are two (sun alike) objects (duplicates) on the same render layer, the partly visible one shows the issue. Blender version is 2.56a beta on ubuntu 10.04, graphic card is intel gm45. Thanks in advance.... Greets Tom%%%

Thomas Fehrenbach commented

2011-01-08 14:56:33 +01:00

Changed status to: 'Open'

Ton Roosendaal commented

2011-01-08 16:51:01 +01:00

%%%Issue confirmed; unfortunately this "fast gauss" code has a mathematically weak side on borders, as noted in our code.

What we use is Recursive Gabor Filtering" by Young/VanVliet, with "border correction" from Triggs/Sdika:
http://ljk.imag.fr/membres/Bill.Triggs/pubs/Triggs-tsp05.pdf

These edge cases seem to be common, and definitely are interesting for research... it's even possible our code has bugs, but the code was provided by a developer "as is", without any maintenance or support. For your interest I've put a piece of this border-correction code here below, this is quite un-debuggable :)
I'll note this on our todo, with link to this report. An image-processing guru might be feeling invited to help here.

sc = (1.1668 + q)*(3.203729649  + (2.21566 + q)*q);
cf- [x] = q*(5.788961737 + (6.76492 + 3.0*q)*q)/ sc;
cf- [x] = -q2*(3.38246 + 3.0*q)/sc;
cf- [x] = q2*q/sc;
cf- [x] = 1.0 - cf- [x] - cf- [x] - cf[3];

sc = cf- [x]/((1.0 + cf- [x] - cf- [x] + cf- [x])*(1.0 - cf- [x] - cf- [x] - cf- [x])*(1.0 + cf- [x] + (cf- [x] - cf- [x])*cf[3]));
tsM- [x] = sc*(-cf- [x]*cf- [x] + 1.0 - cf- [x]*cf- [x] - cf[2]);
tsM- [x] = sc*((cf- [x] + cf- [x])*(cf- [x] + cf- [x]*cf[1]));
tsM- [x] = sc*(cf- [x]*(cf- [x] + cf- [x]*cf[2]));
tsM- [x] = sc*(cf- [x] + cf- [x]*cf[2]);
tsM- [x] = sc*(-(cf- [x] - 1.0)*(cf- [x] + cf- [x]*cf[1]));
tsM- [x] = sc*(-(cf- [x]*cf- [x] + cf- [x]*cf- [x] + cf- [x] - 1.0)*cf[3]);
tsM- [x] = sc*(cf- [x]*cf- [x] + cf- [x] + cf- [x]*cf- [x] - cf- [x]*cf[2]);
tsM- [x] = sc*(cf- [x]*cf- [x] + cf- [x]*cf- [x]*cf- [x] - cf- [x]*cf- [x]*cf- [x] - cf- [x]*cf- [x]*cf- [x] - cf- [x]*cf- [x] + cf[3]);
tsM- [x] = sc*(cf- [x]*(cf- [x] + cf- [x]*cf[2]));

%%%

%%%Issue confirmed; unfortunately this "fast gauss" code has a mathematically weak side on borders, as noted in our code. What we use is Recursive Gabor Filtering" by Young/VanVliet, with "border correction" from Triggs/Sdika: http://ljk.imag.fr/membres/Bill.Triggs/pubs/Triggs-tsp05.pdf These edge cases seem to be common, and definitely are interesting for research... it's even possible our code has bugs, but the code was provided by a developer "as is", without any maintenance or support. For your interest I've put a piece of this border-correction code here below, this is quite un-debuggable :) I'll note this on our todo, with link to this report. An image-processing guru might be feeling invited to help here. sc = (1.1668 + q)*(3.203729649 + (2.21566 + q)*q); cf- [x] = q*(5.788961737 + (6.76492 + 3.0*q)*q)/ sc; cf- [x] = -q2*(3.38246 + 3.0*q)/sc; cf- [x] = q2*q/sc; cf- [x] = 1.0 - cf- [x] - cf- [x] - cf[3]; sc = cf- [x]/((1.0 + cf- [x] - cf- [x] + cf- [x])*(1.0 - cf- [x] - cf- [x] - cf- [x])*(1.0 + cf- [x] + (cf- [x] - cf- [x])*cf[3])); tsM- [x] = sc*(-cf- [x]*cf- [x] + 1.0 - cf- [x]*cf- [x] - cf[2]); tsM- [x] = sc*((cf- [x] + cf- [x])*(cf- [x] + cf- [x]*cf[1])); tsM- [x] = sc*(cf- [x]*(cf- [x] + cf- [x]*cf[2])); tsM- [x] = sc*(cf- [x] + cf- [x]*cf[2]); tsM- [x] = sc*(-(cf- [x] - 1.0)*(cf- [x] + cf- [x]*cf[1])); tsM- [x] = sc*(-(cf- [x]*cf- [x] + cf- [x]*cf- [x] + cf- [x] - 1.0)*cf[3]); tsM- [x] = sc*(cf- [x]*cf- [x] + cf- [x] + cf- [x]*cf- [x] - cf- [x]*cf[2]); tsM- [x] = sc*(cf- [x]*cf- [x] + cf- [x]*cf- [x]*cf- [x] - cf- [x]*cf- [x]*cf- [x] - cf- [x]*cf- [x]*cf- [x] - cf- [x]*cf- [x] + cf[3]); tsM- [x] = sc*(cf- [x]*(cf- [x] + cf- [x]*cf[2])); %%%

Andrew Hale commented

2011-05-07 17:16:31 +02:00

%%%Added a patch to (hopefully) make the code easier understand. Border correction will eliminate issues arising from the original Young and van Vliet algorithm, but the filter still has no information about the image outside its borders. I think the aim of the border correction here, is that, in the absence of other information it maintains the status quo i.e. it makes sure that the blurred result on the border is no brighter or dimmer than the unblurred image.%%%

Ton Roosendaal commented

2011-05-07 17:54:04 +02:00

%%%Andrew: thanks! Will reopen report now. Don't have time or energy to do it today, but it's on the active list again :)%%%

Ton Roosendaal commented

2011-06-09 16:11:10 +02:00

%%%Andrew: took a while, sorry. I've applied the patch now. The math you've provided seems to differ, but the result on rendering the attached sample is identical... was it meant to solve the brightness overflowing?%%%

Andrew Hale commented

2011-06-11 07:44:55 +02:00

%%%Ton: It won't change the result, but the original implementation did not seem consistent with the paper it was based on, even though it gave the correct result. It was really just to improve the readability and confirm that it was giving the result that the paper predicted. That way, hopefully if there are any problems, I (or someone else for that matter) can understand the code better. The brightness issue reported here is the expected behaviour, the border correction is used to improve the result as it is even worse without the correction. Let me know if there are any areas of the code which need better explaination.%%%

Ton Roosendaal commented

2011-06-19 13:37:44 +02:00

%%%Hi Andrew,

I'll mark this as a todo item now, with link to this report. Assuming the implementation for fast gauss is correct (compliant to paper) we better note is as a known limit.
Fast gauss probably shouldn't be used at all... with new compositor (opencl) things might get a good speedup anyway.%%%

%%%Hi Andrew, I'll mark this as a todo item now, with link to this report. Assuming the implementation for fast gauss is correct (compliant to paper) we better note is as a known limit. Fast gauss probably shouldn't be used at all... with new compositor (opencl) things might get a good speedup anyway.%%%

Ton Roosendaal commented

2011-06-19 13:37:44 +02:00

Changed status from 'Open' to: 'Archived'

Ton Roosendaal closed this issue

2011-06-19 13:37:44 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Fast gaussian blur appears brighter when blurred object's only partly visible #25543