clipka <ano### [at] anonymousorg> wrote:
> Am 01.12.2010 04:23, schrieb Stephen Klebs:
>
> > 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.
>
> Did it work with 3.6?

Sorry. Post amended:

> Did it work with 3.6?
Yes it worked in 3.6. More or less as #version 3.6. Perfectly as #version 3.0.

Post a reply to this message

Am 01.12.2010 14:08, schrieb Stephen Klebs:
> clipka<ano### [at] anonymousorg>  wrote:
>> Am 01.12.2010 04:23, schrieb Stephen Klebs:
>>
>>> 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.
>>
>> Did it work with 3.6?
>
> No. If someone can get it to work (without playing with it for a week). I'll
> shut up.

Okay, so the problems with Steve Gower's scene are obviously unrelated 
to the gamma changes in POV-Ray 3.7.

Post a reply to this message

Stephen Klebs <skl### [at] gmailcom> wrote:
> What one would expect to be a smooth, linear gradient, becomes in 3.7 a
> parabolic curve, heavily skewed to white.

  I took your gradient image, rotated it 90 degrees and put alternating
horizontal black and white lines of pixels at both sides. Look at the
image from far enough that you don't distinguish the individual lines
but instead it becomes a gray, and then estimate on both sides which
square in the central gradient corresponds to this half-gray area on
the sides. I think it's pretty illuminating.

  With my monitor the photoshop/pov36 part (at the left) has the same
brightness somewhere between the second-to-last and third-to-last square,
while the pov37 part (at the right) as the same brightness somewhere in
the middle, as it should.

Post a reply to this message

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

Preview of image 'gradient_10_pov.png'

On 12/01/2010 10:45 PM, Warp wrote:
>   With my monitor the photoshop/pov36 part (at the left) has the same
> brightness somewhere between the second-to-last and third-to-last square,
> while the pov37 part (at the right) as the same brightness somewhere in
> the middle, as it should.

  Oh, and by the way, if the suspicion is that the bright white lines
are "bleeding" over the black lines making them look lighter than they
should (which might be a valid concern especially on a CRT), you can try
zooming the image eg. to 4 times the size (so that each pixel in the
image is scaled to 4x4 screen pixels) to minimize that possibility, and
look at it from even farther away (to "blend" the horizontal lines into
gray). When I do this, it still looks the same.

Post a reply to this message

"Warp"  schreef in bericht news:4cf6b3fd@news.povray.org...
_____________________________________________________
Stephen Klebs <skl### [at] gmailcom> wrote:
> What one would expect to be a smooth, linear gradient, becomes in 3.7 a
> parabolic curve, heavily skewed to white.

  I took your gradient image, rotated it 90 degrees and put alternating
horizontal black and white lines of pixels at both sides. Look at the
image from far enough that you don't distinguish the individual lines
but instead it becomes a gray, and then estimate on both sides which
square in the central gradient corresponds to this half-gray area on
the sides. I think it's pretty illuminating.

  With my monitor the photoshop/pov36 part (at the left) has the same
brightness somewhere between the second-to-last and third-to-last square,
while the pov37 part (at the right) as the same brightness somewhere in
the middle, as it should.
                                                          - Warp
-----------------------------------------------------------------------------------

That's odd, because for me the 3.6 side is correct and the 3.7 side is far 
too bright.
I've a rather new HD LCD TFT monitor (about 6 months) and adjusted it 
conform the windows 7 system with brightness and contrast followed by color 
shade correction.
Further the monitor of my laptop (Acer Aspire, 1 year old, crystal clear 
display) shows exactly the same picture. Both are driven by the NVidia card 
inside the laptop, so they should be the same and for /me/ they are. The 
pictures are displayed by Windows Live Mail.
I'm wondering if the default 3.7 approach is correcting the values for a 2.2 
gamma display in the file, while the display system thinks it gets lineair 
values and correct the values again. That would explain the 3.7 side for me. 
(The jpg and png files are the same for me, so that can't be the problem)
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.

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.
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.
    2. Lineair values and PovRay tells the display system to convert them to 
2.2 display values:
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.
    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).
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.
    2.Same, but the correction depends on the gAMA blok. With no gAMA a 2.2 
correction is used.

I think that the answers are A.1 and B.1, but sometimes I begin to doubt 
that, as I read these gamma stories.
As far as I've understood C.1 is 3.6 and C.2 is 3.7 policy.

Jaap Frank

Post a reply to this message

