Note: There are a few cases of duplicates in user autocompletion which are being worked on.

qcms doesn't support ICC version 4

REOPENED
Unassigned

Status

()

Core
GFX: Color Management
REOPENED
8 years ago
4 months ago

People

(Reporter: Alice0775 White, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 1 bug, {regression, student-project})

1.9.2 Branch
regression, student-project
Points:
---
Dependency tree / graph
Bug Flags:
wanted1.9.2 ?
in-testsuite ?

Firefox Tracking Flags

(blocking2.0 -, status2.0 wanted)

Details

(Whiteboard: [parity-IE9][parity-Opera12][gfx-noted], URL)

Attachments

(13 attachments)

3.94 KB, application/octet-stream
Details
78.29 KB, application/octet-stream
Details
84.63 KB, application/octet-stream
Details
3.86 KB, application/octet-stream
Details
3.96 KB, application/octet-stream
Details
100.37 KB, application/octet-stream
Details
656.51 KB, application/octet-stream
Details
27.80 KB, application/octet-stream
Details
242.88 KB, application/octet-stream
Details
772 bytes, patch
bholley
: review+
Details | Diff | Splinter Review
2.98 KB, application/octet-stream
Details
3.83 KB, application/octet-stream
Details
700 bytes, application/octet-stream
Details
(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090416 Firefox/3.5.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090416 Shiretoko/3.5b4pre ID:20090416044319

ICC version 4 doesn't work on Windows

Reproducible: Always

Steps to Reproduce:
1.Visit URL
2.
3.
Actual Results:  
The system supports ICC version 2 profiles only 

Expected Results:  
The system supports these ICC version 4 and version 2 profiles 


Regression of Bug 481926 - Rewrite color management component

Related  bugs:
Bug 488468 -  qcms build break with pre-4 GCCs  
 Bug 488468 -  qcms build break with pre-4 GCCs
(Reporter)

Updated

8 years ago
Blocks: 481926
Severity: major → normal
Keywords: regression
Version: unspecified → 3.1 Branch

Comment 1

8 years ago
Fails on Mac as well
Status: UNCONFIRMED → NEW
Component: General → GFX: Color Management
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → color-management
Version: 3.1 Branch → Trunk
I'm pretty sure that qcms only supports v2. Jeff, can you confirm this?
Yes, qcms currently only supports v2.

Comment 4

8 years ago
I wonder why is that? v4 worked fine in 3.0
(In reply to comment #4)
> I wonder why is that? v4 worked fine in 3.0

3.0 used lcms. We've switched to qcms for maintenance and security reasons.

Comment 6

8 years ago
It's not only on Windows. It also doesn't work on my MacBook (OSX 10.5.7).

Tested with this build:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090520 Minefield/3.6a1pre

I checked the image from color.org and I get a ICC v2 only image.
OS: Windows XP → All
Hardware: x86 → All
Summary: qcms ICC version 4 doesn't work on Windows → qcms doesn't support ICC version 4

Comment 7

8 years ago
So who was the brain child who thought it would be a good idea to switch without bothering to check if ICC V4 is supported.
(In reply to comment #7)
> So who was the brain child who thought it would be a good idea to switch
> without bothering to check if ICC V4 is supported.

We intentionally limited the scope of qcms to not include support for icc v4 to ensure that qcms would be ready for 3.5.
Flags: in-litmus?
Keywords: student-project

Comment 9

8 years ago
This is disgraceful. When the casual user views my images on the Net they'll now see something that looks totally wrong. And who'll they blame? Me when they should be blaming Mozilla!!!

Fix this ASAP.

Comment 10

8 years ago
This has taken the shine off the launch of Firefox 3.5 for me. Browsing images is such a variable experience with some looking better and some looking much worse. I'll be using a different browser until this is fixed. I hope it happens soon.

Comment 11

8 years ago
Without pointing any fingers, could I please ask anyone who wants to add additional comments to this bug along the lines of comments 7, 9 and 10, to please first read: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html . If this bug is important to you, you can vote for it, without adding yet more comments. Thank you.

Comment 12

8 years ago
This is horrible, horrible bug. I can't really design enything for FF now as it produces oversaturated, contrasted and dark images/colours. I'm running on Sypder calibrated Dell monitor and this is simply a no-go. Take a look: https://files.getdropbox.com/u/27213/qlory.jpg
criography - how does this relate to the lack of ICC4 support? I'm reasonably sure that not all of those other browser support ICC4 either, so the fact that firefox doesn't perform color management on ICC4-tagged profiles shouldn't be your issue here. Maybe you're talking about bug 497363?
Can those of you with ICCv4 profiles attach them to the bug. That will help us get an idea of what kinds of things will need to be done to support those profiles.
I can provide a Matrix and a LUT profile made by a LaCie Blue Eye Pro for the Acer P243W monitor. (both v4) Should I bundle them or attach them separately? (if bundled, what compression format should I use?)
(In reply to comment #15)
> I can provide a Matrix and a LUT profile made by a LaCie Blue Eye Pro for the
> Acer P243W monitor. (both v4) Should I bundle them or attach them separately?
> (if bundled, what compression format should I use?)

attaching them separately is fine.
Created attachment 386376 [details]
v4 Matrix profile for Acer P243W by LaCie Blue Eye Pro
Created attachment 386377 [details]
v4 LUT profile for Acer P243W by LaCie Blue Eye Pro

Updated

8 years ago
Duplicate of this bug: 501917

Comment 20

8 years ago
Created attachment 386811 [details]
Nec LCD2690WUXI ICC profile

Comment 21

8 years ago
I also added my monitor profile, in case it can be helpful to the developers.

Comment 22

8 years ago
Created attachment 386818 [details]
Color profile for HP LP2475w wide gamut monitor created with Huey Pro calibrator

Comment 23

8 years ago
Color profile for HP 2475w wide gamut made by TFTCentral using LaCie Blue Eye Pro.

Comment 24

8 years ago
Created attachment 386948 [details]
color profile for HP 2475w made by TFTCentral

Comment 25

8 years ago
Created attachment 389102 [details]
Philips 240PW9ES ICC profile

Supplied by Philips, taken from the driver disc.

Comment 26

8 years ago
Created attachment 389269 [details]
v4 LUT for Dell 2408WFP by Eye-One Match 3 using Eye-One Display 2

v4 LUT for Dell 2408WFP by Eye-One Match 3 using Eye-One Display 2

Comment 27

8 years ago
Created attachment 389285 [details]
Profile for HP LP2475w from Spyder2

Profile for HP LP2475w from Spyder2

Comment 28

8 years ago
I think it a mistake to remove v4 support, especially without telling anyone.  This has caused considerable grief in the user community, especially among those not computer literate for whom colour management is a bit of a mystery at the best of times.  I really think Mozilla should avoid doing anything like this again.  If any features absolutely must be removed, there should be big easy-to-understand warnings when you try to upgrade.

Comment 29

8 years ago
Sorry, the profile I submitted for the HP LP2475w from a Spyder2 was v2.4 - not v4 as I thought.

Comment 30

8 years ago
Created attachment 389556 [details]
ICC v4 profile for MacBook Pro 15" (Summer 07)

Updated

8 years ago
Flags: wanted1.9.2?

Comment 31

8 years ago
Here is the official color.org web page to test version 2 and version 4 support in web browsers.

http://www.color.org/version4html.xalter

This has source ICC profiles in both version 2 and version 4.

I want to add that the "security issues" in LCMS that prompted this change were bogus since they were virtually impossible to exploit and were fixed with in days of being reported.  Almost every open source system has LCMS installed and this library is used by dozens of applications and at no point did anyone ever have anyone exploit the reported issues.
I've put a build up here with the version check disabled. It would be interesting to hear how this works for those of you with ICCv4 profiles.
And the url is:

https://build.mozilla.org/tryserver-builds/jmuizelaar@mozilla.com-1248732712/

Comment 34

8 years ago
I've tested the new build, and although it does not support ICCv4 profiles, I don't get over-saturated colours anymore. They look as good as the nightly build from April I was using until now.

Comment 35

8 years ago
Same here. The new build is still ICCv2 only according to the color.org test mentioned earlier. This can easily be tested by anyone, just grab the ICCv4 profile provided here: http://www.color.org/srgbprofiles.xalter - the green area in the upper right corner is a dead giveaway to test for compliance.

That test uses some more exotic profiles then (I guess) you'd normally encounter on the web. This build certainly did things a bit better, color tagged pictures such as http://blog.lib.umn.edu/carls064/freealonzo/bsg4.jpg (sRGB) aren't as oversaturated as they are in Fx 3.5. It's not exactly the same as in Photoshop though. The surfing picture from bug 497363 seems the same though, according to Photoshop it's in Adobe RGB. 

Browsing the web with gfx.color_management.mode set to 1 is also improved in the same way at a first glance. Somebody should do some direct comparisons with the latest version of Firefox 3 that still has LCMS for more definitive comparisons though.
Here's a comparison shot I made on my laptop - which has no means to adjust its monitor's settings, so the difference between calibrated and default is very noticeable. I compared the 2009-04-13 nightly (just before QCMS landed) on the left, to the tryserver build in the centre, to the latest nightly on the right. gfx.color_management.mode is set to 1 so you can see the effect on the GUI as well. I suggest you download the image and view it in a program like photoshop for obvious reasons.

http://img188.imageshack.us/img188/8217/colormanagementtest.png
Created attachment 391953 [details] [diff] [review]
Accept version 4 profiles
Attachment #391953 - Flags: review?(bobbyholley)
Jeff - I'm confused about 2 things:

1) What we support by disabling this version check that we didn't support before
2) Why increasing our matrix of accepted profiles fixes over-saturation problems
Duplicate of this bug: 508322
(In reply to comment #38)
> Jeff - I'm confused about 2 things:
> 
> 1) What we support by disabling this version check that we didn't support
> before

Profiles that we can treat as version 2 profiles but are marked as version 4

> 2) Why increasing our matrix of accepted profiles fixes over-saturation
> problems

I'm not sure about this one... I'll look into it.

Comment 41

8 years ago
Just add support to all the stuff described at this page (also the answer to question 2):
http://www.color.org/version4html.xalter

Comment 42

8 years ago
But, to be honest, IE is worse when it comes to this, and the bug where ICC4 pictures where treated as ICC2 pictures seems to be fixed.

Comment 43

8 years ago
(In reply to comment #13)
> criography - how does this relate to the lack of ICC4 support? I'm reasonably
> sure that not all of those other browser support ICC4 either, so the fact that
> firefox doesn't perform color management on ICC4-tagged profiles shouldn't be
> your issue here. Maybe you're talking about bug 497363?

Safari does ICC4, no other browser other than Firefox before this version supports ICC4. Neither Opera or IE supports no colour management.
Until fixed I will be switching to Safari.
(In reply to comment #40)
> (In reply to comment #38)
> > 2) Why increasing our matrix of accepted profiles fixes over-saturation
> > problems
> 
> I'm not sure about this one... I'll look into it.

Ping me when you figure it out? I'd rather know what's going on before reviewing. If you really need it now let me know.

Comment 45

8 years ago
(In reply to comment #38)
> Jeff - I'm confused about 2 things:
> 1) What we support by disabling this version check that we didn't support
> before
> 2) Why increasing our matrix of accepted profiles fixes over-saturation
> problems


Comment #41 From ruben.nesvadba@gmail.com 2009-08-11 09:46:38 PDT (-) [reply] ------- Just add support to all the stuff described at this page (also the answer to
question 2):
http://www.color.org/version4html.xalter
------- Comment #42 From ruben.nesvadba@gmail.com 2009-08-11 10:11:34 PDT (-) [reply] ------- But, to be honest, IE is worse when it comes to this, and the bug where ICC4
pictures where treated as ICC2 pictures seems to be fixed.

Comment 46

8 years ago
(In reply to comment #40)
> (In reply to comment #38)
> > Jeff - I'm confused about 2 things:
> > 
> > 1) What we support by disabling this version check that we didn't support
> > before
> Profiles that we can treat as version 2 profiles but are marked as version 4
> > 2) Why increasing our matrix of accepted profiles fixes over-saturation
> > problems
> I'm not sure about this one... I'll look into it.



Comment #41 From ruben.nesvadba@gmail.com 2009-08-11 09:46:38 PDT (-) [reply] ------- Just add support to all the stuff described at this page (also the answer to
question 2):
http://www.color.org/version4html.xalter
------- Comment #42 From ruben.nesvadba@gmail.com 2009-08-11 10:11:34 PDT (-) [reply] ------- But, to be honest, IE is worse when it comes to this, and the bug where ICC4
pictures where treated as ICC2 pictures seems to be fixed.
Created attachment 396595 [details]
srgb v2 profile

