1284225 - Firefox saturating images

Status: REOPENED

(Core :: Graphics: Color Management, defect, P3)

Description

[Ruturaj Vartak]

Attachment: firefox-nightly-guardian.png

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36
Build ID: 20160606113944

Steps to reproduce:

1. Navigate to https://www.theguardian.com/football/2016/jul/03/france-iceland-euro-2016-quarter-final-match-report in Firefox Nightly private browsing
2. take screenshot
3. Open same URL in google-chrome in incognito
4. take a screenshot
5. Compare screenshots



Actual results:

Compare colors of the rendered pages, Firefox's screenshot seems to be having higher saturation of colors than Google Chrome's


Expected results:

Both the screenshots should've had equal saturation of colors. Google's color is better as France's football jersey color is correctly rendered.

Comment 1

[Ruturaj Vartak]

Attachment: Chrome color rendering

Chrome's color rendering seems "true" than firefox's !

Comment 2

[Ruturaj Vartak]

This is my system configuration

Laptop: Lenovo ThinkPad X201
OS: Ubuntu 16.04 LTS GNOME (x86_64)
Firefox: Nightly compiled from source
Google Chrome:51.0.2704.106-1

Comment 3

[Loic]

Does it work with the official Linux version from Mozilla?
https://www.mozilla.org/en-US/firefox/all/

In addition, could you type about:support in the location bar and copy here the "graphics" section.

Comment 4

[Ruturaj Vartak]

No, Doesn't happen for the Fx official release (new profile)

Here is the about:support "graphics"  (This is common for Fx official version existing profile vs. new profile)
=============================================
Adapter Description	Intel Open Source Technology Center -- Mesa DRI Intel(R) Ironlake Mobile
Asynchronous Pan/Zoom	none
Device ID	Mesa DRI Intel(R) Ironlake Mobile
Driver Version	2.1 Mesa 11.2.0
GPU Accelerated Windows	0/1 Basic (OMTC)
Supports Hardware H264 Decoding	No
Vendor ID	Intel Open Source Technology Center
WebGL Renderer	Intel Open Source Technology Center -- Mesa DRI Intel(R) Ironlake Mobile
windowLayerManagerRemote	true
AzureCanvasAccelerated	0
AzureCanvasBackend	cairo
AzureContentBackend	cairo
AzureFallbackCanvasBackend	none
CairoUseXRender	0
=============================================

This is about:support # graphics for the nightly
=============================================
Features
Compositing	Basic
Asynchronous Pan/Zoom	wheel input enabled; touch input enabled
WebGL Renderer	Intel Open Source Technology Center -- Mesa DRI Intel(R) Ironlake Mobile
Hardware H264 Decoding	No
GPU #1
Active	Yes
Description	Intel Open Source Technology Center -- Mesa DRI Intel(R) Ironlake Mobile
Vendor ID	Intel Open Source Technology Center
Device ID	Mesa DRI Intel(R) Ironlake Mobile
Driver Version	2.1 Mesa 11.2.0
Diagnostics
AzureCanvasAccelerated	0
AzureCanvasBackend	skia
AzureContentBackend	cairo
AzureFallbackCanvasBackend	none
CairoUseXRender	0
Decision Log
HW_COMPOSITING	
blocked by default: Acceleration blocked by platform
=============================================

Do you think an older Fx config (which I might be carrying since 2yrs+) is causing the issue ? or any addons ?

However for the nightly build doesn't have anything.

Comment 5

[Loic]

With your current profile, you can test in safe modeto know if add-ons are faulty:
https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

Safe mode disables HWA too, so you can just test in normal mode with only HWA disabled:
https://support.mozilla.org/en-US/kb/forum-response-disable-hardware-acceleration (restart FF to apply)

Comment 6

[Ruturaj Vartak]

Unfortunately, now I'm unable to replicate the issue even in the older profile. I don't know what changed. But the colors are coming up fine now.!

Comment 7

[Tim Nguyen :ntim]

Someone reported the same issue here: https://www.reddit.com/r/firefox/comments/4wpqbu/colors_in_firefox_49_dev_edition_heavily/

It seemed related to a pref.

Comment 8

[Milan Sreckovic [:milan] (needinfo for best results)]

Any of gfx.color_management* preferences set to a non-default value could be the cause.  We've also seen cases where the path to the color profile wasn't set correctly, and things were coming up wrong.
Not sure this bug is actionable, but bug 1292885 may be related, and may be actionable.