On 02.12.2010 01:01, Jaap Frank wrote:
 > That's odd, because for me the 3.6 side is correct and the 3.7 side is
 > far too bright.
 > I've a rather new HD LCD TFT monitor (about 6 months) and adjusted it
 > conform the windows 7 system with brightness and contrast followed by
 > color shade correction.
 > Further the monitor of my laptop (Acer Aspire, 1 year old, crystal clear
 > display) shows exactly the same picture. Both are driven by the NVidia
 > card inside the laptop, so they should be the same and for /me/ they
 > are. The pictures are displayed by Windows Live Mail.

Trust me, Warp is correct and if you see it different there is something 
screwed up with your display system. One cannot *perfectly* calibrate a 
display without usage of some external hardware but for, let's say 
hobbyist usage, there are quite a lot tools (and web-pages) around that 
allow for visual adjustment but all of them boil down to something 
similar Warp has shown.


 > I'm wondering if the default 3.7 approach is correcting the values for a
 > 2.2 gamma display in the file, while the display system thinks it gets
 > lineair values and correct the values again. That would explain the 3.7
 > side for me. (The jpg and png files are the same for me, so that can't
 > be the problem)
 > 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.
 >
 > 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.
 > 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.
 > 2. Lineair values and PovRay tells the display system to convert them to
 > 2.2 display values:
 > 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.
 > 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).
 > 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.
 > 2.Same, but the correction depends on the gAMA blok. With no gAMA a 2.2
 > correction is used.
 >
 > I think that the answers are A.1 and B.1, but sometimes I begin to doubt
 > that, as I read these gamma stories.
 > As far as I've understood C.1 is 3.6 and C.2 is 3.7 policy.
 >

A.1. but the actual value can be adjusted by the display_gamma setting 
with the recommended default of 2.2 (unless you know what you are doing ;)
B.1. but the actual value can be adjusted by the file_gamma setting with 
the recommended default of 2.2 (unless you know what you are doing ;-P) 
and the exception of high dynamic range formats being always encoded 
linear (as they should be by definition).

C.2. is true for POV-Ray 3.7 AND 3.6 and PNG input format except when no 
gamma chunk was present when POV-Ray 3.6 did apply no correction at all 
(see below).

C.1. is true for POV-Ray 3.7 and any other format than PNG
BUT POV-Ray 3.6 did use the gamma encoded values internally directly 
without converting them to linear color space and this was plain wrong!

-Ive (and sorry for sending the mail - this happens to me all the time, 
I really should learn how to use Thunderbird)

Post a reply to this message

On 12/02/2010 02:01 AM, Jaap Frank wrote:
> That's odd, because for me the 3.6 side is correct and the 3.7 side is
> far too bright.
> I've a rather new HD LCD TFT monitor (about 6 months) and adjusted it
> conform the windows 7 system with brightness and contrast followed by
> color shade correction.
> Further the monitor of my laptop (Acer Aspire, 1 year old, crystal clear
> display) shows exactly the same picture. Both are driven by the NVidia
> card inside the laptop, so they should be the same and for /me/ they
> are. The pictures are displayed by Windows Live Mail.

  Note that at least with some LCD displays (especially on some laptops)
the angle from which you look at the screen affects the brightness. For
example, if I look at the image I posted in a MacBook laptop, I can
"tune" the "gamma correction" of the display by tilting the screen back
or forth (thus changing the vertical angle from which I look at the
screen). At some angles it looks like the brightness of the sides
correspond to the center of the 3.6 gradient (and thus the 3.7 gradient
is too bright), while at other angles it looks like they correspond to
the center of the 3.7 gradient (and thus the 3.6 gradient looks too
dark). (And everything in-between, of course.) This tells me that the
screen on this laptop is an *extremely* poor tool to determine which one
is correct (if either), because I can change it by simply looking at it
from a higher or a lower angle.

  I do understand, however, that many of the more modern and expensive
LCD displays don't suffer from this problem (at least not as badly).

  If I had a working camera I could take photos to corroborate these
findings, but unfortunately I don't.

Post a reply to this message

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

> Okay, so the problems with Steve Gower's scene are obviously unrelated
> to the gamma changes in POV-Ray 3.7.

I don't know. I don't know the inner workings of all the changes that have been
made or how they interrelate. Can anyone? POV's turned into a pretty complex
organism. I just couldn't get it to work. And if that doesn't work I'm assuming
there's a lot of other scenes that won't work. They don't have to, of course.
But it worked fine in 3.6 (as #version 3.0). How stuff made in 3.6 will come out
in 3.7 (as #version 3.6) we'll see.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

> 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.

Your gammachecker_3.6 is fascinating. Is the scene file floating around
somewhere. I assume from the title it's done in 3.6 -- if that makes any
difference.

I don't really understand how this tests gamma, though, which in practical
terms, for how I use it, has to do with the relative relation of highlight and
midtones and shade and shadow, or in Photoshop terms, "curves."

Post a reply to this message