Am 10/18/2017 um 14:24 schrieb Kenneth:
> 
> I can't say that I know exactly what I'm doing with this experiment-- ha!-- but
> is  0.72941  the correct value for the gamma 2.2 swatch? (I assume it is, of
> course, but I wanted an expert's opinion.)
> 
Calculate for yourself:  0.5 ^ (1 / 2.2) = ?
Also note that sRGB is NOT equal to gamma 2.2.

-Ive

Post a reply to this message

Ive <ive### [at] lilysoftorg> wrote:
> Am 10/18/2017 um 14:24 schrieb Kenneth:
> >
> > I can't say that I know exactly what I'm doing with this experiment-- ha!--
> > but is  0.72941  the correct value for the gamma 2.2 swatch? (I assume it
> > is, of course, but I wanted an expert's opinion.)
> >
> Calculate for yourself:  0.5 ^ (1 / 2.2) = ?

0.72941 !  (or almost)
But I was somehow thinking (in a fuzzy way) that the gray swatch for gamma 2.2
should perhaps measure as 0.5 instead-- with 0.5^2.2 resulting in .217, the
'gamma corrected' equivalent of 'half brightness' (0.5).  In any case, it was
just some 'idle philosophical thought' ;-) But I wanted to make sure that the
gray swatches themselves had been well thought-out, all those eons ago.

> Also note that sRGB is NOT equal to gamma 2.2.

Agreed; I simply think of 2.2 and sRGB as 'functionl equivalents', more or less,
practically speaking.

Post a reply to this message

Am 10/18/2017 um 16:32 schrieb Kenneth:
> Ive <ive### [at] lilysoftorg> wrote:
>> Am 10/18/2017 um 14:24 schrieb Kenneth:
>>>
>>> I can't say that I know exactly what I'm doing with this experiment-- ha!--
>>> but is  0.72941  the correct value for the gamma 2.2 swatch? (I assume it
>>> is, of course, but I wanted an expert's opinion.)
>>>
>> Calculate for yourself:  0.5 ^ (1 / 2.2) = ?
> 
> 0.72941 !  (or almost)
> But I was somehow thinking (in a fuzzy way) that the gray swatch for gamma 2.2
> should perhaps measure as 0.5 instead-- with 0.5^2.2 resulting in .217, the
> 'gamma corrected' equivalent of 'half brightness' (0.5).  

Well, the gamma corrected equivalent of linear 'half brightness' isn't 
the power of 2.2 but the inverse, therefor 0.5 to the power of 1/2.2

-Ive

Post a reply to this message

Am 18.10.2017 um 14:24 schrieb Kenneth:
> SO... getting back to POV-Ray's built-in gamma set-up chart...
> 
> As that chart was made many eons ago, I had a desire to see if it is still
> 'accurate' in the modern world ;-)  Leaving no stone unturned, I copied that
> image and took it into both my (older) Photoshop, and a recent version of GIMP--
>  to check not the thin horizontal bars, but the gray 'gamma' swatches that they
> are compared against.  (BTW, both of my apps are working in sRGB color/gamma
> space.) Using the 'eyedropper' tools there, I measured the gamma 2.2 swatch. Its
> brightness value in both apps reads as 186/255, or 0.72941    And 0.72941^2.2 =
> 0.49950, or almost exactly 0.5
> 
> I can't say that I know exactly what I'm doing with this experiment-- ha!-- but
> is  0.72941  the correct value for the gamma 2.2 swatch? (I assume it is, of
> course, but I wanted an expert's opinion.)

IF your display subsystem has a gamma of 2.2, THEN the corresponding
swatch, when displayed, should result in a physical brightness of 0.5.

In other words, the swatch should have a brightness value of N such that:

    (N/255)^2.2 = 0.5

The (N/255) part is the stored value normalized to the [0..1] range, and
the ^2.2 part is the effect of the display's non-linearity.


BTW, the swatch-based assessment has some more limitations than just the
zoom/interpolation issue:

- It relies on the image being displayed "as is", without any active
gamma correction, just the "native" effect of the display subsystem. If
for example your display is calibrated to the Adobe RGB colour space,
and the displaying software is aware of this fact and presumes the image
data to be stored in accordance to the sRGB standard, then this approach
will give nonsense results because the display software will introduce
another non-linear conversion that is not part of the native display.

- It naively presumes the display subsystem's native transfer function
to match the form f(x) = x^gamma. For display subsystems calibrated to
e.g. the sRGB, ITU-R BT.709 or ITU-R BT.2020 standards this is
specifically not the case (for the modern ITU-R BT.2100 standard, aka
HDR TV, it is probably not even close), and you'll get a gamma value
that is only valid for 50% physical brightness.

Post a reply to this message

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

>
> BTW, the swatch-based assessment has some more limitations than just the
> zoom/interpolation issue:
[snip]
> - It naively presumes the display subsystem's native transfer function
> to match the form f(x) = x^gamma. For display subsystems calibrated to
> e.g. the sRGB, ITU-R BT.709 or ITU-R BT.2020 standards this is
> specifically not the case (for the modern ITU-R BT.2100 standard, aka
> HDR TV, it is probably not even close), and you'll get a gamma value
> that is only valid for 50% physical brightness.

*That's* interesting-- because, after all of this info, I'm *still* having
trouble getting my new monitor to look really accurate! (Not due to any problems
with POV-Ray's gamma set-up tests).  My monitor is a consumer-level VIZIO, a
so-called 'LED' type (which seems to mean only that the 'edge lighting' is from
LEDs-- otherwise, it's an LCD monitor.) It has only typical 'consumer-friendly'
controls-- brightness, color, contrast, tint.. and 'backlight', which looks to
simply brighten or dim the entire image. Otherwise, nothing fancy. Trouble is,
if I set it for a correct gamma of 2.2-- as best I can-- then the overall screen
appearance just doesn't look decent (tonal values and colors.) Depending on the
particular digital-photo image I view on the web, any *slight* off-kilter color
cast is accentuated.  Quite frustrating!

Gamma adjustment is a 'non-linear' thing, of course; but my  monitor seems to
have a NON-LINEAR non-linear response(!)-- at least regarding color intensities.
Green looks a bit too intense... but decreasing the 'green' amount only makes
images look worse.  I do know that our eyes are 'attuned' to seeing shades of
green better than other colors...but something just doesn't look right.  The
monitor also shows BIG visual differences re: the vertical viewing angle. (The
POV-Ray gamma chart's horizontal lines are an 'acid test' for this particular
problem.) And those black/white lines have a slight yellowish color-cast (when
'eye-blurred')-- i.e., not true gray.

Windows 7's built-in 'monitor calibration' feature seems to be quite useless,
BTW. The example *image* there for setting contrast is a guy in a white wrinkled
shirt, along with a black "X" seen against a black(er) background. But it's so
prone to an 'opinion' of correctness that it stinks. But I used it anyway.

Then, returning to POV-ray's older gamma set-up chart at "3.2.3.2 Setting your
Display Gamma", the monitor gamma actually looks decent... more or less. I'm
surprised!

In the newer docs section "2.3.4.1 Setting Up Your Display", with the colored
spheres, the main example image there looks correct as well, gamma-wise, as seen
within the documentation. So far, so good! At this point, my monitor is at the
best settings I can manage to get :-/  (And yes, it's set to its native
resolution -- 1920 X 1080)

As a final test,  I rendered the 'gamma_showcase' file, at both of its
recommended command-line settings. The docs say, "At 100% zoom, both images
should look identical in your viewing software." Is that true?? I ask because
the two PNG images look *radically* different from each other, in all of my
viewing apps including Windows' own image viewer...

.....EXCEPT in Ive's IC/Lilysoft app! There, they both look identical... which is
quite interesting, regarding our previous discussions about PNG gamma and
viewing apps ;-)  And it raises an obvious question, concerning either the
documentation OR the method of how that sphere-test was created:  Is IC the
'target app' for viewing the rendered images? If so, that leaves out lots of
other 'typical' image-viewer apps-- possibly an unintended consequence of the
test scene. As gamma is an important issue, the documentaion needs to mention
this (or the test scene itself needs reworking somehow, to be more inline with
the majority of 'wrong-PNG-gamma' viewing apps??)

Hmm, this smells like a conundrum  :-0

Post a reply to this message

Am 10/25/2017 um 1:44 schrieb Kenneth:
> ......EXCEPT in Ive's IC/Lilysoft app! There, they both look identical... which is
> quite interesting, regarding our previous discussions about PNG gamma and
> viewing apps ;-)  And it raises an obvious question, concerning either the
> documentation OR the method of how that sphere-test was created:  Is IC the
> 'target app' for viewing the rendered images? If so, that leaves out lots of
> other 'typical' image-viewer apps-- possibly an unintended consequence of the
> test scene. As gamma is an important issue, the documentaion needs to mention
> this (or the test scene itself needs reworking somehow, to be more inline with
> the majority of 'wrong-PNG-gamma' viewing apps??)
> 

IC is not related to POV-Ray in any way and it is not a 'target app' for 
anything.
It just happens that it is accurate for the image formats it supports 
because it's original back-end-library was designed for the use in the 
medical sector where this might even be a matter of life and death.

Which reminds me that I'm using a much improved version of IC by myself 
and really should make it available for download - but as I did already 
point out somewhere else: I'm lazy!
But I did post a test-pattern for you to p.b.i.

-Ive

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> *That's* interesting-- because, after all of this info, I'm *still* having
> trouble getting my new monitor to look really accurate! (Not due to any problems
> with POV-Ray's gamma set-up tests).  My monitor is a consumer-level VIZIO, a
> so-called 'LED' type (which seems to mean only that the 'edge lighting' is from
> LEDs-- otherwise, it's an LCD monitor.) It has only typical 'consumer-friendly'
> controls-- brightness, color, contrast, tint.. and 'backlight', which looks to
> simply brighten or dim the entire image. Otherwise, nothing fancy. Trouble is,
> if I set it for a correct gamma of 2.2-- as best I can-- then the overall screen
> appearance just doesn't look decent (tonal values and colors.) Depending on the
> particular digital-photo image I view on the web, any *slight* off-kilter color
> cast is accentuated.  Quite frustrating!

What you describe sounds like colour gamut and/or whitepoint issues to me, which
are quite unrelated to gamma (except that they can all be subsumed under the
topic "colour space").

By recommendation of the W3C, images on the web (and, as a de-fact consequence,
everywhere images are exchanged without further specification of colour space)
should by default be encoded for the sRGB colour space, which was designed to
match an average CRT display. Therefore, the primary colours match typical CRT
phosphors, which are comparatively "impure", limiting the gamut (i.e. the range
of colours that can be displayed accurately).

Displays with an LED backlight often have "cleaner" primary colours, which give
a wider gamut. This is often advertised as giving more "vibrant" colours, but
this has two sides: Not only /can/ such displays render more vibrant colours,
they also /do/ interpret the same colour values as more vibrant than a
sRGB-compliant display woud.

As an additional problem, such displays' primaries differ from those mandated by
the sRGB standard not only in saturation, but sometimes also in hue (and
occasionally brightness, but since that can usually be tuned it is less of a
problem). Most notably, the Adobe RGB colour space (which is becoming
increasingly popular in displays) has a notably less yellowish green primary. As
an effect, any colour on the red-yellow-green axis would be displayed with a
more greenish tint than on an sRGB device.

There are three possible general solutions for this issue:

(A) Fix it at the display. Some displays have settings to change the display's
effective colour profile; often the settings aren't labeled with colour space
names, but are called "Video", "Image" or some such. However, from your
description I would presume your display doesn't have such a thing. (As you
already noticed, just tuning the brightness of the primaries doesn't have the
same effect; it just shifts the whitepoint, not the effective primary colours.)

(B) Fix it in your software. Usually this involves telling the operating system
about your display's properties (installing an "ICC colour profile" that matches
your display), and telling your software that by default you want images to be
interpreted as sRGB or "web standard". This may be a software's default, and
really good software should also be able to identify POV-Ray's PNGs as "sRGB"
automatically. However, some software may need extra coaxing to use sRGB as the
default, and cheapo software out there may not support such stuff at all.

I /think/ (though I would have to revisit this myself) that in modern Windows
you can not only specify the display's colour profile (so that software can
query it by system call and adapt accordingly), but also a working profile for
Windows itself (so that Windows takes care of the translation itself). If you
set that one to sRGB, that should solve the problem for cheapo software.

(C) Fix it in your graphics adapter. Technically this is just a matter of
populating a lookup table the adapter uses anyway, translating screen buffer
values to the actual values sent to the display. The challenge is in finding a
piece of software that does this job for you each time your computer starts up:

- Old versions of Adobe Photoshop came with a tool that could do this job. Don't
remember details off the top of my head though.

- IIRC some graphics card also come with such a tool (though it may need
separate installation).

- Professional display calibration hardware (colorimeters; sensors you dangle in
front of your screen to measure what your display is actually showing) always
comes with such a piece of software.


> As a final test,  I rendered the 'gamma_showcase' file, at both of its
> recommended command-line settings. The docs say, "At 100% zoom, both images
> should look identical in your viewing software." Is that true?? I ask because
> the two PNG images look *radically* different from each other, in all of my
> viewing apps including Windows' own image viewer...
>
> .....EXCEPT in Ive's IC/Lilysoft app! There, they both look identical... which is
> quite interesting, regarding our previous discussions about PNG gamma and
> viewing apps ;-)  And it raises an obvious question, concerning either the
> documentation OR the method of how that sphere-test was created:  Is IC the
> 'target app' for viewing the rendered images? If so, that leaves out lots of
> other 'typical' image-viewer apps-- possibly an unintended consequence of the
> test scene. As gamma is an important issue, the documentaion needs to mention
> this (or the test scene itself needs reworking somehow, to be more inline with
> the majority of 'wrong-PNG-gamma' viewing apps??)

