Am 26.03.2018 um 01:45 schrieb Kenneth:
> By the way, if my memory is not faulty, an embedded 'gamma' and an embedded 'ICC
> profile' may actually be separate things(?)-- one dealing with image gamma, the
> other with a specific 'color profile.' My apologies if I'm confused about that
> distinction, or if there *is* a distinction.

Full-fledged colour management is comprised of various components:

(0) Definition of a colour model: It needs to be defined what basic
properties the three (or four) colour channels denote. The most common
formats for actual image storage are probably RGB (Red, Green, Blue
3-channel additive model as used by most displays), YCbCr (brightness
and chromaticity 1+2 channel model as used in TV broadcast as well as
JPEG-style compression) and for some purposes CMYK (Cyan, Magenta,
Yellow, Black=Key 4-channel subtractive model as used in printing);
other models such as HSV, HSL, LUV, XYZ, XyY and whatnot are rarely used
in this role. (Another common colour model is monochrome, i.e. a
1-channel brightness-only model.)

(1.0) Definition of a whitepoint: It needs to be defined which hue and
saturation the data triplet (255,255,255) denotes. Typical whitepoints
for standard colour spaces would be the CIE whitepoints D65 (daylight)
or D50 (compromise between daylight and artificial light); typical
whitepoints for displays or image sensors on the other hand may vary widely.

(1.1) Definition of a luminance level: It may also be desirable to
define which absolute brightness the data triplet (255,255,255) denotes.
For example, the sRGB standard prescribes a brightmess of 80 cd/m^2.

(2) Definition of the primaries: It needs to be defined which hue,
saturation and relative brightness (compared to the whitepoint) the data
triplets (255,0,0), (0,255,0) and (0,0,255) denote.

(3) Definition of a blackpoint: Since many real-life displays and image
sensors cannot render or sense true black, it may need to be defined
which hue, saturation and relative brightness the data triplet (0,0,0)
denotes.

(4) Definition of intermediate values: Since many real-life displays and
image sensors have some non-linearity to them, and also because storing
image data in a non-linear format is more memory-efficient, it needs to
be defined which hue, saturation and relative brightness each and every
given data triplet denotes.

(4a) One naive but very inefficient method of defining intermediate
values would be by storing an exhaustive table.

(4b) A typical approach for defining the colour space of real-life
displays or image sensors is to store the hue, saturation and relative
brightness for a selection of sample triplets, and interpolate for
in-between values (sometimes using linear curves, and sometimes using
spline-ish constructs).

(4c) For standard colour spaces (as opposed to colour spaces real-life
displays or image sensors operate in), another option is to define
encoding/decoding curves that are applied to each colour channel separately.


Gamma handling technically covers (4c) and nothing more.

ICC profiles cover (1.0), (2), (3) and either (4b) or (4c); whether they
also cover (1.1) is beyond my knowledge.


The PNG format defines mechanisms for...

(A) dealing with none of the above (the default as per file format);

(B) dealing with (1.0) and (2) via a cHRM chunk, and/or with (4c) via a
gAMA chunk;

(C) dealing with (1.0) through (4) by referring to the sRGB standard
colour space via an sRGB chunk; or

(D) dealing with (1.0) through (4) by specifying an custom ICC profile
via an iCCP chunk.

Apparently, mechanisms (B) and (C) are rarely supported by contemporary
software, while POV-Ray currently only supports (B) and (C).

Also, it is recommended that (C) and (D) are /not/ combined; so if an
image conforms to sRGB, it should theoretically use (C), but in practice
seems to have to use (D), and in theory should then do so /instead/.

Post a reply to this message