Open Bug 1639584 Opened 4 years ago Updated 1 month ago

Color management different with or without embedded color profile

Categories

(Core :: Graphics: Color Management, defect)

Product:
Core
Component:
Graphics: Color Management
Version:
77 Branch
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox-esr68 --- unaffected
firefox76 --- unaffected
firefox77 --- disabled
firefox78 --- disabled
firefox79 --- disabled

People

(Reporter: bugzilla, Unassigned)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0

Steps to reproduce:

Firefox 77 with gfx.color_management.mode = 1

Images with embedded sRGB profiles appear different to images without embedded profiles.

All images should appear the same. All images are already in sRGB colour space.

See sample images and screenshots at https://www.nedmartin.org/v3/public/colour-management-test.html

Actual results:

Images with embedded colour profile look different to images without embedded colour profile.

Expected results:

All images should look the same.

Component: Untriaged → GFX: Color Management
Product: Firefox → Core

You're referring to the difference in shadow detail? It could be related to the "linear segment" or "toe" in a proper sRGB implementation. A proper sRGB implementation does not have a tone reproduction curve defined by a gamma 2.2 function. It's defined by "the sRGB curve". There are two common implementations and they both just get called sRGB.

Point 2, which says gamma 2.2 is an approximation, versus point 8.
http://www.color.org/srgb.pdf

Open question for Mozilla folks if Firefox color managemet is using a TRC defined by gamma 2.2 or if they're using the actual sRGB curve as the "source profile" in the transformation to (user) display RGB, i.e. when the image doesn't have a profile embedded in it.

