|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |