Closed Bug 1799391 Opened 1 year ago Closed 1 year ago

Regression: Colour management no longer working

Categories

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

Firefox 107
defect

Tracking

()

VERIFIED FIXED
109 Branch
Tracking Status
firefox-esr102 --- unaffected
firefox107 --- verified
firefox108 --- verified
firefox109 --- verified

People

(Reporter: colinlee10, Assigned: jrmuizel)

References

(Regression)

Details

(Keywords: regression)

Attachments

(3 files)

Attached image colorman.png

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

Steps to reproduce:

  1. Build Firefox from nightly or beta. I used 107.0b10 (64-bit)
  2. Apply attached ICC profile in Windows colour management
  3. Try a color management test after restarting the browser (e.g by using https://cameratico.com/tools/web-browser-color-management-test/, or just comparing to earlier Firefox version with gfx.color_management.mode = 1)

This ICC profile was exported by DisplayCal with standard settings after monitor profiling.

I believe this is the regression point. Reverting this change restores colour management:
https://bugzilla.mozilla.org/show_bug.cgi?id=1795045

See attached screenshots from https://cameratico.com/tools/web-browser-color-management-test/ for comparison between browsers.

Actual results:

Colour management is not visible - images appear oversaturated on wide gamut monitor. Tagged images do not have changed colors

Expected results:

Output images should have colour management applied.

The Bugbug bot thinks this bug should belong to the 'Core::Graphics: Color Management' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Graphics: Color Management
Product: Firefox → Core
Regressed by: 1795045

:jrmuizel, since you are the author of the regressor, bug 1795045, could you take a look? Also, could you set the severity field?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jmuizelaar)
Keywords: regression
Severity: -- → S2
Priority: -- → P2
Assignee: nobody → jmuizelaar

It seems like Chrome allows this and it's relatively common.
We don't have a good reason to continue blocking these profiles.

Attachment #9303350 - Attachment description: Bug 1799391. Allow negative XYZ on non-macOS → Bug 1799391. Allow negative XYZ on non-macOS.
Pushed by jmuizelaar@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a635a87e5896
Allow negative XYZ on non-macOS. r=aosmond
Status: UNCONFIRMED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 109 Branch

Thanks. Verified fix on my end

Set release status flags based on info from the regressing bug 1795045

See Also: → 1792469

I assume you're going to want this in a dot release, so go ahead and nominate for Beta & Release approval when you get a chance. It grafts cleanly.

colinlee10, did you have gfx.color_management.enablev4 set to true?

Flags: needinfo?(colinlee10)

Yes

Flags: needinfo?(colinlee10)

Comment on attachment 9303350 [details]
Bug 1799391. Allow negative XYZ on non-macOS.

Beta/Release Uplift Approval Request

  • User impact if declined: Color management will not work for some people with negative XYZ in their profiles
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): We've been shipping this change on macOS for many year.
  • String changes made/needed:
  • Is Android affected?: Yes
Flags: needinfo?(jmuizelaar)
Attachment #9303350 - Flags: approval-mozilla-beta?

Comment on attachment 9303350 [details]
Bug 1799391. Allow negative XYZ on non-macOS.

Approved for 108.0b4

Attachment #9303350 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

:jrmuizel could you add a release uplift request on this when ready?
Would like to consider including this in the planned dot release

Flags: needinfo?(jmuizelaar)
Flags: qe-verify+

Comment on attachment 9303350 [details]
Bug 1799391. Allow negative XYZ on non-macOS.

Beta/Release Uplift Approval Request

  • User impact if declined: Users that have set gfx.color_management.enablev4=true may get broken color management on Windows and Linux
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): This will cause us to accept profiles that we previously rejected. As far as we know that's ok.
  • String changes made/needed:
  • Is Android affected?: Yes
Flags: needinfo?(jmuizelaar)
Attachment #9303350 - Flags: approval-mozilla-release?

https://www.reddit.com/r/firefox/comments/z1t28j/color_management_not_working_after_microsoft/ sounds like it might be another user running into this issue in 107.

Reproduced the bug as observed in screenshot from description, on Beta 108.0b2 on Windows 10. Also, on affected build, there are no changes on colors when set gfx.color_management.mode = 1 (default is 2).

I can confirm that bug is fixed on Beta 108.0b5 and latest Nightly build ID 20221122094606, on Windows 10 and Ubuntu 18.04 x64

QA Whiteboard: [qa-triaged]

Comment on attachment 9303350 [details]
Bug 1799391. Allow negative XYZ on non-macOS.

Approved for 107.0.1

Attachment #9303350 - Flags: approval-mozilla-release? → approval-mozilla-release+

Verified as fixed on RC 107.0.1 on Windows 10 and Ubuntu 18.04 x64.

Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-triaged]
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: