New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 651688 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 44872
Owner:
Last visit > 30 days ago
Closed: Oct 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Chrome misinterprets images without an embedded color profile

Reported by maestrom...@gmail.com, Sep 30 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36

Example URL:
http://cameratico.com/tools/web-browser-color-management-test/

Steps to reproduce the problem:
1. View an sRGB image without an embedded color profile
2. Compare to same image with an sRGB color profile
3. Colors differ.

What is the expected behavior?
Without a profile, Chrome should assume sRGB, so colors should be the same.

What went wrong?
Colors differ when the image is missing a profile. See the section "How does your browser interpret untagged images and page elements?" on http://cameratico.com/tools/web-browser-color-management-test/

Or see http://www.color-management-guide.com/web-browser-color-management.html#attitude

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? N/A 

Does this work in other browsers? Yes 

Chrome version: 53.0.2785.143  Channel: stable
OS Version: 10.0
Flash Version: Shockwave Flash 23.0 r0

Verified that the problem does not occur in Microsoft Edge on the same computer.
 
Cc: noel@chromium.org ccameron@chromium.org
Components: -Blink Internals>Images>Codecs
Cc: msarett@chromium.org
Note that this problem does not occur on 52.0.2743.116 (64-bit) on Linux.
Owner: msarett@chromium.org
Status: Assigned (was: Unconfirmed)
I agree that we behave very strangely in this situation.

On Mac/Win platforms, the image decoders will correct any image with an ICC profile to the monitor space.  Any untagged image will be left alone (rather than treated as sRGB).

The problem does not reproduce on Linux because we do read the monitor space on Linux - we just guess that it is sRGB.  The tagged image will undergo a sRGB->sRGB conversion (which I think QCMS will actually still do math for).  But it should be (at least roughly) the same as leaving the bytes alone.
We currently have the behavior that:
1. CSS colors are not transformed
2. Un-tagged images are not transformed
3. Tagged images are transformed.

As a consequence, colors in un-tagged images match CSS colors.

We plan to update [1] and [2] to be transformed, but this will take some care to be done accurately, and they need to be updated atomically (otherwise the one way that authors can match CSS colors will be broken).

Comment 6 by pdk...@gmail.com, Oct 28 2016

> The problem does not reproduce on Linux because we do read the monitor space on Linux - we just guess that it is sRGB.

I think you left out a NOT here. And it's fixed on Linux too now.

https://chromium.googlesource.com/chromium/src/+/b0df9e3fcbca19d2a625fa274172bd3be4116261
Mergedinto: 44872
Status: Duplicate (was: Assigned)

Sign in to add a comment