Firefox does not color manage any images except for ones tagged with my specific monitor .icc profile
I'm having an issue that's causing quite a few problems for me. It seems that Firefox is not color managing any images - and by that I mean, it is outright discarding the profiles/failing conversion, unless the image in question is tagged with the same color profile that my monitor is presently using.
My monitor is calibrated with an i1 Display Pro, and consequently the monitor/OS is set to use a custom color profile. We'll call this myprofile.icm. Now, this profile serves me well in almost any other application - Photoshop, where myprofile.icm is the working space for RGB images, no issues. In Firefox however, any images that are not saved with myprofile.icm embedded wind up displaying as if there is no color management on them at all.
For example, let's say I've worked on a painting in my custom profile, and prior to saving it as a .png for the web I convert it to sRGB and save it with the sRGB profile embedded. This does not cause significant change, and the new .png will display properly in Photoshop whether I open it and use the embedded sRGB profile, or reconvert it to the working space. This same .png will also display properly in Window's photo gallery and other browsers. As soon as I open the image in Firefox, however, the image is displayed as if the color profile is completely thrown out the window (I can replicate this view of the image by opening the image in Photoshop, and choosing to discard the embedded profile, and not color manage the file at all). Any sRGB image, or untagged image, is displaying in Firefox as if it is not color managed at all. Be it a .png, .jpg, my own image - or anyone else's. The only images that display properly are images with myprofile.icm embedded.
I've messed around with my about:config options, but they present sit as follows:
gfx.color_management.display_profile [blank] (this is the default) gfx.color_management.mode 2 (this is the default) gfx.color_management.rendering_intent 0 (this is the default)
I've tried setting gfx.color_management.display_profile to point to the very specific .icm profile that my system is currently using, restarted Firefox, no difference. I tried setting gfx.color_management.mode to 1, as well as 0, and neither of these fixed my issue. I also tried changing gfx.color_management.rendering_intent to -1 for curiosity's sake, and this also did not resolve the problem.
The fact that any sRGB tagged, or untagged images are displaying identically to if I open them in photoshop and intentionally discard color profiles, and don't color manage the image, is concerning.
Now, my fairly non-technical understanding of Firefox's color management solution is that it supports embedded profiles, but should also effectively convert the color information to your monitor's in-use profile for accurate color representation. What appears to be happening is that any time this conversion actually takes place, it fails, and discards the information entirely. This may be why images already tagged with my monitor profile work without issue? I am uncertain.
Any information or additional assistance regarding this would be awesome, because it's a fairly significant issue for me.
- Wacom Dynamic Link Library
- Shockwave Flash 18.0 r0
- Plugin for Wacom tablets.
- User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0
As an update to this, the more I look into the issue the more I'm suspecting that Firefox is detecting my system/monitor color profile to be bogus.
I "pass" tests such as:
But the issue is that images do not always match what I can see in other color-managed applications (such as Photoshop). The only thing I can think of to explain this is that Firefox is reading embedded ICC profiles appropriately, and if set to, will assign untagged images an sRGB profile, and then when it tries to convert to monitor RGB says "Hey this is a bogus profile, using sRGB as monitor RGB instead..."
Can someone tell me, does this sound plausible? Is there a way for me to tell if Firefox is actually utilizing my monitor RGB profile?
由 Linguini 於 修改
I tried calibrating a laptop display once; not a good experience. But I digress.
You are correct that by default, Firefox will only try to color manage tagged images. There are several hidden preferences you could check/experiment with:
(1) In a new tab, type or paste about:config in the address bar and press Enter/Return. Click the button promising to be careful.
(2) In the search box above the list, type or paste gfx.c and pause while the list is filtered
gfx.color_management.display_profile - if Firefox is not using your monitor profile you can enter the path to it here - you may need to exit Firefox and start it up again for a change to this preference to take effect
gfx.color_management.mode - governs application of color management to images
0 = off 1 = on for ALL images 2 = on for TAGGED images (default)
gfx.color_management.rendering_intent - whether Firefox honors or overrides the intent flag in the ICC profile, by default, overrides to Perceptual
gfx.color_management.enablev4 - double-click to toggle to true if you are using an ICC v4 profile
Can you find a combination of settings that does what you want?
I am not able to rectify the issue I'm experiencing with any combination of about:config color management options. The issue is not that Firefox is utterly ignoring any attempts at color management. It will utilize embedded ICC profiles, and will assume sRGB for untagged images if gfx.color_management.mode is set to 1 appropriately. The issue, however, is that despite it managing these profiles - they do not look exactly accurate, because they are not then utilizing my monitor profile thereafter.
The flow, assuming color management is enabled for Firefox, to my knowledge is supposed to be:
Acknowledge tagged images and utilize their embedded profiles (if color_management.mode set to 2 > Convert to Monitor RGB utilizing color_management.rendering_intent > Rejoice in seeing accurate color for your screen (assuming a properly calibrated/profiled system).
The issue I'm having is that it seems the second step is failing, as it does not seem to be using my monitor profile at all. I am wondering if Firefox is detecting my monitor profile to be faulty/corrupted/otherwise bogus, because I believe then it will simply assume an sRGB profile for the monitor. Which would be fine, except that sRGB will almost certainly not be an accurate color profile to use for one's system - a properly calibrated display will have a custom profile that should be used instead.
I have tried pointing Firefox to my specific monitor/system profile via the gfx.color_management.display_profile config, and this does not rectify the issue.
This may be more a developer question - but I'm really wondering, is there a way to tell if Firefox is viewing my monitor profile to be "valid"?
Thank you for the response, I appreciate the help.
I am wondering if Firefox is detecting my monitor profile to be faulty/corrupted/otherwise bogus, because I believe then it will simply assume an sRGB profile for the monitor.
There is a section of the code that examines the profile to make sure it is not "bogus" but the math here is beyond me and I'm not sure whether there is a way to detect what Firefox decides:
- Call to function: https://dxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxPlatform.cpp#1857
- Function: https://dxr.mozilla.org/mozilla-central/source/gfx/qcms/iccread.c#272
If you search around discussion forums oriented toward graphics/photography professionals, perhaps you can find similar reports and workarounds/solutions that don't require understanding the code. (I hope!)
Hrmm, well, the issue definitely does seem to be that it's simply not successfully converting images to my monitor RGB profile - even though it is using the embedded ICC profiles without issue.
All of my images in Firefox show up identically to how they show up in something like Opera, which utilizes color management, but does not consider your monitor profile in its solution.
That being said, according to that code you've linked to, Firefox's handling of color profiles for one's system - and determining whether or not they're "bogus", should be similar to Adobe's if not more lenient, and Photoshop is utilizing my monitor profile without any issues whatsoever. I've compared the math in the function you linked to with the values in my color profile, and I see nothing that would cause alarm based on that code. Of course, code is not my forte, so I could be missing something.
I can only assume at the moment that the issue is something to do with Firefox, or the rest of that code that makes all sorts of references I'm no familiar with.
I guess I will try to generate additional color profiles over the next several days, and see if any of them do wind up working.
Upon doing some additional research, I've come to the conclusion that Firefox is having issue with table-based color profiles (rather than matrix profiles). Did some reading and reportedly there was some work done to support LUT based profiles, though some say you need to have gfx.color_management.enablev4 enabled (I've tried it with or without, no dice either way), but Firefox still seems to not work properly with all of them. Other color managed applications (Photoshop, Window's photo gallery in Windows 7) seem to work without any problems.
I copied my wife's matrix based RGB monitor profile onto my computer, and as soon as I set that to my default and relogged in, Firefox was showing things consistent with Photoshop.
Bit of a bummer but at least it's something. Definitely seems to be on Firefox's end, not handling certain table based profiles correctly. I guess I'll recalibrate and generate a matrix profile for this system over the next few days in an attempt to fix the issue.
Thank you for reporting back. If a lot of users want a feature supported, there would be some hope of getting it on the agenda or further up the agenda. You can submit feedback here:
If you spend time on forums of other Firefox + calibration users, have them submit feedback, too.