Am 02.12.2010 01:01, schrieb Jaap Frank:

> That's odd, because for me the 3.6 side is correct and the 3.7 side is
> far too bright.

Actually /that/ is odd.

> By the way, the challenge from clipka is for me a perfect gradient from
> 0,0 to 1,1 in the XY-plane. I suspect that this picture is made with
> 3.7, so that is odd again.

No, it's an image with a "visually linear" gradient created in Photoshop 
while working with the sRGB color profile, which I then converted to a 
custom color profile with a gamma of 1.0. The challenge is to open this 
image in Photoshop and - without converting it to a different color 
profile - draw a visually linear gradient over it. I don't know about 
newer versions, but in Photoshop 6.0 this will have you end up with a 
gradient similar to that created by POV-Ray 3.7.

> I'm reading the Gamma Stories for months now and all the same I'm confused.
> Maybe clipka can answer what is correct:
> Povray makes a calculation for a picture and the values of the first
> three pixels are 64,64,64 / 128,128,128 / 192,192,192.
> As I understand these are the values of PovRay's internal lineair color
> space.

No. POV-Ray internally works with floating point numbers.
But let's for now assume that POV-Ray happens to compute 0.25,0.25,0.25 
/ 0.5,0.5,0.5 / 0.75,0.75,0.75 for those pixels.

> My questions are:
> A. What values are send to the display system at the moment of rendering:
> 1. Gamma corrected values for a 2.2. display, so not the lineair values.

Yes. In the given case that would be 136,136,136 / 186,186,186 / 
224,224,224.

To be precise, the gamma may be the one specified by the Display_Gamma 
INI file option, defaulting to 2.2. You can also set 
"Display_Gamma=sRGB", in which case you'll get the roughly similar 
adjustment specified in the sRGB color space specification ("sRGB 
transfer function").

> 2. Lineair values and PovRay tells the display system to convert them to
> 2.2 display values:

No.

> B. What values are written in the png file and what is put in the gAMA
> chunk.
> 1. Same as A.1. and the gAMA chunk tells the values are gamma corrected
> for 2.2.

By default, yes. Again, you can specify the gamma using the File_Gamma 
INI file option, and once again 2.2 is the default and "sRGB" is a valid 
value also.

> 2. Same as A.2. and the gAMA chunk tells that the correct values should
> be 2.2 corrected values (sounds not correct, but you never can tell).

That would be the case if you set File_Gamma=1.0. But to be precise, 
POV-Ray would not tell in the gAMA chunk that the values still need to 
be gamma-corrected for 2.2, but rather just tell that the values are 
linear, leaving it up to the image viewer to decide for which gamma to 
pre-correct the data before sending them to the display.

> To complete the story:
> C.1. PovRay expects the file for a image-texture on a object to be gamma
> corrected (default 2.2) and counter corrects the values for it's lineair
> color space.

That would be the case for most low dynamic range file formats that do 
not carry gamma information (or none that POV-Ray can currently 
understand; e.g. BMP or JPEG).

> 2.Same, but the correction depends on the gAMA blok. With no gAMA a 2.2
> correction is used.

That would be the case for PNG images, except that an sRGB chunk would 
take precedence over a gAMA chunk, and the default would be the sRGB 
transfer function, which is close to (but not quite the same as) a gamma 
of 2.2.


> I think that the answers are A.1 and B.1, but sometimes I begin to doubt
> that, as I read these gamma stories.

It's still true nonetheless. The original cause of confusion is 
typically the impression that normally pixel values (such as displayed 
by Photoshop, or by most color pickers) would be linear. They're not.

> As far as I've understood C.1 is 3.6 and C.2 is 3.7 policy.

Yes and no. In general you're right, but for PNG 3.6 already used gamma 
correction if a gAMA chunk was present (it ignored sRGB chunks though, 
IIRC).

Post a reply to this message