In a recent newsgroup thread by Thomas, a sub-topic arose about 'ICC profiles'
in JPEG and PNG images that are posted to the internet-- essentially about
whether or not the images actually show up as visually intended. As this seems
to be a rather important topic (to say the least!), I thought it best to start a
separate thread about the questions and comments that were posted there.

Thomas's original thread, for reference...
http://news.povray.org/povray.binaries.images/thread/%3Cweb.5ab82726b126f8c9a47873e10%40news.povray.org%3E/

Ive wrote...
> And a general note to everybody who's posting images to theses
> newsgroups: please make sure your JPEG image contains a ICC profile.
> Since about 2 months Firefox and Thunderbird have full color management
> enabled by default. Chrome and Opera do the same since quite a while,
> [...]

And Clipka wrote...
> ...the W3C officially recommends sRGB for all web content, so that's what
> browsers should default to if an ICC profile is not embedded.
>
> Also, a lot of images posted here are rendered with POV-Ray, which
> currently does not embed an ICC profile. So to comply with your request,
> each and every image would have to be post-processed before posting,
> which I consider unreasonable.
> [...]

My own *current* understanding of JPEG images is that they do not include an ICC
profile (and never have?) And that the vast majority of general graphics apps do
not 'embed' any profile in them. Meaning, the image will show up 'more or less'
as intended by the person who made it... assuming the image was made in an app
that was working in either a gamma 2.2 or sRGB color/gamma space-- the two
genarally-accepted defaults.

As others mentioned in the previous thread, I likewise don't know how to embed a
specific ICC profile into a JPEG image, or if it is even necessary.

For PNG images (whether made in POV-Ray or elsewhere), my current understanding
is that they DO have an embedded ICC profile, created when the image was made.
That profile would generally be either gamma 2.2 or gamma sRGB, depending on the
particular app... which *should* match the display gamma of a
monitor/computer... or rather, the *intended* or expected display gamma.

One main question seems to be: Should JPEG images *have* an embedded ICC
profile? And if so, how is that done?

There are other questions about this situation that need discussing-- but I
don't yet know what to ask ;-) It's all quite complex and technical.

Post a reply to this message

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.

Post a reply to this message

On 26-3-2018 1:19, Kenneth wrote:
[snip]

> As others mentioned in the previous thread, I likewise don't know how to embed a
> specific ICC profile into a JPEG image, or if it is even necessary.
> 

Look atIve's site: http://www.lilysoft.org/IC/ic_index.htm

The new IC version can embed an ICC profile in a jpeg image. As far as I 
can judge for now, The Gimp cannot.

-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:

>
> Look atIve's site: http://www.lilysoft.org/IC/ic_index.htm
>
> The new IC version can embed an ICC profile in a jpeg image. As far as I
> can judge for now, The Gimp cannot.
>

Yes, I plan to update my version of IC asap; thanks. Although, it's still not
clear to me why a JPEG image needs a color profile, or *doesn't* need one.

I also came across this, which explains some of the reasons for ICC profiles,
why some image file types don't have embedded ones, etc. I can't say if this is
a 'definitive' explanation, but it describes the basics at least. (Although, the
opinion there about the sRGB color space might be controversial.)

https://ninedegreesbelow.com/photography/embedded-color-space-information.html

Interestingly, the article says something like, "GIMP expects to see an embedded
color profile when it loads an image"... but apparently it doesn't WRITE a
profile to an image. That's a bit strange ;-)

The comments from Ive and Clipka have raised some interesting questions, IMO.

Post a reply to this message

On 26-3-2018 10:21, Kenneth wrote:
[snip]
> Interestingly, the article says something like, "GIMP expects to see an embedded
> color profile when it loads an image"... but apparently it doesn't WRITE a
> profile to an image. That's a bit strange ;-)
> 
> The comments from Ive and Clipka have raised some interesting questions, IMO.
> 

Indeed. Indeed. I confess I will leave the discussion to my betters. I 
have no understanding of the matter. :-)

-- 
Thomas

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

>
> For PNG images (whether made in POV-Ray or elsewhere), my current understanding
> is that they DO have an embedded ICC profile, created when the image was made.
> That profile would generally be either gamma 2.2 or gamma sRGB, depending on the
> particular app... which *should* match the display gamma of a
> monitor/computer... or rather, the *intended* or expected display gamma.
>

Clipka explained this PNG stuff in another thread awhile ago (in a far better
way), and I'm probably mistaken about some of the details here.

Post a reply to this message

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