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?

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: [...]

That would make an *excellent* set of tools, covering every possible scenario
AFAIK. Kudos for the concept! Not that I would want to continue indefinitely
with the *old way* of doing things re: gamma--but it sure makes 'the paradigm
change' easier to swallow ;-)
>
> There will also be some caveats regarding PNG input files.

Not unexpected. There was always a hidden caveat anyway, when using png input
images in v.3.6.1 (with assumed_gamma 2.2)--the only good way to get them to
reproduce *as expected* was to embed a gamma of 1.0 into them, via Photoshop or
some such. (At least, that was my own experience, using my *legacy* version of
Photoshop 5.0.)

Ken

Post a reply to this message

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.

Post a reply to this message

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