/*
Gamma - 3.6/3.7 Beta

This is an example of my problems with gamma in 3.7. It's a composite of three
images.
The top is a straight-forward gradient in 10% increments done in Photoshop.
The 2nd is the test scene done with default settings in 3.6 (Display_Gamma =
2.2, no assumed_gamma).
The last is the same scene with defaults in 3.7 (Display_Gamma/File_Gamma = 2.2,
no color correction).
What one would expect to be a smooth, linear gradient, becomes in 3.7 a
parabolic curve, heavily skewed to white.
The histograms look something like this.

3.6
|     |     |     |     |     |     |     |     |     |     |
1                                                           0

3.7
|         |         |        |       |      |     |   |  | ||
1                                                           0
*/

//+W1100 +H100

#local w = 11;
camera {
  orthographic
  location -z*1E8
  look_at y/2
  right w*x
  up w*y*image_height/image_width
}

#local i = 0;
#while (i <= 10)
 object {box {0 1}
  pigment {rgb 1-(i/10)}
  finish {ambient 1}
  translate (i-5.5)*x
 }
 #local i = i + 1;
#end

Post a reply to this message

Post a reply to this message

Attachments:
Download 'gradient_10_pov.jpg' (26 KB)

Preview of image 'gradient_10_pov.jpg'

Post a reply to this message

Attachments:
Download 'gradient_10_pov.png' (4 KB)

Preview of image 'gradient_10_pov.png'

On my display, the top two strips looks skewed toward black, with the 
two rightmost areas undistinguishable. The bottom strip does appears as 
regularly stepped shades, with all shades clearly distinct from is't 
neibours.
Also, the JPG and the PNG looks identical.



Alain

Post a reply to this message

Alain <aze### [at] qwertyorg> wrote:

>
> On my display, the top two strips looks skewed toward black, with the
> two rightmost areas undistinguishable.

That might be due to a slight error with your monitor set-up...and mine. :-)
I've noticed that, when using v3.6.1 and rendering a similar 0-to-100% gray
chart (and using the *old* assumed_gamma of 2.2 or just leaving it out, same
thing) that I get the same 'look' as his top two charts--but I need to carefully
adjust my monitor's gamma-related stuff (brightness and contrast) to get a good
visual separation between those two darkest bands. If my monitor isn't
calibrated properly, those two bands appear identical, same as you.

> The bottom strip does appears as
> regularly stepped shades, with all shades clearly distinct from is't
> neibours.

Yes--but, as the poster says, they are reproducing a 'parabolic' brightness
curve (his words), rather than the *expected*, *visually* linear curve.
("Expected" meaning, simply what he--and I--have been used to seeing in our
previous scenes, using assumed_gamma 2.2 rather than 1.0-- and prior to v3.7's
new gamma changes.)

I'm not saying that any of this is correct or incorrect--just *different* from
3.7. (I surely don't want to get into any late argument about the pros or cons
of the 3.7 gamma changes. ;-)

Ken

Post a reply to this message