In theory, good software /should/ indeed behave like Ive's IC.

Historically, the only reason why software didn't, was because their developers
were unaware of colour space issues in general (of which gamma issues are a
subset). In other words, crappy software.

But Alas! Today it seems that even good software doesn't, presumably because
their developers are /too much/ aware of colour space issues in general.

You see, in PNG there are two levels of colour space handling:

(1a) Gamma handling: There is an optinal header field, "gAMa", which tells
displaying software that the image was encoded with a particular gamma. This is
what POV-Ray normally uses to convey gamma information.

(1b) Chromaticity handling: There is also an optinal header field, "cHRM", which
tells displaying software that the image was created with a particular set of
primary colours and whitepoint in mind. (As POV-Ray is currently unaware of
gamut and whitepoint, it does not use this field.)

(2a) Full-fledged colour space handling: There is another optional header field,
"iCCP", which can be used instead of (1a) and (1b) to convey the same
information, while at the same time being much more flexible (most notably
supporting non-power-law "gamma" curves). In essence, rather than storing gamma
and chromaticity parameters, the colour space is represented via a
lookup-table-ish mechanism.

(2b) Standard colour space: There is yet another optional header field, "sRGB",
which can be used instead of (2a) to tell displaying software that the colour
profile is the one defined in the sRGB standard.

