|
 |
I have been using focal blur in my images lately and without error, it has
consistently made my images brighter. Brighter in the fact that it seems that
to be jacking up the ambient value of all the surfaces in the scene.
I got the "funny feeling" that POV wasn't averaging the blur samples
correctly. And after looking at the source I found that it is not and why.
Beginning at line 2349 in Render.C there is this following code snippet
contained within the function Focal_Blur(). This snippet is is the middle of
a loop that is terminated by the maximum number of samples to be taken (or by
early exits via variance checking). It creates a ray, traces it, gamma
corrects the calculated color and adds that color to a tallying "color sum"
stored in 'Colour'. At the very end of the function, this color sum is scaled
down by the total number of samples taken, which was stored in 'nr'.
if (create_ray(Ray, x+dx, y+dy, nr))
{
Trace_Level = 1;
Increase_Counter(stats[Number_Of_Samples]);
Trace(Ray, C, 1.0);
Clip_Colour(C, C);
gamma_correct(C);
Add_Colour(Colour, Colour, C);
}
Please consider the following....
The bug here is that we do NOT want to gamma correct each individual sample.
Reason? Because of those of us who know about how gamma works, we know that
it is not a linear multiplication of the color components. For this reason,
we cannot expect to "factor it out" of a sum of colors. Becuase the
gamma_correct changes each individual color in the entire sum, its subsequent
upwards lighting of each color is exacerbated when we keep adding it in each
time. This is what I'm saying:
(gamma_correct(color1)+gamma_correct(color2)+gamma_correct(color3) ... )/n
DOES NOT EQUAL
gamma_correct(color1+color2+color3+color4 ... ) / n
The code as it is written calculates the former, which, in general, will be
brighter than the latter. This is why gamma-corrected images with focal blur
appear brighter than those without focal blur.
To correct this problem, remove line 2359 ( gamma_correct(C); ) altogethor
and then, at the very end of the function, add this line:
gamma_correct(Colour);
My hat is off to anyone who posts a Win95 3.02 recompile with these changes.
I would greatly appreciate it and I will use your executable all the time! :)
Thanks,
Steve
Post a reply to this message
|
|
|
|
You are definitely right about the two transforms not being equal
> (gamma_correct(color1)+gamma_correct(color2)+gamma_correct(color3) ... )/n
> DOES NOT EQUAL
> gamma_correct(color1+color2+color3+color4 ... ) / n
However, I think the correct code should be
gamma_correct( (color1+color2+color3+color4 ...)/n )
since this would be equivalent to tracing the image and then gamma_correcting,
which is the proper procedure.
In Him,
Ben Birdsey
Post a reply to this message
|
|
|
|
It _is_ still living in 3.1.
-Hans-
Thorsten Froehlich wrote:
>
> In article <369b9b77.580981266@news.povray.org> , hor### [at] osu edu (Steve )
> wrote:
> >My hat is off to anyone who posts a Win95 3.02 recompile with these changes.
> >I would greatly appreciate it and I will use your executable all the time! :)
>
> Did you check if the problem is still in the POV-Raz 3.1 source code, or is the
> "3.02" version just a typo?
>
> Thorsten
Post a reply to this message
|
|
|
|
In article <369E4333.A8A0CECE@pecos.nospam.de> , Hans-Detlev Fink
<hdf### [at] pecosnospamde> wrote:
>It _is_ still living in 3.1.
>
>-Hans-
Thanks, I forwarded it to team now.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: Tho### [at] csicom
I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://www.povray.org
Post a reply to this message
|
|
