"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