Issue metadata
Sign in to add a comment
|
piman's g+ photo renders wrong on linux |
||||||||||||||||||||||
Issue descriptionVersion 56.0.2897.0 (current dev). Attached picture is a png where every color is #314159. When opening in chrome, grabbing a screenshot, and checking the color that is rendered, it became #3a4359. vmiura produced a jsbin that shows the problem (should not have seams, is correct in 54, but not in dev, or apparently beta on linux, but is correct on mac): https://output.jsbin.com/cotuxipiza/1 A bisect-builds pointed to https://chromium.googlesource.com/chromium/src/+log/203bbc711d1134ad2b5d0dc88bf656d3ceb83341..1714619ebb3e94c7bd1e4be123f1be3bd1c1424c , where the most likely suspect is https://chromium.googlesource.com/chromium/src/+/09d613c9521618057602b7fe451da352ad1051b5 "Support for retreiving the monitor color space on X11." Any thoughts?
,
Oct 27 2016
nvm comment 1, pebkac, still broken on tot
,
Oct 27 2016
Is this GPU Rasterization specific? Otherwise maybe tag as internals>GPU>image?
,
Oct 27 2016
,
Oct 27 2016
If your monitor ICC profile is not sRGB, then maybe this is actually correct?
,
Oct 27 2016
The PNG image is untagged, so it shouldn't be getting color corrected as I understand it.
,
Oct 27 2016
At least, http://regex.info/exif.cgi reports that the PNG has no color-space metadata and no embedded color profile. The expected behavior is that we don't color correct, and we match CSS color for images without embedded color profiles.
,
Oct 27 2016
Images with color profiles trigger color transform with ImageDecoder::setColorSpaceAndComputeTransform(). This can be set by PNGImageDecoder::headerAvailable(). On Mac I verified that this is never set for this PNG. Likely we are setting this on Linux due to a difference in libpng configuration, but I haven't yet verified.
,
Oct 27 2016
It looks correct on Chrome OS too (current dev, which is still 55.0.2883.17 on samus, i.e. like beta on desktop). So maybe there is a desktop-linux-specific thing somewhere, that got triggered by hubbe's patch?
,
Oct 27 2016
Not color-correcting untagged images is something we're probably going to have to change at some point. Once we start seeing HDR and/or BT2020 displays, not adjusting colors is going to look very bad. That doesn't change the fact that it is currently unexpected though.
,
Oct 27 2016
^ yes, we're going to start color correcting them soon, along with CSS element colors. The expectation is those match.
,
Oct 27 2016
#9: I think hubbe@'s patch just enabled color correction on Linux for tagged images which is fine. The bug seems in how we're handling PNG headers on Linux, treating the image having a color profile.
,
Oct 28 2016
The PNG has an sRGB chunk, which is like an implied sRGB profile, so it's working correctly. (Now, before the patch it didn't on Linux.)
,
Oct 28 2016
Why isn't this true on Mac and Chrome OS as well, then?
,
Oct 28 2016
It is true. If you use the same screen for all OSes, your Linux profile may be incorrect. If not, your other screens are probably very close to sRGB, so the difference isn't noticeable. Also, ChromeOS has system-wide color management, which I'm not sure what its effect is in this case. (I have no device.) http://crbug.com/495196
,
Oct 28 2016
^ I think this is right; it's working correctly now. When I checked on Mac earlier it seemed to me we weren't doing color correction on this PNG as the image color didn't change when I modified the Display's Color Profile settings, even when re-starting Chrome. It does look like we're detecting sRGB profile and marking the image for color correction on Mac too. Closing, works as expected. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by piman@chromium.org
, Oct 27 2016