Closed Bug 488800 Opened 16 years ago Closed 2 years ago

qcms doesn't support ICC version 4

Categories

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

Product:
Core
Component:
Graphics: Color Management
Version:
1.9.2 Branch
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
108 Branch
Tracking Flags:
Tracking Status
blocking2.0 --- -
status2.0 --- wontfix
relnote-firefox --- 108+
firefox108 --- fixed

People

(Reporter: alice0775, Assigned: jrmuizel)

References

(Depends on 1 open bug, Blocks 3 open bugs,
URL
)

Details

(6 keywords)

Attachments

(14 files)

v4 Matrix profile for Acer P243W by LaCie Blue Eye Pro
3.94 KB, application/octet-stream
Details
v4 LUT profile for Acer P243W by LaCie Blue Eye Pro
78.29 KB, application/octet-stream
Details
Nec LCD2690WUXI ICC profile
84.63 KB, application/octet-stream
Details
Color profile for HP LP2475w wide gamut monitor created with Huey Pro calibrator
3.86 KB, application/octet-stream
Details
color profile for HP 2475w made by TFTCentral
3.96 KB, application/octet-stream
Details
Philips 240PW9ES ICC profile
100.37 KB, application/octet-stream
Details
v4 LUT for Dell 2408WFP by Eye-One Match 3 using Eye-One Display 2
656.51 KB, application/octet-stream
Details
Profile for HP LP2475w from Spyder2
27.80 KB, application/octet-stream
Details
ICC v4 profile for MacBook Pro 15" (Summer 07)
242.88 KB, application/octet-stream
Details
Accept version 4 profiles
772 bytes, patch
bholley
: review+
Details | Diff | Splinter Review
srgb v2 profile
2.98 KB, application/octet-stream
Details
color profile for Thinkpad W 105% gamut display
3.83 KB, application/octet-stream
Details
color profile eciRGB_v2 by ECI
700 bytes, application/octet-stream
Details
Bug 488800. Let ICCv4 support ride out to release.
48 bytes, text/x-phabricator-request
Details | Review
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
Blocks: 481926
Severity: major → normal
Keywords: regression
Version: unspecified → 3.1 Branch
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.
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.
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
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?
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.
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.
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.
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.
I also added my monitor profile, in case it can be helpful to the developers.
Color profile for HP 2475w wide gamut made by TFTCentral using LaCie Blue Eye Pro.
Supplied by Philips, taken from the driver disc.
v4 LUT for Dell 2408WFP by Eye-One Match 3 using Eye-One Display 2
Profile for HP LP2475w from Spyder2
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.
Sorry, the profile I submitted for the HP LP2475w from a Spyder2 was v2.4 - not v4 as I thought.
Flags: wanted1.9.2?
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.
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.
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
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
(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.
Just add support to all the stuff described at this page (also the answer to question 2): http://www.color.org/version4html.xalter
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.
(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.
(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.
(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.
Attached file 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?
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+
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?
Flags: in-testsuite?
Flags: blocking1.9.2?
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?
(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
Flags: in-testsuite?
Flags: in-testsuite-
Flags: in-litmus?
Flags: in-litmus-
The feature being: support for IIC V4 color profiles / passing the test on: http://www.color.org/version4html.xalter
*ICC
Mozilla Firefox used to pass this test, but now it's just as bad as Microsoft Internet Explorer is.
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?
(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?
Anyway, I belief people are talking about more than one subject on this bug-page.
(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."
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
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.
(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.
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.
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.
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
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.
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
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.
(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.
Although I have to admit their implementation has saturation issues.
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.
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.
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).
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.
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?
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 )
Whiteboard: [parity-IE9]
Also parity-safari, per the test at color.org.
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.
(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
IE9 has it, so it would be cool if Fx4 has it too :)
(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.
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.
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 :-)
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.
No sorry, I'm running Win7x64
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.
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()
(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.
Still not supported in the latest trunk under Windows 7 x64. http://www.color.org/version4html.xalter
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.
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.
(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
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.
(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.”
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.
(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!
(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.
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.
(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
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"
(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).
Depends on: 679371
Why didn't Jeff Muizelaar's code that fixed this bug get merged into the mainline?
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)."
Whiteboard: [parity-IE9] → [parity-IE9][parity-Opera12]
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INCOMPLETE
What's up with Alice0775 White's mass-closing of bugs?
Flags: needinfo?(alice0775)
Status: RESOLVED → REOPENED
Flags: needinfo?(alice0775)
Resolution: INCOMPLETE → ---
Blocks: 1179671
Is this bug still valid?
Flags: needinfo?(alice0775)
Version: Trunk → 1.9.2 Branch
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).
Flags: needinfo?(alice0775)
Whiteboard: [parity-IE9][parity-Opera12] → [parity-IE9][parity-Opera12][gfx-noted]
Perhaps lcms2 should be reevaluated, it supports ICC v4 and the performance considerations for the original switch to qcms may no longer be true either hardware wise or with lcm2's optimizations. And if it turns out lcms2 needs more optimization, better to improve lcms2 so other projects can take advantage.
(In reply to bugzilla@colorremedies.com from comment #156) > Perhaps lcms2 should be reevaluated, it supports ICC v4 and the performance > considerations for the original switch to qcms may no longer be true either > hardware wise or with lcm2's optimizations. I also think that compilers made quite some progress within the eight years this bug exists ;-)
(In reply to bugzilla@colorremedies.com from comment #156) > Perhaps lcms2 should be reevaluated, it supports ICC v4 and the performance > considerations for the original switch to qcms may no longer be true either > hardware wise or with lcm2's optimizations. Note too that Little CMS has always had an emphasis on low footprint and high performance (hence the name) and the latest version also mentions perf improvements: Little CM2 2.8 released! which adds alpha channel handling and improved performance, new plug-in types, bugfixes and other minor features. http://www.littlecms.com/ > > And if it turns out lcms2 needs more optimization, better to improve lcms2 > so other projects can take advantage. Sure, although an evaluation of the current performance is a necessary first step.
The main reason to switch back would be that I'm fairly sure qcms has barely been developed since incomplete ICC v4 was added years ago. I suspect this is because it was written in C and its main repository lives outside mozilla-central. The large stylistic differences from core Gecko code and the requirement to uplift (even if the repository owner promptly responds to requests) makes this component less appealing for developers to work on. The advantage to switching back to LCMS would thus be that it is actively developed without Mozilla having to commit additional resources. The disadvantage compared to something purely in-tree is that we would need to periodically update our version, but I think that's probably still better than the status quo. Of course, the current performance of LCMS would have to be evaluated first.
It looks like all the other major browsers support this correctly now.
Whiteboard: [parity-IE9][parity-Opera12][gfx-noted] → [parity-chrome][parity-safari][parity-ie][parity-edge][parity-presto opera]
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-chrome, parity-edge, parity-ie, parity-opera-mini, parity-safari
Whiteboard: [parity-chrome][parity-safari][parity-ie][parity-edge][parity-presto opera]
(In reply to Jonathan Watt [:jwatt] from comment #160) > It looks like all the other major browsers support this correctly now. so it there any specific regression? (sorry if there was previous comment for this I missed)
See Also: → 999600

Today, the lack of ICC v4 makes XYB JPEGs look green.

See https://twitter.com/jyzg/status/1569249920556888066 for an example, left image is libjpeg, right is XYB (in this version defined as an RGB jpeg).

Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 8 duplicates, 113 votes and 103 CCs.
:aosmond, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(aosmond)

Sure.

Severity: S3 → S2

Latest version is Little CMS 2.13.1 from Jan 2022, so actively maintained including security and bugfixes.

This 14-year-old bug means Firefox is trailing Chrome and Safari in this area; which is particularly important given wide gamut color in CSS Color 4 and 5 (part of Interop 2022) and the increase in profiled, wide gamut screens in consumer hardware.

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(aosmond)

At least pdf-view still doesnt seem to support any CSS either 2 nor 4.
Picture looks correct (for me) in html: https://www.color.org/version4html.xalter
But no support for CSS at all in pdf-view: https://www.color.org/version4pdf.pdf

Assignee: nobody → jmuizelaar

Release Note Request (optional, but appreciated)
[Why is this notable]: It's a feature people have wanted for a long time and Chrome and Safari have done it for a long time.
[Affects Firefox for Android]: I'm not sure
[Suggested wording]: Firefox now supports properly color correcting images tagged with ICCv4 profiles.
[Links (documentation, blog post, etc)]:

relnote-firefox: --- → ?
Pushed by jmuizelaar@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/dd4af60f439b Let ICCv4 support ride out to release. r=aosmond

I agree that after closing out this long-standing bug, a note to say

a) why it is important
b) that it can now be relied upon, being fully cross-browser

would be appreciated.

https://hg.mozilla.org/mozilla-central/rev/dd4af60f439b

Status: REOPENED → RESOLVED
Closed: 10 years ago → 2 years ago
status-firefox108: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 108 Branch

(In reply to Grisu from comment #168)

But no support for CSS at all in pdf-view: https://www.color.org/version4pdf.pdf

It's bug 860023.

(In reply to Grisu from comment #168)

At least pdf-view still doesnt seem to support any CSS either 2 nor 4.

You man ICC, or really CSS?

Sorry, of course ICC v2 and v4 doesnt work with pdf.
Just open the link and you will see the wrong colors.

PDF spec 1.3 to 1.7 supports ICC profile format spec 2.x
PDF spec 2.x supports ICC profile format spec 2.x and 4.x

Anything creating PDF is expected to convert a v4 ICC profile into a v2 ICC profile, rather than embedding a v4 profile and expecting the reader to handle it.

Thats what Edge-Chrome is doing, showing at least ICC v2 correctly and failing with ICC v4.
But on Firefox I see different coulors in all 4 quarters.

Bug 860023 handles ICC proiles in PDFs.

(In reply to polet82 from comment #4)

I wonder why is that? v4 worked fine in 3.0

(In reply to Dave from 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.

(In reply to Simon Garrett from comment #28)

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.

(In reply to ruben.nesvadba from comment #59)

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

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

(In reply to Aaron Kelly from comment #86)

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.

(In reply to Emanuel Hoogeveen [:ehoogeveen] from comment #155)

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).

(In reply to Jyrki Alakuijala from comment #163)

Today, the lack of ICC v4 makes XYB JPEGs look green.

See https://twitter.com/jyzg/status/1569249920556888066 for an example, left image is libjpeg, right is XYB (in this version defined as an RGB jpeg).

Before this comment the issue had nothing to do with PDF (despite the ICC page mentioning a PDF version)!

(In reply to Grisu from comment #168)

At least pdf-view still doesnt seem to support any CSS either 2 nor 4.
Picture looks correct (for me) in html: https://www.color.org/version4html.xalter
But no support for CSS at all in pdf-view: https://www.color.org/version4pdf.pdf

Then this comment seems to be the reason to close the bug!

(In reply to Chris Murphy from comment #177)

PDF spec 1.3 to 1.7 supports ICC profile format spec 2.x
PDF spec 2.x supports ICC profile format spec 2.x and 4.x

Anything creating PDF is expected to convert a v4 ICC profile into a v2 ICC profile, rather than embedding a v4 profile and expecting the reader to handle it.

And this seems to be a completely different issue IMHO:

(In reply to Masatoshi Kimura [:emk] from comment #179)

Bug 860023 handles ICC proiles in PDFs.

So basically I really wonder: While celebrating the standstill in qcms for 14 years, there would have been a working solution named LCMS all the time. I'm not sure bug 1564585 is basically a consequence of this one, but I'm really tired seeing green faces (even the DuckDuckGo icon appears green) all the time.

I could not reach this bug from bug 1500737. Adding dependency.

Blocks: 1500737
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: