POV-Ray currently applies gamma correction before antialiasing, while it
should be applied after antialiasing, since averaging of colors must be done
in a linear color space. For a sample picture that make this problem very
obvious, see the thread "Anti-Aliasing Problem including sample image (58k)"
in povray.binaries.images.

Here's a patch:

--- povwin-3.5-orig/source/render.cpp Sun Jul 28 00:55:32 2002
+++ povwin-3.5/source/render.cpp Wed Nov 27 13:31:48 2002
@@ -1571,6 +1571,7 @@ void Start_Adaptive_Tracing()

       POV_PRE_PIXEL (x, Current_Line_Number, Colour)
       trace_sub_pixel(1, Block, x, Current_Line_Number, 0, 0,
sub_pixel_size, sub_pixel_size, sub_pixel_size, Colour, antialias_line);
+      gamma_correct(Colour);
       POV_POST_PIXEL (x, Current_Line_Number, Colour)

       /* Do histogram stuff. */
@@ -2084,7 +2085,6 @@ static void supersample(COLOUR result, i

         Clip_Colour(colour, colour);

-        gamma_correct(colour);
         Add_Colour(result, result, colour);
       }
       else
@@ -2100,6 +2100,7 @@ static void supersample(COLOUR result, i
   /* Average pixel's color. */
   Scale_Colour(result,result,(1.0/samples));

+  gamma_correct(result);
 }


@@ -2330,8 +2331,6 @@ static void trace_ray_with_offset(int x,
       }

       Clip_Colour(Colour, Colour);
-
-      gamma_correct(Colour);
     }
     else
     {

--
light_source{6#local D=#macro B(E)#macro A(D)#declare E=(E-#declare
C=mod(E D);C)/D;C#end#while(E)#if(A(8)=7)#declare D=D+2.8;#else#if(
C>2)}torus{1..2clipped_by{box{-2y}}rotate<1 0C>*90translate<D+1A(2)
*2+1#else}cylinder{0(C-v=1).2translate<D+C*A(2)A(4)#end-2 13>finish
{specular 1}pigment{rgb x}#end#end#end-8;1B(445000298)B(519053970)B
(483402386)B(1445571258)B(77778740)B(541684549)B(42677491)B(70)}

Post a reply to this message

"Anders K." wrote:
> 
> POV-Ray currently applies gamma correction before antialiasing, while it
> should be applied after antialiasing, since averaging of colors must be done
> in a linear color space. For a sample picture that make this problem very
> obvious, see the thread "Anti-Aliasing Problem including sample image (58k)"
> in povray.binaries.images.

Just for the record: although such a change is surely a good idea this
does not mean the linear interpolation of colors in rgb space is the
optimal solution for color blending problems.  Despite such a change
unwanted colors may still occur.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 15 Nov. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <3de5126d$1@news.povray.org> , "Anders K." <and### [at] kaseorgcom>
wrote:

> POV-Ray currently applies gamma correction before antialiasing, while it
> should be applied after antialiasing, since averaging of colors must be done
> in a linear color space. For a sample picture that make this problem very
> obvious, see the thread "Anti-Aliasing Problem including sample image (58k)"
> in povray.binaries.images.

We know.  It has been fixed some time ago and will be made available in
POV-Ray 3.51 in the future.


    Thorsten


PS: Before anybody asks, I am not going to provide any details when it will
be released.  It surely won't be tomorrow, so don't hold your breath! ;-)


____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3de5126d$1@news.povray.org> , "Anders K." <and### [at] kaseorgcom>
wrote:

> Here's a patch:

Hint:  There is a bit more to this, but it is a long story...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:
>PS: Before anybody asks, I am not going to provide any details when it will
>be released.  It surely won't be tomorrow, so don't hold your breath! ;-)

Hmm probably a stupid question, but I must know: will it include the
sphere_sweep speed optimisation I read about some time ago (together with
the bugfix of course)? Such a cool primitive, it's a shame it renders that
slow.


--
Jonathan

Post a reply to this message

Christoph Hormann wrote:
> Just for the record: although such a change is surely a good idea this
> does not mean the linear interpolation of colors in rgb space is the
> optimal solution for color blending problems.

I'm not sure I see why. I've never seen unwanted colors testing my patch,
even when I deliberately lined up two clashing colors halfway between pixel
boundries:

// +w160 +h120 +am1 +r8 +a0.0
global_settings { assumed_gamma 1.0 }
camera { orthographic right 4/3*x up y direction z }
plane { -z, -1 pigment { checker rgb <0, 1, 1>, rgb <1, 0, 1> scale 1/4
translate 1/240 } finish { ambient 1 } }

But I'm curious to hear what you have in mind.

Anders

--
light_source{6#local D=#macro B(E)#macro A(D)#declare E=(E-#declare
C=mod(E D);C)/D;C#end#while(E)#if(A(8)=7)#declare D=D+2.8;#else#if(
C>2)}torus{1..2clipped_by{box{-2y}}rotate<1 0C>*90translate<D+1A(2)
*2+1#else}cylinder{0(C-v=1).2translate<D+C*A(2)A(4)#end-2 13>finish
{specular 1}pigment{rgb x}#end#end#end-8;1B(445000298)B(519053970)B
(483402386)B(1445571258)B(77778740)B(541684549)B(42677491)B(70)}

Post a reply to this message

In article <3de53fce$1@news.povray.org> , "Anders K." <and### [at] kaseorgcom>
wrote:

> Christoph Hormann wrote:
>> Just for the record: although such a change is surely a good idea this
>> does not mean the linear interpolation of colors in rgb space is the
>> optimal solution for color blending problems.
>
> I'm not sure I see why. I've never seen unwanted colors testing my patch,
> even when I deliberately lined up two clashing colors halfway between pixel

Christoph's argument is valid, and one would indeed expect problems either
way.  Tests showed that they don't exist, even with Clip_Colour being
performed after averaging you get good antialiasing and not even visible
color blending problems!  Don't ask me why, I don't know because I have not
investigated it in detail as the result is good...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <web.3de53dcd6040bc4978071460@news.povray.org> , "JRG" 
<jrg### [at] hotmailcom> wrote:

>>PS: Before anybody asks, I am not going to provide any details when it will
>>be released.  It surely won't be tomorrow, so don't hold your breath! ;-)
>
> Hmm probably a stupid question, but I must know: will it include the
> sphere_sweep speed optimisation I read about some time ago (together with
> the bugfix of course)? Such a cool primitive, it's a shame it renders that
> slow.

It will contain all suitable bug fixes the POV-Team knows about.  You can
assume we know about every bug fix that has been discussed here or is
mentioned on ABX's site.  Apart from that, please don't ask about details.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Anders K." wrote:
> 
> I'm not sure I see why. I've never seen unwanted colors testing my patch,
> even when I deliberately lined up two clashing colors halfway between pixel
> boundries:

See the thread in p.b.i. for some arguments in that concern. 
Interpolating between two strongly different colors with convincing
results is a difficult task.  One method would be to always interpolate
via some gray (or near to gray) value, this of course only makes sense if
the difference between the two colors is fairly large.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 15 Nov. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Wed, 27 Nov 2002 16:49:01 EST, "JRG" <jrg### [at] hotmailcom> wrote:
> Hmm probably a stupid question, but I must know: will it include the
> sphere_sweep speed optimisation I read about some time ago (together with
> the bugfix of course)? Such a cool primitive, it's a shame it renders that
> slow.

That speedup will be rather in something like MegaPOV or PoPOV first.
It's currently under testing so will be released soon probably.

ABX

Post a reply to this message