POV-Ray : Newsgroups : povray.beta-test : Gamma tutorial for the 3.7 documentation? : Re: Gamma tutorial for the 3.7 documentation? Server Time
5 Oct 2024 02:12:33 EDT (-0400)
  Re: Gamma tutorial for the 3.7 documentation?  
From: clipka
Date: 15 Oct 2009 15:40:57
Message: <4ad77ac9@news.povray.org>
ingo schrieb:

> In the time since the 3.6 release I gues over 80% of 
> the users have switched from CRT to LCD that has no gamma at all. So an 
> old image will never look the same on a new monitor. The spread of 
> quality between LCD's I find quite big, so big a "gamma" adjustment 
> would be needed.

While it is true that technically an LCD /panel/ has no gamma worth 
mentioning, LCD /displays/ usually do include some gamma curve using a 
look-up table - for the sole purpose of being compatible with CRTs in 
this respect.

High-end LCDs for multimedia production may be yet a different story, 
but the average PC user is likely to have either a low-end LCD, or a 
high-end LCD for gaming purposes.

> Digital imaging has progressed over time, digital camera's are commen 
> now. People will expect the "same" output of a renderer as from their 
> camera. So, I would suggest a simple setting for the user to choose 
> colour space, not just gamma. Most digital devise use sRGB now, so for 
> many platforms that would be the default. A special colour space could 
> be "linear" for a gamma = 1 output (it's been some time ago, but 
> doesn't the hf_gray setting automagically create gamma = 1 images).

I think going for full-fledged colour management would be pretty 
far-fetched ATM - even if output would be limited to two hard-coded 
color profiles (e.g. sRGB, as well as a linear color space using the 
sRGB primaries and white point) - as it would appear to carry an 
implicit promise that...

- the colors with which POV-Ray is operating internally would be 
precisely defined with respect to wavelength-dependent effects (which is 
not the case at present)

- POV-Ray would do full-fledged colour management for input files as 
well (which it doesn't, and due to complexity and lack of manpower is 
unlikely to do in the near future)

What does seem feasible at present would be to provide an option to use 
the /gamma function/ defined in the sRGB standard (and even make it the 
default) instead of a classic constant-gamma power law encoding.


Post a reply to this message

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