Can those who are experiencing the over-saturation problem try setting this srgb profile as their display profile and see if they still have over-saturated images?

Comment 48

8 years ago
tried it, didn't help: (sRGB.icm and the attached one)
problematic e.g.:
http://www.spiluttini.com/nextroom.php?id=2633
(In reply to comment #44)
> (In reply to comment #40)
> > (In reply to comment #38)
> > > 2) Why increasing our matrix of accepted profiles fixes over-saturation
> > > problems
> > 
> > I'm not sure about this one... I'll look into it.
> 
> Ping me when you figure it out? I'd rather know what's going on before
> reviewing. If you really need it now let me know.

Bobby, it sounds like the oversaturation just comes from using the sRGB profile when we can't use the display profile. I wonder if we should perhaps disable color management in that case instead of defaulting to sRGB.
(In reply to comment #48)
> tried it, didn't help: (sRGB.icm and the attached one)
> problematic e.g.:
> http://www.spiluttini.com/nextroom.php?id=2633

The problem on this site is unrelated to this bug. Do you see the oversaturation people that other people were reporting when using a iccv4 display profile?

(In reply to comment #48)
> tried it, didn't help: (sRGB.icm and the attached one)
> problematic e.g.:
> http://www.spiluttini.com/nextroom.php?id=2633

I've filed bug 515958 for this issue.
(In reply to comment #49)
> (In reply to comment #44)
> > (In reply to comment #40)
> > > (In reply to comment #38)
> > > > 2) Why increasing our matrix of accepted profiles fixes over-saturation
> > > > problems
> > > 
> > > I'm not sure about this one... I'll look into it.
> > 
> > Ping me when you figure it out? I'd rather know what's going on before
> > reviewing. If you really need it now let me know.
> 
> Bobby, it sounds like the oversaturation just comes from using the sRGB profile
> when we can't use the display profile. I wonder if we should perhaps disable
> color management in that case instead of defaulting to sRGB.

Perhaps the report from ks@nextroom.at didn't match what I was looking for, so we can wait to see if anyone else has a report when using the attached sRGB profile.
Bobby, I can't really come up with a better answer for the over-saturation problem (perhaps some misreporting?). Regardless, accepting the parts of ICCv4 profiles that we understand seems like it will be better then ignoring them altogether. So r+ please :)?
Comment on attachment 391953 [details] [diff] [review]
Accept version 4 profiles

sure thing. r=bholley
Attachment #391953 - Flags: review?(bobbyholley) → review+
Pushed:
http://hg.mozilla.org/mozilla-central/rev/3b4b64b6ae23
Attachment #391953 - Flags: approval1.9.2?
Comment on attachment 391953 [details] [diff] [review]
Accept version 4 profiles

approval1.9.2 requests aren't currently being monitored, since we're nearing RC freeze and there are too many outstanding requests, so I'm clearing this request. Feel free to re-request approval if you are confident that it's worth drivers' time to consider whether this non-blocker needs to land for 1.9.2 at this stage.
Attachment #391953 - Flags: approval1.9.2?

Updated

8 years ago
Flags: in-testsuite?
Flags: blocking1.9.2?

Comment 57

8 years ago
This really isn't a bug anymore, but it is a very serious feature request:

http://www.color.org/version4html.xalter
Flags: blocking1.9.2?

Comment 58

8 years ago
(In reply to comment #56)
> (From update of attachment 391953 [details] [diff] [review])
> approval1.9.2 requests aren't currently being monitored, since we're nearing RC
> freeze and there are too many outstanding requests, so I'm clearing this
> request. Feel free to re-request approval if you are confident that it's worth
> drivers' time to consider whether this non-blocker needs to land for 1.9.2 at
> this stage.




A lot of people want this feature (just search on google). So it would be nice if it was added for the version after gecko 1.9.2

Updated

8 years ago
Flags: in-testsuite?
Flags: in-testsuite-
Flags: in-litmus?
Flags: in-litmus-

Comment 59

8 years ago
The feature being: support for IIC V4 color profiles / passing the test on:

http://www.color.org/version4html.xalter

Comment 60

8 years ago
*ICC

Comment 61

8 years ago
Mozilla Firefox used to pass this test, but now it's just as bad as Microsoft Internet Explorer is.

Comment 62

8 years ago
Thumbs up for the bug fixing on the color profile stuff so far though.
Flags: in-testsuite?
Flags: in-testsuite-
Flags: in-litmus-
Comment on attachment 391953 [details] [diff] [review]
Accept version 4 profiles

Requesting approval1.9.2.1 on this small patch for a regression from Firefox 3.5 and previous versions.

Since ICCv4 profiles are a superset of ICCv2, this patch just makes it so we accept them and
treat them the same way we do ICCv2 profiles.
Attachment #391953 - Flags: approval1.9.2.1?
(In reply to comment #63)
> (From update of attachment 391953 [details] [diff] [review])
> Requesting approval1.9.2.1 on this small patch for a regression from Firefox
> 3.5 and previous versions.

Er, make that Firefox 3.0 and previous versions. Forgot qcms was backported to at least 3.5, so this is a regression on 3.5, too.
Attachment #391953 - Flags: approval1.9.1.8?

Comment 65

8 years ago
(In reply to comment #63)
> (From update of attachment 391953 [details] [diff] [review])
> Requesting approval1.9.2.1 on this small patch for a regression from Firefox
> 3.5 and previous versions.
> Since ICCv4 profiles are a superset of ICCv2, this patch just makes it so we
> accept them and
> treat them the same way we do ICCv2 profiles.

Wouldn't treating them as ICC v2 recreate the color problems from the beginning of this whole ordeal?

Comment 66

8 years ago
Anyway, I belief people are talking about more than one subject on this bug-page.

Comment 67

8 years ago
(In reply to comment #63)
> (From update of attachment 391953 [details] [diff] [review])
> Requesting approval1.9.2.1 on this small patch for a regression from Firefox
> 3.5 and previous versions.
> Since ICCv4 profiles are a superset of ICCv2, this patch just makes it so we
> accept them and
> treat them the same way we do ICCv2 profiles.

By the way, this page claims that ICC v4 is NOT JUST (a.k.a. your average one) a superset of ICC v2:

http://www.naturescapes.net/docs/index.php/category-technical/44-technical/379-phil-wigglesworth

==>

"Note however that this is only an issue if you embed an ICCv4 profile WHICH IS NOT a simple superset of an ICCv2 profile into a web page."

Comment 68

8 years ago
This is a document telling all the technical differences, which some others should be able to understand a lot better than I do, allthough it indeed doesn't seem like a NORMAL superset:

http://www.color.org/ICC_White_Paper_26_Using_the_V4_sRGB_ICC_profile.pdf

Comment 69

8 years ago
I think ruben.nesvadba is a bit off about the patch currently attached to this bug.  To be clear, here is a quick summary of what happened in this bug:
 - People complained about images being oversaturated; this was a regression from 3.0 behavior
 - It was determined that this was somehow related to qcms not supporting ICCv4 profiles.  More specifically, if an ICCv4 profile is set as the display profile, qcms will somehow cause the colors to be rendered noticeably overly-saturated.
 - Jeff Muizelaar came up with this patch, which accepts ICCv4 profiles as ICCv2 profiles (see comments 32-36).  For reasons he couldn't figure out, this fixes the oversaturation with ICCv4 display profiles (comment #s 38, 40, 44, 49, 53).

 - #36 contains a side-by-side screenshot which clearly shows the beneficial effect of this patch:  http://img188.imageshack.us/img188/8217/colormanagementtest.png  (The sky should be blue, not purple).  I never saw it discussed why the left-most image is also oversaturated.

 - This patch _does not_ add proper support for ICCv4 images, and as such, will not fix http://www.color.org/version4html.xalter
 - According to other CM-related bugs I've looked through, Dell _may_ distribute ICCv4 profiles on the driver CD for their monitors (I wasn't able to find a clear consensus on this, so consider with a grain of salt).  If true, that would mean that this problem would affect many Dell monitor owners.

Comment 70

8 years ago
(In reply to comment #69)
> I think ruben.nesvadba is a bit off about the patch currently attached to this
> bug.  To be clear, here is a quick summary of what happened in this bug:
>  - People complained about images being oversaturated; this was a regression
> from 3.0 behavior

No this is NOT what happened.  This bug report is that FF v 3.5 no longer supported ICC V4 profiles and that this was a regression since earlier versions did support V4 profiles.  Over saturated was not mentioned until comment #12 and IMO was a not the real issue for which the bug was opened but it somehow became the focus of some posters even though it was a side issue.

>  - It was determined that this was somehow related to qcms not supporting ICCv4
> profiles.  More specifically, if an ICCv4 profile is set as the display
> profile, qcms will somehow cause the colors to be rendered noticeably
> overly-saturated.

The lack of V4 support was determined by the person who opened the bug and that determination had nothing to do with the saturation issue.  See comment #1.  In addition I can't find any comments to this bug that come to the conclusion that the over saturation issue was related to the lack of support for V4 profiles.  In fact all comments about the saturation issue say that the author of the comment has no idea why it is happening.

>  - Jeff Muizelaar came up with this patch, which accepts ICCv4 profiles as
> ICCv2 profiles (see comments 32-36).  For reasons he couldn't figure out, this
> fixes the oversaturation with ICCv4 display profiles (comment #s 38, 40, 44,
> 49, 53).

Again reviewing these comments does not support your statement.  In fact all of these (comment #s 38, 40, 44, 49, 53) are more an indication that no one seems to know what is going on with the over saturation issue.  I would contend that the over saturation issue is unrelated to the initial bug report which was specifically about qcms not supporting ICC V4 profiles.
 
>  - #36 contains a side-by-side screenshot which clearly shows the beneficial
> effect of this patch: 
> http://img188.imageshack.us/img188/8217/colormanagementtest.png  (The sky
> should be blue, not purple).  I never saw it discussed why the left-most image
> is also oversaturated.

The author of #36 makes no claims about the saturation level of the images or which one he thinks is correct.  All the above images show is that qcms is broken and that FF before the implementation of qcms (when it used lcms) was working.  LCMS is the current open source gold standard for color management and any significant variation from how it works is a clear indication that those variations are bugs that need to be fixed.

>  - This patch _does not_ add proper support for ICCv4 images, and as such, will
> not fix http://www.color.org/version4html.xalter
>  - According to other CM-related bugs I've looked through, Dell _may_
> distribute ICCv4 profiles on the driver CD for their monitors (I wasn't able to
> find a clear consensus on this, so consider with a grain of salt).  If true,
> that would mean that this problem would affect many Dell monitor owners.

It does not matter what Dell does since what they are doing is only one possible source of V4 profiles.  Many profiling packages now produce V4 profiles and many images are now tagged with V4 profiles.  V4 profiles are still less common than V2 profiles but there are a significant number of V4 profiles out in the wild and any "color managed" app that does not support them is broken and needs to be fixed.

On *nix system the existing profiling tools only produce V2 profiles.  So *nix users will almost always have only V2 monitor profiles installed.  But this bug still affects them because some images on the web have V4 profiles and qcms does not handle this correctly.

The way to test if this bug is fixed is to test with http://www.color.org/version4html.xalter.  If that web page is working correctly and matches with how this was reproduced with earlier versions of FF that used LCMS then the bug is fixed.

Comment 71

8 years ago
The over saturation is a complete red herring. The bug that means Firefox is no longer colour managed (as it claims) because it no longer supports icc v4 profiles remains.
All calibration devices now generate v 4 profiles, usually be default and many users do not even realise that this causes problems with Firefox. The icc v4 sRGB profile allows a much better gamut than the existing v2 profile and is gaining converts. Presently only Safari colour manages correctly, Firefox doesn't and without v 4 support to claim (as Mozilla does) that Firefox is colour managed is misleading.
This bug was raised a considerable time ago, it has not been fixed and this means that Firefox is not to be recommended as a browser to any one who cares about colour.

Comment 72

8 years ago
Maybe I misunderstood the purpose of "wanted1.9.2?" and such.

If we are talking about whether to merge the patch which is currently attached (which is what I presumed, and which was the context of my comment), then what I said is correct: the attached patch will, for an unknown reason, fix oversaturation for those with ICCv4 display profiles.  If you read the patch and look at comments 32, 34, 35, 36, 38, 40, and 53, then this is clear.

If, on the other hand, we are talking about getting someone to spend the time to properly fix this (by adding ICCv4 support to qcms), then yes, pretty much everything that has been discussed up to this point is irrelevant.  Additionally, in this context, the attached patch is irrelevant as well.

(Note, shaky memory, but I believe this is correct): Finally, from what I've read (here and in other places), one of the major problems with lcms was speed, especially on Windows.  In some circumstances, images would be noticeably slower to render with CM enabled than with it disabled.  By switching from lcms to qcms, the FF folks were able to ship CM enabled-by-default, which is indeed a step in the right direction.

I would certainly like this bug to be fixed properly — I would like Firefox to pass http://www.color.org/version4html.xalter again.  That said, if the team doesn't have the manpower to do that right now (I have no idea), then from what I've read, merging the attached patch will be a welcome bandaid for some until this bug can be fixed properly.

(Generally) If you have the time and knowledge to work on this, I'm sure a great many folks would appreciate it.  I personally took a serious look at the qcms and lcms code and at the ICCv2 and v4 standards, but I realized that I was way in over my head.  If this might not be the case for you, though, please help.
Attachment #391953 - Flags: approval1.9.2.1?
Attachment #391953 - Flags: approval1.9.1.8?
Comment on attachment 391953 [details] [diff] [review]
Accept version 4 profiles

Jeff said he'll file a new bug for branch approval if he wants it.

Updated

8 years ago
Duplicate of this bug: 455531

Comment 75

8 years ago

ICC color correction in Firefox - MDC
https://developer.mozilla.org/En/ICC_color_correction_in_Firefox

Is your system ICC Version 4 ready?
http://www.color.org/version4html.xalter

Gfx.color management.rendering intent - MozillaZine Knowledge Base
http://kb.mozillazine.org/Gfx.color_management.rendering_intent

Introduction to Colour Management Rendering Intents
http://www.colourphil.co.uk/rendering_intents.html



IN FIREFOX ; COLOR MANAGEMENT

    In question, http://www.color.org/version4html.xalter ;


 -Firefox / addressbar / about:config ;  -Filter / gfx ;

#####

gfx.color_management.display_profile;   file:///C:/WINDOWS/system32/spool/.../color/sRGB_v4_ICC_preference.icc

gfx.color_management.mode;   1

gfx.color_management.rendering_intent;   0

gfx.downloadable_fonts.enabled;   false   (my personal option)

gfx.use_text_smoothing_setting;   true

Comment 76

8 years ago
Test your's PHOTOS and youtube VIDEOS with 

############
gfx.color_management.rendering_intent;   1

############

 with introduce &fmt=18 for appreciate High Quality format in youtube
 fmt=18 videos in youtube .mp4 
          YouTube - Mayon Volcano January 06, 2010 1:21PM
          http://www.youtube.com/watch?v=etvlR8I-CvM&fmt=18
 #######

1 Relative colorimetric 

Introduction to Colour Management Rendering Intents
http://www.colourphil.co.uk/rendering_intents.html

Relative Colorimetric:  This will attempt to map the white point of the image "relative" to that of the original. This is usually ideal for proofing. It is sometimes used with certain reflection copy scanned images, and digital camera images. In which case use PhotoShop's Black Point Compensation or Fuji's appropriate Range Mode.

Comment 77

8 years ago
 COLOR MANAGEMENT  links

Gfx.color management.rendering intent - MozillaZine Knowledge Base
http://kb.mozillazine.org/Gfx.color_management.rendering_intent

Introduction to Colour Management Rendering Intents
http://www.colourphil.co.uk/rendering_intents.html

Firefox 3: Color profile support (oh the pretty, pretty colors) :: dria.org
http://www.dria.org/wordpress/archives/2008/04/29/633/


John Resig - Color Profiles in Firefox 3
http://ejohn.org/blog/color-profiles/


So Many Colors « bholley.work.blog
http://bholley.wordpress.com/2008/09/12/so-many-colors/

#######

Jeffrey Friedl’s Blog » Digital-Image Color Spaces, Page 2: Test Images
http://regex.info/blog/photo-tech/color-spaces-page2




#######
Color management - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Color_management

Comment 78

8 years ago
Also:  https://bugzilla.mozilla.org/show_bug.cgi?id=463221

       https://bugzilla.mozilla.org/show_bug.cgi?id=515958

Comment 79

8 years ago
Can't you just copy the way Webkit (Safari) handles this stuff?
(In reply to comment #79)
> Can't you just copy the way Webkit (Safari) handles this stuff?

Not easily, plus that solution wouldn't be cross platform. ColorSync is only available on OS X.

Comment 81

8 years ago
(In reply to comment #80)
> (In reply to comment #79)
> > Can't you just copy the way Webkit (Safari) handles this stuff?
> Not easily, plus that solution wouldn't be cross platform. ColorSync is only
> available on OS X.

Well, Safari on MS Windows then.

Comment 82

8 years ago
Although I have to admit their implementation has saturation issues.

Comment 83

8 years ago
And Safari on http://www.color.org/version4html.xalter ,  the piece of mountain on the upper right page is a bit blurry.
(In reply to comment #79)
> Can't you just copy the way Webkit (Safari) handles this stuff?
Safari handles it, but Chrome doesn't. Probably WebKit itself doesn't contain a color management code.

Comment 85

8 years ago
What about copying parts of the new lcms2?

http://littlecms2.blogspot.com/

http://www.littlecms.com/

http://code.google.com/p/chromium/issues/detail?id=143

Comment 86

8 years ago
Please consider switching back to LCMS (or LCMS 2) until QCMS is working properly.  All the speed in the world does not matter if it doesn't perform the intended function properly.
All the functionality in the world doesn't matter if it gets your computer exploited (the main reason for the switch to qcms), either.  (Just pointing out the other factor in the decision.)

Also: Bugzilla's not an advocacy forum, and every comment here on such issues is just bugspam for the people who just want to follow progress toward the fix.  Anyone who wants to advocate for a change (or for status quo, for that matter) should do so in one of the newsgroups, probably mozilla.dev.tech.gfx or mozilla.dev.platform.

Comment 88

8 years ago
I wasn't advocating lcms, I just wanted to say that lcms2, according to the developper, is completely new, and thus incomparable with lcms(1).

Updated

8 years ago
Duplicate of this bug: 546579

Updated

8 years ago
Duplicate of this bug: 548802

Comment 91

8 years ago
Sorry, I' late on the issue. On comment #38 (and comment #63): I'm no specialist on ICC, but I think one can produce v4 profiles that have all the v2 information, so that they CAN be compatible, but they need not be. Thus simply assuming every v4 profile is a valid v2 profile, too, may be wrong.
(In reply to comment #91)
> Sorry, I' late on the issue. On comment #38 (and comment #63): I'm no
> specialist on ICC, but I think one can produce v4 profiles that have all the v2
> information, so that they CAN be compatible, but they need not be. Thus simply
> assuming every v4 profile is a valid v2 profile, too, may be wrong.

You are correct, some v4 profile will not be handled. I believe the intent is for qcms to try to process the profile given the v2 tag information and if it is insufficient it will be treated as an invalid profile.
Is the present behavior of FF that v4 display profiles that use the tags supported by v2 will be treated as though they were a v2 display profile and thus honored? And that only v4 profiles embedded in images will be disregarded? I'm unclear on the expected behavior at present.
(In reply to comment #93)
> Is the present behavior of FF that v4 display profiles that use the tags
> supported by v2 will be treated as though they were a v2 display profile and
> thus honored? And that only v4 profiles embedded in images will be disregarded?
> I'm unclear on the expected behavior at present.

Currently FF/qcms basically ignores the version field of all profiles. Thus we'll read any iccv4 profiles as though they were iccv2 profiles.

Comment 95

7 years ago
Currently in order to have proper color management using my HP LP2475w monitor I HAVE to use Firefox 3.0.19 with the Color Management 0.4 add-on. I would REALLY want to upgrade my Firefox version but this bug is preventing me from doing it.

Will this bug/downgrade be finally solved in Firefox 4.0 and will I be able to use Firefox 4.0 and still have proper color management using my above-named monitor?

Comment 96

7 years ago
Same problem here. Using Dell 2709w and Nec 2690wuxi not able see correct colors in FF 3.6.3, still using FF 3.0.19. Please try to fix it. I am sure a lot of users see wrong colors in FF 3.6.3. For me color management in FF 3 was the most useful feature.
Note (I can't add a [parity-IE] on the whiteboard) that ICCv4 will be supported in IE9 ( http://blogs.msdn.com/ie/archive/2010/04/09/Benefits-of-GPU-powered-HTML5.aspx )

Updated

7 years ago
Whiteboard: [parity-IE9]
Also parity-safari, per the test at color.org.

Comment 99

7 years ago
Joe or Jeff,  is this something we want to consider for Firefox 4?  I'm not sure if it would block the release, but I think some of these comments and the parity-* argument sound like it might at least be a priority feature or "wanted" status.

What do you think?
blocking2.0: --- → ?
(In reply to comment #99)
> Joe or Jeff,  is this something we want to consider for Firefox 4?  I'm not
> sure if it would block the release, but I think some of these comments and the
> parity-* argument sound like it might at least be a priority feature or
> "wanted" status.
> 
> What do you think?

Sure, it's easy to say that we want it. However, we don't currently have the resources to get it done, so saying that we want it doesn't really change anything. If someone steps up to do the work that would change things, but the current plan is that Benoit will get to it when he's free from other work.

Comment 101

7 years ago
(In reply to comment #100)
> (In reply to comment #99)
> > Joe or Jeff,  is this something we want to consider for Firefox 4?  I'm not
> > sure if it would block the release, but I think some of these comments and the
> > parity-* argument sound like it might at least be a priority feature or
> > "wanted" status.
> > 
> > What do you think?
> 
> Sure, it's easy to say that we want it. However, we don't currently have the
> resources to get it done, so saying that we want it doesn't really change
> anything. If someone steps up to do the work that would change things, but the
> current plan is that Benoit will get to it when he's free from other work.
I understand that, and it makes a lot of sense.  Just wanted to be sure it didn't fall through the cracks as I didn't know it was on anyone's radar.
Sure we want it, but we can release without it.
blocking2.0: ? → -
status2.0: --- → wanted

Comment 103

7 years ago
IE9 has it, so it would be cool if Fx4 has it too :)

Comment 104

7 years ago
(In reply to comment #103)
> IE9 has it, so it would be cool if Fx4 has it too :)

Plus, there're a lot of peaple who use Firefox 3.0 just
beacause it's support for ICC v4 profiles...
There are builds here: http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/jmuizelaar@mozilla.com-7749f3278460/ that support a much larger portion of ICC v4. It would be great if those having problems could check to see if this build resolves them.

Comment 106

7 years ago
The new test build works for me. Testing it with an ICCv4 profile, I'm not getting oversaturated colours anymore, and it also seems the pass the test at http://www.color.org/version4html.xalter.

Good work.

Comment 107

7 years ago
Latest test build also works for me using a custom ICCv4 LUT with a Dell 2408WFP. Passes the v4 color.org test and also my own test images with assorted profiles opened in Photoshop. My only problem now is 90% of my add-ons are incompatible!

Looking forward to this being included in the stable :-)

Comment 108

7 years ago
A note for testers on MS-Windows: AFAIK Windows Vista and newer have built-in support for ICCv4 in the Operating System, while Windows/XP does not. So just to be sure, report the OS you were testing as well. Specifically: Did anybody try it on WIndows/XP? -- Sorry for the noise, but better fix it now than after release.

Comment 109

7 years ago
No sorry, I'm running Win7x64

Comment 110

7 years ago
Same here, Win 7 x64.
The build uses a modified qcms version and does not depend on the system library. That said it is still helpful to know where this has been tested.

Comment 112

7 years ago
I'm running Windows XP with this (http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/jmuizelaar@mozilla.com-7749f3278460/) build and color test works fine for me (http://www.color.org/version4html.xalter), however, right top part of that image is a little blurry
A couple of comments on the patch:

transform.c:
Add a comment about where 33 comes from

chain.c:
will assert(0 && "input color space not supported"); ever be reached?

in qcms_modular_transform_create() shouldn't rgb_to_xyz be called
rgb_to_pcs? and similar for xyz_to_rgb

qcms_modular_transform_release() doesn't need to null check before
free()

Comment 114

7 years ago
(In reply to comment #105)
> There are builds here:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/jmuizelaar@mozilla.com-7749f3278460/
> that support a much larger portion of ICC v4. It would be great if those having
> problems could check to see if this build resolves them.

It worked great in my testing.  Win32 build, Windows 7 Enterprise x64 OS.  HP elite-book 6930p laptop.  I hope this gets incorporated into the mainline code soon!  Thanks!
> chain.c:
> will assert(0 && "input color space not supported"); ever be reached?
> 
It will be reached if the input color space is GRAY and either profile contain a CLUT. Perhaps this should be changed to ignore the CLUT and use the TRC curves instead.

> in qcms_modular_transform_create() shouldn't rgb_to_xyz be called
> rgb_to_pcs? and similar for xyz_to_rgb
That is true since I moved LAB conversions.
Duplicate of this bug: 551211

Updated

7 years ago
Duplicate of this bug: 606195

Updated

7 years ago
Duplicate of this bug: 610955
Still not supported in the latest trunk under Windows 7 x64.
http://www.color.org/version4html.xalter
Created attachment 508731 [details]
color profile for Thinkpad W 105% gamut display
Latest on Fedora 13 is still ignoring the v4 profile for my wide gamut calibrated Thinkpad display.  Other color managed apps (eg, Gimp) are properly handling the profile.  Attaching a profile (Output of HueyPro for Thinkpad W701 105% gamut display) just in case it's weird.

Comment 122

7 years ago
On comment #121: There once was a (freeware) Windows tool named "ICC inspect" (or so) that would allow one to look inside an ICC profile. I noticed that some vendors of color calibrating software (e.g. Datacolor and theirt Spyder3) want to protect their income like this: The profiles they create are minimal (some call them "Matrix shapers"), but they include some proprietary extension (i.e. the color lookup tables) that only their software can deal with (Otherwise you could profile multiple devices while only having bought/licensed one piece hardware/software). If you (Monty) wants to try the "ICC inspect", send me some E-Mail message.

Comment 123

7 years ago
(In reply to comment #122)
> On comment #121: There once was a (freeware) Windows tool named "ICC inspect"
> (or so) that would allow one to look inside an ICC profile.
You mean this? http://www.color.org/profileinspector.xalter

Comment 124

7 years ago
No, my tool is dated "2002", but the one you've cited looks like a later version of what I have, or at least it's quite similar. Anyway the tool should show you what you need.
Check out iccxml at http://iccxml.sourceforge.net/
You will need SampleICC first, since iccxml depends on that. Basically the command:
iccToXML iccprofilefilename xmlprofilefilename

So when I do this, the only "odd" thing I get in the profile is:
      <TagSignature>wtpt</TagSignature>
      <XYZNumber X="0.96418762" Y="0.99996948" Z="0.82487488"/>

The rX, gX, bX all add up to X above, which is not exactly 1.0. It ought to be exactly 1.0 but I think that this is close enough. What I'm not sure of, is somewhere in Firefox (I'm not sure if it's rolled into qcms or elsewhere) there is a check for valid profiles, and I do not know what threshold was put in for X when it's not 1.0. There were some profiles that had really wrong X values.

Also there is a Firefox log somewhere that will put up a message if the display profile is being ignored and why. So it might be due to the display profile white point. Maybe "error console"?
(In reply to comment #125)
> The rX, gX, bX all add up to X above, which is not exactly 1.0. It ought to be
> exactly 1.0 but I think that this is close enough. 

Those are the value for D50 white point and should not sum to 1.0.
Oops. I meant to write rY,gY,bY should add up to 1.0. They do add up to the Y in the wtpt tag which is close to 1.0 but is not 1.0.

Y for primaries and white point is always normalized to 1.0.
D50 is X=0.9642, Y=1.0000, Z=0.8249

For version 4.0.0 profiles, the spec says the media wtpt tag is supposed to be D50, which is X=0.9642, Y=1.0000, Z=0.8249.

And then the RGB primaries must be adapted such that their XYZs add up to X=0.9642, Y=1.0000, Z=0.8249.

The ThinkPad 4.0.0 profile is not built this way. But I do not know if this is within either the tolerance check in Firefox or qcms. And the ICC doesn't specify a tolerance. Y is simply supposed to be 1.0000.

Comment 129

6 years ago
Created attachment 519735 [details]
color profile eciRGB_v2 by ECI

(In reply to comment #14)
> Can those of you with ICCv4 profiles attach them to the bug. That will help us
> get an idea of what kinds of things will need to be done to support those
> profiles.

Attached color profile by ECI: eciRGB_v2. “eciRGB is recommended by the European Color Initiative (ECI) for use as an RGB working color space and color data exchange format for ad agencies, publishers, reproduction and printing houses.”

Comment 130

6 years ago
I just tested with FF V4 and the problem is still there.  This regression is almost two years old.  Please get it fixed.
Interestingly, Safari 5.0.4 for Windows also dropped a support for ICCv4 profiles.
I don't know if it's related to the dropping of v4 support in Safari Windows, but there are some issues with v4 profiles in general.

I'm not aware that these issues affect the display device class, however. While there are some meaningful differences between the v2 and v4 spec, none of the really helpful ones are required by the spec. So you have to have display profiling application that uses those features. The overwhelming majority of v4 display profiles I've seen are identical to v2 except they state their version as v4.

It's a problem if users can only obtain or produce v4 profiles, so v4 support is needed. However the benefits right now are pretty minor, and wherever possible I recommend building v2 profiles instead until more kinks can be worked out of v4 workflows.

Comment 133

6 years ago
(In reply to comment #131)
I wonder if it should be worse than the Windows "Image and FAX Display" (which is able to handle ICC profiles). Don't find programs that are worse, find programs that are better to compare with!

Comment 134

6 years ago
(In reply to comment #133)
> (In reply to comment #131)
> I wonder if it should be worse than the Windows "Image and FAX Display" (which
> is able to handle ICC profiles). Don't find programs that are worse, find
> programs that are better to compare with!

 A good example of a program
 which currently is actually better
 at color profiles is internet explorer 9.

Comment 135

6 years ago
I wouldn't describe IE9 as better; the latter handles image profiles but ignores monitor profiles (of whatever version), apparently converting all images to sRGB.  IE9 works colour managed only if the monitor happens to be exactly sRGB colour space.
Should this bug depend on bug 538114? I know this isn't a tracking bug, but it seems like a reasonable follow-up. Or perhaps there should be a tracking bug for all QCMS-related work?
Sorry for the lack of update. 

We've landed improvements to the nightly build that support a large subset of ICC v4 profiles. You will need to set the preference |gfx.color_management.enablev4| and restart the browser. Please post any feedback you have here.
(Reporter)

Comment 138

6 years ago
(In reply to comment #137)
> Sorry for the lack of update. 
> 
> We've landed improvements to the nightly build that support a large subset
> of ICC v4 profiles. You will need to set the preference
> |gfx.color_management.enablev4| and restart the browser. Please post any
> feedback you have here.

Tested on Latest Nightly nightly build, 
http://hg.mozilla.org/mozilla-central/rev/cef1817c3b13
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0a1) Gecko/20110729 Firefox/8.0a1 ID:20110729030824

v4 e-sRGB and v4 YCC-RGB looks OK in http://www.color.org/version4html.xalter

Comment 139

6 years ago
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0a1) Gecko/20110729 Firefox/8.0a1

Model identifier: MacBookPro5,1

Testing on http://www.color.org/version4html.xalter returns "The system supports ICC version 2 profiles only"

Comment 140

6 years ago
(In reply to comment #139)
> Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0a1) Gecko/20110729
> Firefox/8.0a1
> 
> Model identifier: MacBookPro5,1
> 
> Testing on http://www.color.org/version4html.xalter returns "The system
> supports ICC version 2 profiles only"

My apologies. Neglected to set appropriate config. 

"The system supports these ICC version 4 and version 2 profiles" !!!
Appears to work for me with v2 and v4 display profiles (destination profiles) in conjunction with v2 and v4 source profiles: i.e. v2-v2, v2-v4, v4-v2, v4-v4. Albeit limited testing.
With gfx.color_management.mode set to 1, http://www.color.org/version4html.xalter now reports that none of the ICC profiles are supported on my system. Did the meaning of the setting change, or is it rejecting my (v2 LUT) profile for some reason? Even if it is, shouldn't the images' profiles still be applied anyway? Being on a tethered connection, unfortunately I can't really do any regression testing on this. I might be able to upload the profile I'm using, however, should that prove useful (it was created using a ColorMunki Photo).
(In reply to comment #142)
> With gfx.color_management.mode set to 1

gfx.color_management.mode default is 2. This bug is about gfx.color_management.enablev4 being set to true (from false).

When gfx.color_management.enablev4 = true, and I change gfx.color_management.mode = 1, I get the same results as before (comment 141). I'm unable to reproduce comment 142, however the v4.2 display profile I have is LUT + matrix/TRC. I don't have a ColorMunki profile handy but I'm pretty sure even its LUT profiles have both LUT tags and conventional (required AFAIK) rgbXYZ and rgbTRC tags.

Is FF/qcms using LUT if present? Or does it continue to use rgbXYZ+rgbTRC tags?
You're right, the v4 setting does work as expected (with gfx.color_management.mode set to 2), so this probably isn't the right place to for this discussion. Would you like me to file a new bug? I can't do much testing for the next two weeks, however, due to bandwidth restrictions.
(In reply to comment #144)
I'd have to defer to others on strategy. If I were testing and had this experience I'd isolate it by creating a new user so I had a clean set of preferences, make the changes to gfx.color_management.mode and gfx.color_management.enablev4 as you did and see if it's still reproducible. If so, yeah I'd file a new bug. I would not expect the structure or version of ICC profile to cause gfx.color_management.mode 1 to behave as if it were gfx.color_management.mode 0. If I'm understanding your experience correctly.
(In reply to comment #143) 
> Is FF/qcms using LUT if present? Or does it continue to use rgbXYZ+rgbTRC
> tags?

qcms will prefer LUT if present.
Okay, I can try a new profile; if that doesn't help I think I'll wait and see if bug 585074 gains any traction. If not I'll file a new bug when I get home (assuming no one else runs into this and there's an easy fix in the meantime).

Updated

6 years ago
Depends on: 679371

Updated

6 years ago
Duplicate of this bug: 509273
Gentle ping. What's the status in this bug?

FYI, Opera support ICC v4- http://my.opera.com/desktopteam/blog/2012/08/28/core

Comment 150

5 years ago
Why didn't Jeff Muizelaar's code that fixed this bug get merged into the mainline?

Comment 151

5 years ago
Is in Opera 12.10: http://my.opera.com/ODIN/blog/opera-12-10-is-out
"Opera 12.10 also supports International Color Consortium (ICC) profile v4, which will make photographs more vibrant and colorful, displaying them exactly as the photographer intended.

In the example below, you see what difference this can make. This photo of a caterpillar by Flickr user Scarlet St looks more vibrant in Opera 12.10 compared to its predecessors, because the Adobe RGB (1998) profile included in the image metadata is applied (as intended)."

Updated

5 years ago
Whiteboard: [parity-IE9] → [parity-IE9][parity-Opera12]
(Reporter)

Updated

2 years ago
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INCOMPLETE

Comment 152

2 years ago
What's up with Alice0775 White's mass-closing of bugs?

Updated

2 years ago
Flags: needinfo?(alice0775)
(Reporter)

Updated

2 years ago
Status: RESOLVED → REOPENED
Flags: needinfo?(alice0775)
Resolution: INCOMPLETE → ---
Blocks: 1179671
Is this bug still valid?
Flags: needinfo?(alice0775)
Version: Trunk → 1.9.2 Branch

Comment 154

10 months ago
Yes. see http://www.color.org/version4html.xalter
More specifically, the value of gfx.color_management.enablev4 is still false by default. Unfortunately I don't think anyone is actively working on qcms (or has in years).
(Reporter)

Updated

10 months ago
Flags: needinfo?(alice0775)
Whiteboard: [parity-IE9][parity-Opera12] → [parity-IE9][parity-Opera12][gfx-noted]
You need to log in before you can comment on or make changes to this bug.