POV-Ray : Newsgroups : povray.bugreports : Gamma Correct bugs Server Time
14 May 2024 02:08:11 EDT (-0400)
  Gamma Correct bugs (Message 1 to 2 of 2)  
From: Nathan Kopp
Subject: Gamma Correct bugs
Date: 14 Nov 1999 03:28:55
Message: <382e72c7@news.povray.org>
Gamma correction in POV-Ray 3.1g suffers from a few bugs.  The most visible
bug is with focal_blur, where gamma correction is applied twice to the
image.  The other problem is with antialiased pixels, where gamma correction
should occur after the samples are averaged, but is instead applied for each
sample before they are averaged.  Due to the non-linear nature of gamma
correction, this produces incorrect results.  Luckily, the problems with
antialiasing is not very apparent.

If you are using focal_blur, however, you will probably have to make
modifications to your gamma correction settings to achieve the same results
as when focal_blur is not used.

The next version of UVPov (release date unknown) will contain a fix.  (...as
will the next release of POV-Ray... release date of that is also unknown.)

-Nathan

------------

Here are a few gamma_correct() bugs in POV 3.1g.  All of these are in
render.c.

First:
trace_pixel() calls focal_blur() in line 2513.  At the very end of
focal_blur(), there is a call to gamma_correct() in line 2391.  After
focal_blur() returns, trace_pixel() calls gamma_correct() again (line 2540).
The fix is either to remove the gamma_correct() call from focal_blur() or
move the call in trace_pixel() to before line 2536.

This bug was reported by someone on the newsgroups.  I have made the above
change in UVPov and verified that it did correct the problem.

Second:
supersample() calls gamma_correct() in line 2000 on each ray traced instead
of after it divides the sum by the number of samples.  gamma_correct()
should be moved to after line 2013.

Third:
trace_ray_with_offset() (which is part of adaptive anti-aliasing) calls
gamma_correct() in line 2240.  It should not.  Instead,
Start_Adaptive_Tracing() should call gamma_correct() directly after the call
to trace_sub_pixel() in line 1564.

Finally, the various calls to Clip_Colour() that usually go along with
gamma_correct() should also be moved with gamma correct.  However, due to
the nature of Clip_Colour(), this is probably not necessary.  On the other
hand, if the 'infinite light patch' is included in POV 3.5, which uses a
modified Clip_Colour() procedure, then this could make a significant
difference.

-Nathan


Post a reply to this message

From: Nathan Kopp
Subject: Re: Gamma Correct bugs
Date: 18 Nov 1999 00:33:08
Message: <38338f94@news.povray.org>
My gamma_correct solution may be flawed.  I'll look into it further and let
you know.  The focal_blur solution is correct.  It is the anti-aliasing ones
that do not work properly.

-Nathan


Nathan Kopp <Nat### [at] Koppcom> wrote...
>
> Gamma correction in POV-Ray 3.1g suffers from a few bugs.  The most
visible
> bug is with focal_blur, where gamma correction is applied twice to the
> image.  The other problem is with antialiased pixels, where gamma
correction
> should occur after the samples are averaged, but is instead applied for
each
> sample before they are averaged.  Due to the non-linear nature of gamma
> correction, this produces incorrect results.  Luckily, the problems with
> antialiasing is not very apparent.
>


Post a reply to this message

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