I have a hunch that (2a) and (2b) have become so widespread in actual image
material that developers are no longer paying any attention to the alternatives
(1a) and (1b) as alternatives (even more so since each by itself is technically
insufficient to define how any given colour value triplet is to be displayed, so
developers would have to implement some guesswork there).

To solve this (without rewriting the display software or choosing IC), there
seems to be no way except for POV-Ray to be made aware of the colour primaries
and whitepoint used (or at least pretend). Maybe writing a "cHRM" chunk in
addition to the "gAMA" chunk will suffice. If an "iCCP" chunk turns out to be
necessary, it would probably require adding a 3rd party library. (Not that it
would be a bad thing; making POV-Ray fully colour space aware is on my agenda
anyway.)

Post a reply to this message

Ive <ive### [at] lilysoftorg> wrote:
>
> IC is not related to POV-Ray in any way and it is not a 'target app' for
> anything.
>
Sorry for the bad choice of words; what I meant was, I suspected that the
'sphere' gamma-test scene was made *using* IC, with its correct interpretation
of PNG gamma (as opposed to the plethora of apps that are wonky in that
respect.) Discovering that those many apps fail such a test-- with the exception
of Firefox-- was a surprise!
>
> Which reminds me that I'm using a much improved version of IC by myself
> and really should make it available for download - but as I did already
> point out somewhere else: I'm lazy!
> But I did post a test-pattern for you to p.b.i.
>
Yes indeed; VERY useful, and takes much of the guesswork out of the dreaded
'gamma Hydra beast'  ;-)