"Stephen Klebs" <skl### [at] gmailcom> wrote:
> /*
> Gamma - 3.6/3.7 Beta
>
> This is an example of my problems with gamma in 3.7.

Like you, I have grown comfortable with, and accustomed to, the 'look' of the
pre-3.7 gamma set-up (i.e., using assumed_gamma 2.2 rather than 1.0). Which in
itself was *wrong* according to the old docs; they used to say that
assumed_gamma should be 1.0, not 2.2. (While at the same time implying that
assumed_gamma should be the same as display_gamma--which would be 2.2, not 1.0)
It was all kind of screwy, IMO. But the main reason *I* have used assumed_gamma
2.2 forever, was probably the same as you--that it matched my Photoshop (and
many other apps') representation of a similar 0-100% grayscale chart. Not to
mention digital camera photos, web browsers (reproducing jpeg photos), etc. I
could never get used to the look of using assumed_gamma 1.0 in POV-Ray.

This gamma change in v3.7 is probably the biggest change to impact POV-Ray in
quite some time. Yet I *do* see the reasoning behind the new changes, I guess
the main one being that POV-Ray needs to operate on 'gamma-uncorrected' values,
in order to do accurate light-based calculations. (And it corrects some internal
inconsistencies, I believe.) This gamma thing has been a thorny issue for years,
and I applaud Clipka and the other developers for even daring to tackle it, to
iron out the issues. The changes were bound to cause many of us to howl and
protest, because, AFAIU, it *does* mean we will have to go back to our many
legacy scenes and rework them (I think that includes assumed_gamma 2.2 AND 1.0
users, though I don't know for sure.) I'm personally not averse to doing
so--even though it *will* be quite a chore--because it will result in a more
coherent and accurate approach to lighting, colors, etc. And Clipka has
mentioned that a 'pre-3.7 gamma switch' is being discussed (which would seem to
be a solution to 'our problem'-- less of a 'blunt weapon' approach than simply
using the version 3.6 directive.)

What *does* bother me a bit about your 3.7 grayscale test is that it looks
identical (or very similar) to the results when using v3.6.1 and assumed_gamma
1.0.  :-(  Yet if 3.7 is doing what it's supposed to do--and I have no reason to
think otherwise--I guess I'm just going to have to get used to that ;-)

Ken

Post a reply to this message

Am 30.11.2010 22:51, schrieb Kenneth:
> coherent and accurate approach to lighting, colors, etc. And Clipka has
> mentioned that a 'pre-3.7 gamma switch' is being discussed (which would seem to
> be a solution to 'our problem'-- less of a 'blunt weapon' approach than simply
> using the version 3.6 directive.)

If the change proves to work as intended, you will essentially have 
three choices:

(A) Use a "#version 3.6" directive and no "assumed_gamma" to get default 
3.6 behaviour.

(B) Use "assumed_gamma" with any #version directive you like (or none at 
all) to get 3.6 "assumed_gamma" behaviour.

(C) Use a "#version 3.7" (or higher) directive and no "assumed_gamma" to 
get the new 3.7 gamma behaviour, which would essentially be the same as 
using "assumed gamma 1.0" plus a ton of improvements for input image files.

(A) and (B) will be for backward compatibility only, and will not play 
well with the new 3.7 gamma-related features such as the File_Gamma INI 
option or the "gamma" SDL keyword. There will also be some caveats 
regarding PNG input files.

Post a reply to this message

Am 30.11.2010 14:39, schrieb Stephen Klebs:

> What one would expect to be a smooth, linear gradient, becomes in 3.7 a
> parabolic curve, heavily skewed to white.

To be exact, it /does/ become a smooth, linear gradient - but our eyes 
prefer a nonlinear one.

And all that is gold does not glitter - here are two scenes rendered 
with POV-Ray 3.6 to showcase why we're doing it differently now.

On most displays, image "gammachecker_3.6.png" will show a chrome sphere 
on a checkered plane, but there's something wrong here: The checkering 
shouldn't be there - the plain grey tiles have a brightness of 0.5, 
while the striped tiles have alternating lines of 0.0 black and 1.0 
white, so should appear just as bright as the grey if you squint your 
eyes; and in indeed both tiles appear to have the same brightness in the 
reflection, where anti-aliasing computes the correct result.

Images "test_a.png" and "test_b.png" show virtually the same scene, (a) 
using proper gamma handling, and (b) using POV-Ray 3.6 with 
assumed_gamma 2.2; colors and finish parameters have been adjusted to 
compensate, and even the light sources' brightness has been tweaked to 
get the same brightness level, but still the output doesn't look as 
convincing - for a reason: For instance, the shadows are unrealistically 
deep. That's because when working in gamma 2.2 space, half brightness + 
half brightness does /not/ add up to full brightness.

For comparison I also added a third variant of the scene, which uses the 
very same values as (b) but with output gamma adjusted. Obviously the 
colors in (c) are different (because the values mean something different 
than in (b)), but aside from that I think it looks just as convincing as 
(a).

Post a reply to this message

Attachments:
Download 'gammachecker_3.6.png' (100 KB) Download 'test_a.png' (143 KB) Download 'test_b.png' (132 KB) Download 'test_c.png' (167 KB)

Preview of image 'gammachecker_3.6.png'

Preview of image 'test_a.png'

Preview of image 'test_b.png'

Preview of image 'test_c.png'

Alain <aze### [at] qwertyorg> wrote:

>
> On my display, the top two strips looks skewed toward black, with the
> two rightmost areas undistinguishable. The bottom strip does appears as
> regularly stepped shades, with all shades clearly distinct from is't
> neibours.
> Also, the JPG and the PNG looks identical.
>
>
>
> Alain

What do you get when you bring them into an image editing program? Look at the
histogram? Just the numbers. Do the pictures that look like smooth gradients
have a LAB or HSB progression of like (0, 0, 10), (0, 0, 20), etc.?

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 30.11.2010 22:51, schrieb Kenneth:
> > coherent and accurate approach to lighting, colors, etc. And Clipka has
> > mentioned that a 'pre-3.7 gamma switch' is being discussed (which would seem to
> > be a solution to 'our problem'-- less of a 'blunt weapon' approach than simply
> > using the version 3.6 directive.)
>
> If the change proves to work as intended, you will essentially have
> three choices:
>
> (A) Use a "#version 3.6" directive and no "assumed_gamma" to get default
> 3.6 behaviour.
>
> (B) Use "assumed_gamma" with any #version directive you like (or none at
> all) to get 3.6 "assumed_gamma" behaviour.
>
> (C) Use a "#version 3.7" (or higher) directive and no "assumed_gamma" to
> get the new 3.7 gamma behaviour, which would essentially be the same as
> using "assumed gamma 1.0" plus a ton of improvements for input image files.
>
> (A) and (B) will be for backward compatibility only, and will not play
> well with the new 3.7 gamma-related features such as the File_Gamma INI
> option or the "gamma" SDL keyword. There will also be some caveats
> regarding PNG input files.

Sounds fine. Your intentions are admirable. Your science is impressive. But I
always seem to hear a lot of uncertainty in your final tone. The system is so
interrelated you obviously appreciate how hard it is to know how it will turn
out. When I tried to reproduce in 3.7 Steve Gower's wonderful "Bucket of
Seashells", however, using every possible gamma/version/ambience whatever I
could think of, I was surprised how dramatically different everything looked.
The smooth beach turned into a pile of large boulders. The light on the water
looked fake and glaringly over exposed. Parts of the seashells lost all their
beautiful gradations and were just black.

Post a reply to this message