Also for what it's worth, cameras don't use ICC profiles (I can't think of one anyway), but rather use EXIF to tag the JPEG with a single encoded value that translates into sRGB. Therefore it's up to the viewer to properly implement such a transformation. And whether Firefox's JPEG support honors EXIF is a valid question, because there's a value to define the source space as Adobe RGB (1998) which is defined with a gamma 2.2 function. And there's a way to define arbitrary spaces in later versions of EXIF.

But there's more. A proper sRGB implementation is defined with a white luminance of 80 nits (candelas per meter squared) which is not very bright by today's display standards (they come out of the box at 300+). And then there's black luminance of 0.2 nits. Both include veiling glare, the effect of ambient light reflecting off the face of the display back to the viewer. And to get to such a low black level requires a ambient luminance level of 64 lux or less. Almost no one is doing that these days. And as sRGB is an output color space, an image rendered for sRGB really does expect to be viewed in such conditions, even to be approximate to the original scene. It was a difficult problem 20 or so years ago, and today it's even harder mainly because of lack of controlling the environment with mobile devices and laptops everywhere. I had to drop the office room lighting quite a bit to see the difference in shadow detail between the example images.

Andrew, do you happen to know?

Severity: -- → S3
Flags: needinfo?(aosmond)

By the way, when I say "a proper implementation" I mean that in the strict sense. I don't mean to indicate that the (very common) alternative is inappropriate or disqualified. Perhaps it would be "nice to have". I think we can recognize that difference in shadow detail between a gamma 2.2 function, and sRGB function, for defining the tone reproduction curve, is really small compared to the real world impacts of ambient lighting being all over the map. And the very real problem of display devices diverging from sRGB.

Were it true that we had reliable built-in ways (hardware sensors, software APIs) to compensate for all of these surround, ambient, and adaptation effects, then yeah sure we'd more strongly want a "proper" implementation.

difference in shadow detail between a gamma 2.2 function, and sRGB function, for defining the tone reproduction curve, is really small compared to the real world impacts of ambient lighting being all over the map [emphasis mine]

This, while very true, won’t nullify the fact that on the same display, whatever its characteristics, images converted using proper and 2.2 gamma curves will look different when put next to each other, though. Or when compared to properly colour-managed application. No?

If it’s about computation complexity, would these, much closer, approximations be better than 2.2 gamma curve?

(In reply to paperboyo from comment #4)

This, while very true, won’t nullify the fact that on the same display, whatever its characteristics, images converted using proper and 2.2 gamma curves will look different when put next to each other, though. Or when compared to properly colour-managed application. No?

Proper color management actually means having the proper ambient condition and observer adaptation. That's what the color science is predicated on, so if the ambient is wrong or the observer partially adapted, then the color management is also off. i.e. it is not the case that color management is strictly about transforms.

On an sRGB calibrated display, the two images look similar. And at unmodified scale, I didn't see a difference right away. Enlarged, it's noticeable. Does it evoke a different response? Yeah maybe, and in that sense it's meaningfully different.

If it’s about computation complexity, would these, much closer, approximations be better than 2.2 gamma curve?

That I don't know. That's mostly about ICC profile size for the purpose of embedding and transmitting the profile times millions and billions. (Hence the far cheaper EXIF tag should be honored equivalent to the real sRGB color space.) The computational complexity is going to be the same, regardless of profile size because the implied TRCs are the same, and that's what indicates the nature of the transform, and its expense.

But if I had to guess, it's pretty cheap because Photoshop was doing display compensation 20 years ago, with no performance impact. How they optimized this I don't know. Probably they only ever do transforms on the actual pixels that will be displayed, rather than on all the pixels in the image. A long time ago the way Apple's early ICCv2 engine did transforms, they built what was called a 'color world' - they didn't actually push pixels through two profiles. They took two profiles and created one transformation as a LUT, and then just pushed all pixels through that LUT. Super cheap back then. Today the things that were expensive are now cheap and the cheap things aren't as cheap because of all the optimizations. So I have to leave such things up to others.

So yeah, if you can to things strict and it's just as cheap. Do that.

Proper color management actually means having the proper ambient condition and observer adaptation.

Yeah. I was just thinking about a flat brand colour in an SVG without a profile (with assumed), next to an AVIF with an embedded proper sRGB on a CSS background – all with the same numbers, looking ever so slightly different no matter how well controlled and correct (or not) is the environment. Seems pretty academic until someone sends a screenshot of the difference between them only in Firefox they are unable to fix :-).

Looks like Chrome is using a simple gamma function too. What is the correct thing to do? Mimic Safari and Chrome? Or Photoshop and GIMP? Split the difference (a 3rd variant)?

I don't know the exact origin story of using a gamma function to approximate the TRC but I'm willing to bet it was a space savings technique, because the LUT is much bigger than a single gamma function.

😱 I wrongly assumed nobody is doing gamma 2.2 for sRGB!

What is the correct thing to do? Mimic Safari and Chrome? Or Photoshop and GIMP?

I’m just a pixel guy. Faced with the (hypothetical!) scenario I’ve concocted above, I wouldn’t know how to fix it and would need to work hard to learn what is used where and convert images or strip profiles to workaround differing implementation(s). So I would vote to be correct in the first place. But I have zero idea how much harder that might be. Re:mimicking other browsers’ implementations instead: I can’t imagine anyone complaining that they want to match incorrect behaviour, but we users are an inventive bunch…

First step, there should be a confirmation that the proposed explanation does in fact account for the entirety of what's being seen. There could be more than one thing going on.

Second, maybe it's sane to have an interim period where it uses a gamma 2.2 function and a "flag day" for the browsers to flip over to sRGB. Ergo they need to implement both. I don't have all the relevant standards, there was something about it in CSS3 but I think it got pulled (not certain).

Untagged images are in the sRGB color space. Videos are different.
https://www.w3.org/TR/css-color-4/

This
https://www.w3.org/TR/css-color-4/#biblio-srgb
points to this
https://webstore.iec.ch/publication/6169

And IEC 61966-2-1:1999 certainly includes the linear segment. So I'm pretty sure that the intent is that untagged images should simulate the toe. Maybe Chris Lilley can tell us, adding to cc.

Confirming that sRGB does have a small linear portion, followed by a 2.4 exponent function. The result is similar to, but not the same as, a 2.2 gamma especially in the shadow area. This could explain why the dark trees against a slightly lighter sky just go to all black when the profile is not there.

Confirming too that untagged images should be treated as if they have an sRGB profile, per CSS4. I thought all browsers were doing that now.

I didn't go as far as to extract the ICC profiles from the images to look at them.

If it’s about computation complexity, would these, much closer, approximations be better than 2.2 gamma curve?

Those optimizations are about filesize, especially for tiny thumbnail images where an ICC RGB profile can be a sizeable proportion of the total. They are not about implementation complexity, because the typical implementation populates a 256-element lookup table and off you go. So doing it wrong and doing it right are similar in implementation cost.

BTW the Adobe 1998 RGB space is not quite a 2.2 gamma; it is a 256/563 gamma because those two values fit into the binary values used in v.2 ICC profiles.

Firefox has just recent started to, by setting gfx.color_management.mode=1. And there are some bug reports describing regressions.
https://bugzilla.mozilla.org/show_bug.cgi?id=455077

In Chrome, untagged images look like the TRC is defined by a gamma 2.2 function, not the sRGB curve. I'm not certain about Safari.

Since the point of any specification referring to a color space intends to describe the entire encoding, the intent is that the TRC should be defined by the sRGB curve, not a gamma 2.2 function. But in practice, since using gamma 2.2 is considered an approximation, I think it's fair to say it's approximately in compliance with the spec. :D

Is it good enough? Maybe.

(In reply to Chris Murphy from comment #1)

You're referring to the difference in shadow detail? It could be related to the "linear segment" or "toe" in a proper sRGB implementation. A proper sRGB implementation does not have a tone reproduction curve defined by a gamma 2.2 function. It's defined by "the sRGB curve". There are two common implementations and they both just get called sRGB.

Point 2, which says gamma 2.2 is an approximation, versus point 8.
http://www.color.org/srgb.pdf

Also for what it's worth, cameras don't use ICC profiles (I can't think of one anyway), but rather use EXIF to tag the JPEG with a single encoded value that translates into sRGB. Therefore it's up to the viewer to properly implement such a transformation. And whether Firefox's JPEG support honors EXIF is a valid question, because there's a value to define the source space as Adobe RGB (1998) which is defined with a gamma 2.2 function. And there's a way to define arbitrary spaces in later versions of EXIF.

The test images I used at https://www.nedmartin.org/v3/public/colour-management-test.html have sRGB profiles embedded by Photoshop. I'm not an expert, but I believe they are embedded ICC profiles, not tagged.

But there's more. A proper sRGB implementation is defined with a white luminance of 80 nits (candelas per meter squared) which is not very bright by today's display standards (they come out of the box at 300+). And then there's black luminance of 0.2 nits. Both include veiling glare, the effect of ambient light reflecting off the face of the display back to the viewer. And to get to such a low black level requires a ambient luminance level of 64 lux or less. Almost no one is doing that these days. And as sRGB is an output color space, an image rendered for sRGB really does expect to be viewed in such conditions, even to be approximate to the original scene. It was a difficult problem 20 or so years ago, and today it's even harder mainly because of lack of controlling the environment with mobile devices and laptops everywhere. I had to drop the office room lighting quite a bit to see the difference in shadow detail between the example images.

The issue here is that the same 4 images on my sample link above look different on the same monitor under identical viewing conditions. They should look the same as they are all the same image. Regardless of how you want to define or manage your colours and so forth, they should not look different to each other.

Obviously they should ideally look the same as the properly colour managed versions of each - i.e. what Photoshop, IrfanView, or any other properly colour managed application displays them as. From my testing, it appears that the versions which do have embedded (not tagged, but actually embedded) ICC colour profiles do colour manage correctly.

Chrome being different again is yet another issue, but not one you have any control over I suppose.

Or maybe there's something else going on entirely... which is why I've linked https://www.nedmartin.org/v3/public/colour-management-test.html so people with more experience than me can confirm that the images are in fact correct and don't have the wrong profiles embedded or something weird like that.

However, under no circumstances should they look different to each other.

Yes, this is something that will need to be fixed as part of relanding enabling color management everywhere. I've blocked it against the meta bug blocking those issues. I was mistaken things Chrome didn't color manage untagged images, due to some other bugs we were trying to work around (I must have misunderstood the code).

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(aosmond)

This has now hit release and is affecting users in bug 1643242 and:

https://reddit.com/r/firefox/comments/gvmw0h/firefox_77_update_broke_my_color_management/
https://reddit.com/r/firefox/comments/gvnx6l/770_color_management_no_longer_works/
https://reddit.com/r/firefox/comments/gwnjnt/color_management_still_broken_in_7701/
https://www.dpreview.com/forums/post/64006246

Since bug 1631615 was based on a wrong assumption, I assume the backport should be reverted for beta or maybe even release?
What's more important: windy.com or professionals with wide gamut monitors using gfx.color_management.mode;1, or is there a way to fix windy.com, while not regressing existing users' setups?

edit: I assume windy.com was incidentally fixed by bug 1639574 reverting the default gfx.color_management.mode to 2, so a revert of the bug 1631615 backport would only affect those that explicitly want full color management.

Keywords: regression
Regressed by: 1631615
Has Regression Range: --- → yes

This is a definite bug. Setting gfx.color_management.mode to 1 no longer works, and Firefox 77 (and 77.0.1) no longer colour-manages untagged images. The nature of the bug means that it is likely only to be seen on wide-gamut monitors.

See for example http://simongarrett.uk/TestColours.htm where the first row of colour blogs should look the same left and right. On a wide-gamut monitor, the left hand set contain profiles, the right hand set do not and are over-saturated in FF77+.

This makes Firefox unusable on a wide-gamut monitor.

(In reply to Simon Garrett from comment #17)

This is a definite bug. Setting gfx.color_management.mode to 1 no longer works, and Firefox 77 (and 77.0.1) no longer colour-manages untagged images. The nature of the bug means that it is likely only to be seen on wide-gamut monitors.

See for example http://simongarrett.uk/TestColours.htm where the first row of colour blogs should look the same left and right. On a wide-gamut monitor, the left hand set contain profiles, the right hand set do not and are over-saturated in FF77+.

This makes Firefox unusable on a wide-gamut monitor.

That's right. Google Photos for example is affected so for wide-gamut users Severity is S2.

I used mozregression-gui to identify the commit to introduce the regression.
Points to https://phabricator.services.mozilla.com/D73737

bug 1631615 - Don't color manage PNG/JPG/WebP if not tagged.
"It appears some websites assume we will not color manage untagged images and encode metadata in the image's surface data. Chrome matches this behaviour. We should probably do the same for webcompat."

I would prefer to have untagged images color manged when the setting is explicitly set.

This is not a question of personal preference, luckily. Untagged images (and other page elements) have to be colour-managed (assumed to be sRGB), when gfx.color_management.mode is set to 1, and have been for years. Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1631615 was a mistake and it “fixed” a problem introduced by making gfx.color_management.mode default to 1, if I understand correctly. If Firefox is unprepared to change the default, let it default back to (wrong) 2 for the duration of making it being prepared. But untagged images have to be colour managed, when set to 1, so this needs fixing.

"It appears some websites assume we will not color manage untagged images and encode metadata in the image's surface data. Chrome matches this behaviour. We should probably do the same for webcompat."

This is wrong AFAIK. Chrome correctly assumes untagged images to be sRGB (and without having to change any obscure settings; plus this). Also, if some websites would really make some silly assumptions, well, they would need to change their ways.

I believe W3C also specifies that browsers should assume untagged elements are sRGB and colour-manage accordingly, but I can't find the document where I found that before. In other words, the gfx.color_management.mode=1 behaviour should not only work but be the default. I would be a little surprised if "some websites assume we will not color manage untagged images", as this would be incorrect behaviour. It's bonkers anyway, as it means that the resulting colour is entirely unpredictable, depending on monitor colour space.

This is now being reverted in bug 1645042 (not sure why a separate bug had to be opened instead of using one of the half-dozen dupes or this one).

See Also: → 1645042

(In reply to Simon Garrett from comment #21)

I believe W3C also specifies that browsers should assume untagged elements are sRGB and colour-manage accordingly, but I can't find the document where I found that before. In other words, the gfx.color_management.mode=1 behaviour should not only work but be the default.

Here's the document: https://www.w3.org/TR/css-color-4/#untagged
So, yes, should apply mode=1 to map anything untagged to sRGB.

(In reply to Simon from comment #23)

(In reply to Simon Garrett from comment #21)

I believe W3C also specifies that browsers should assume untagged elements are sRGB and colour-manage accordingly, but I can't find the document where I found that before. In other words, the gfx.color_management.mode=1 behaviour should not only work but be the default.

Here's the document: https://www.w3.org/TR/css-color-4/#untagged
So, yes, should apply mode=1 to map anything untagged to sRGB.

Thanks!

I wrote a bit about the errors between the correct sRGB (and display-p3) TRC and the gamma 2.2 or 2.4 approximations:

https://svgees.us/Color/errors.html

The code for that is trivial, but anyway here it is

https://github.com/svgeesus/svgeesus.github.io/blob/master/Color/sRGB_TRC-errors.js

You need to log in before you can comment on or make changes to this bug.