Stephen Klebs wrote:

> Bluntly put. You're making this much too complicated.

There is probably some merit both in making things
simple and making them work right. Ideally, of course,
they should be both.

> If it looks right, it IS right. 

On the other hand, the amount of time needed to get something
to look right in the first place might depend on whether the
process of rendering is realistic.

> Now what do I get? Not a straight, smooth, gradual gradient from
> light to dark but a parabolic curve of values from light to slightly
> darker but still light to abruptly skewed to black. 

I have to admit I don't understand this either. Until now I
thought that since 3.7 now uses a linear color space, 0.5 would
represent a true midgray and all the nifty gamma handling ensures
that everyone perceives that midgray on their display when viewing
the image file. So I'd also have expected the end result of your
test scene to visually yield evenly spaced brightness steps.

Looking at the png itself it seems the upper two rows use 127
for midgray while the lower uses 186. From all I heard so far
186 should appear as midgray on a calibrated gamma 2.2 display
so that would appear to be correct. But I too perceive the
upper two rows as more visually correct. It's as if my lcd
used linear color space. I wonder if the Windows 7 built-in
display calibration is somehow playing tricks on me.

You can get the old behavior with assumed_gamma 2.2 or
by replacing rgb x with rgb pow(x,0.45).

Independent of this issue: Would it be useful to have a
setting of "color_gamma" that tells POV-Ray how to interpret
literal color values specified in SDL? The default value of 1.0
would yield the current behavior while e.g. 2.2 would internally
convert a value as rgb 186/255 to rgb 0.5 without the need for
plastering your code with gamma macros.

Post a reply to this message