Post a reply to this message

"clipka" <nomail@nomail> wrote:
>
> What you describe sounds like colour gamut and/or whitepoint issues to me,
> which are quite unrelated to gamma (except that they can all be subsumed
> under the topic "colour space").
[snip]
>
> Displays with an LED backlight often have "cleaner" primary colours,
> which give a wider gamut. This is often advertised as giving more "vibrant"
> colours, but this has two sides: Not only /can/ such displays render more
> vibrant colours, they also /do/ interpret the same colour values as more
> vibrant than a sRGB-compliant display would.
>

Yeah, this 'vibrant color' issue is one of the main reasons why I kept putting
off the purchase of my first flat-panel monitor years ago; my older CRT monitors
(of which I still have ONE working model, thankfully) just looked more 'natural'
to me. And still do ;-)

As to iCC profiles and other assorted goodies...
My Win 7 computer has a built-in graphics chip: Intel Q965/Q963 Express Chipset
family. (I've never installed a 3rd-party graphics *card* on any computer, BTW.)
From some research I've done, Windows (starting with Vista) began using its own
color gamut-mapping feature or converter, called WCS (Windows Color System). In
Win 7's own "Color Management" app ('advanced' tab), these are the various
parameters I see:

Rendering intent: I set it to "Perceptual (photo images)"

ICC profile-- apparently only one is installed on my computer (or none at all?):
"sRGB display profile with display hardware configuration data derived from
calibration."

Device profile: "System default (sRGB IEC61966-2.1)"
Viewing conditions: "System default (WCS profile for sRGB viewing conditions)"

And, in the "ICC Rendering Intent To WCS Gamut Mapping" section :
Default rendering intent: "System default (perceptual)"
Perceptual (photo images): "System default (photography)"
-- (the rest of it looks to be unimportant, for my usage; all are system
defaults)--

Does all of this make perfect sense to me? Well...  :-(  I guess I should try
and find an iCC profile for my specific monitor, as you suggest.

For rendering POV-Ray scenes, this is my current set-up:
monitor at its native resolution -- 1920 X 1080
Display_Gamma = srgb
File_Gamma=srgb
assumed_gamma 1.0

Post a reply to this message

Am 25.10.2017 um 19:37 schrieb Kenneth:

> My Win 7 computer has a built-in graphics chip: Intel Q965/Q963 Express Chipset
> family. (I've never installed a 3rd-party graphics *card* on any computer, BTW.)
> From some research I've done, Windows (starting with Vista) began using its own
> color gamut-mapping feature or converter, called WCS (Windows Color System). In
> Win 7's own "Color Management" app ('advanced' tab), these are the various
> parameters I see:
> 
> Rendering intent: I set it to "Perceptual (photo images)"
> 
> ICC profile-- apparently only one is installed on my computer (or none at all?):
> "sRGB display profile with display hardware configuration data derived from
> calibration."
> 
> Device profile: "System default (sRGB IEC61966-2.1)"

That's the one you want to change. Otherwise, Windows and all other
colour-space-aware software will think that your display conforms to sRGB.

Post a reply to this message