POV-Ray : Newsgroups : povray.beta-test : Gamma in POV-Ray 3.6 vs. 3.7 : Re: Gamma in POV-Ray 3.6 vs. 3.7 Server Time
5 Oct 2024 02:15:41 EDT (-0400)
  Re: Gamma in POV-Ray 3.6 vs. 3.7  
From: clipka
Date: 12 Sep 2009 09:46:50
Message: <4aaba64a$1@news.povray.org>
Christian Froeschlin schrieb:

> Yes, but gamma is inherently related to defining a color and
> not a vector. I find it confusing to add the gamma correction
> prefix to the "vector part" of the syntax

I'd actually disagree (though I see your point): Raytracing is quite a 
lot about physics, and therefore POV-Ray tends to use physical 
parameters. For colors, this means that the defining coefficients are 
luminance values. If you want to define colors based on any other set of 
parameters (e.g. gamma pre-corrected RGB coefficients), you must convert 
it to luminance values *first*.

 > (not sure how the
> parser views it technically but to the user it looks like
> color rgb takes a vector argument).

That's something I find particularly confusing about POV-Ray's color 
syntax, and I hope a next generation SDL will do away with that by 
constructing a clear "language barrier" between vectors and colors, 
allowing conversion from one to the other only via helper functions or 
some such.

> Well, I was thinking from the renderers point of view. Among other
> things it gets parsed pigments as input some of which may stem from
> image_maps and some with actual color definitions. How about
> "pigment_gamma" or similar? I assume an image which is used
> for texture maps or normals should not be gamma corrected.

You're trying to move the gamma correction away from the file, and to 
its use in an actual "real-life" pigment instead, but this opens up a 
can of worms.

What if an image is used in a pigment, which is subsequently converted 
to a function, which in turn is then used in a height field, or in a 
texture or normal map?

You cannot carry gamma as a sideband information across functions, as 
those may apply some math to it, which may in turn require a particular 
gamma (typically linear).

The only "sane" solution to this dilemma I see is to warn users that 
gamma adjustment *will* be applied to *all* images, unless used in the 
following language constructs: ...(tbd)..., and that if they want to 
change the behavior for a particular file, they *must* explicitly 
specify a "gamma" parameter for this one.

The name of the default parameter should reflect this perspective.


Post a reply to this message

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