POV-Ray : Newsgroups : povray.binaries.programming : Bug Report!! Server Time
21 Dec 2024 23:59:02 EST (-0500)
  Bug Report!! (Message 1 to 2 of 2)  
From: Steve
Subject: Bug Report!!
Date: 12 Jan 1999 06:08:20
Message: <369b1aec.548068652@news.povray.org>
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

From: Daren Scot Wilson
Subject: Re: Bug Report!!
Date: 15 Jan 1999 20:38:31
Message: <369FA748.BE96D2AF@pipeline.com>
Steve wrote:
> I got the "funny feeling" that POV wasn't averaging the blur samples
> correctly.  ...<snip>...
...snip...
> (gamma_correct(color1)+gamma_correct(color2)+gamma_correct(color3) ... )/n
> DOES NOT EQUAL
> gamma_correct(color1+color2+color3+color4 ... )   / n

Ha, I discovered this when I wrote my first dispersion patch (not the
current one, which is simple and works, but one I wrote in 1997).   I
couldn't get images to look decent even when i wasn't using dispersion,
but i had changed all the COLOUR types to a 9-component array, and had
to change loops,etc.   Antialiasing, focal blur, radiosity, and other
features all went nuts. 

Funny how this bug sat there for so long without notice.  Even though I
bumped into it, i assumed it was a flaw in my patch.

I hope all the usual people catch on and spread this fix.


-- 
Daren Scot Wilson
dar### [at] pipelinecom 
www.newcolor.com
----
"A ship in a harbor is safe, but that is not what ships are built for"
                                            -- William Shedd


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.