Closed
Bug 450923
Opened 16 years ago
Closed 16 years ago
white background color has turned a tint of yellow
Categories
(Core :: Graphics: Color Management, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 460629
People
(Reporter: 14kgary, Assigned: glennrp+bmo)
References
(Blocks 1 open bug, )
Details
Attachments
(5 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1a2pre) Gecko/20080816032044 Minefield/3.1a2pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1a2pre) Gecko/20080816032044 Minefield/3.1a2pre
I upgraded to the latest nightly build of Firefox 3.1a2pre. When the browser loaded a lot of things were tinted yellow. For example, when going to google.com the usual white page is now a tint of yellow, but the text box is still white. When I revert back to Firefox 3.0 it changes back to white. The URL bar and the search bar backgrounds have also been tinted yellow, as well as the focused tabs in the tab bar (though not the unfocused tabs) and the favicons of websites that show up just as a blank page, that blank page is yellow. I have opened minefield in safe mode, but the same thing is still happening. I tried going to about:config to see if the background color got changed, but it is still #FFFFFF.
Here is a link to how i see google.com: http://gary.katsevman.com/wp-content/uploads/minefield.png
Reproducible: Always
Steps to Reproduce:
1.
2.
3.
Comment 1•16 years ago
|
||
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a2pre) Gecko/20080816105915 Minefield/3.1a2pre
This works fine for me. Have you tried:
- Firefox's safe-mode to exclude extension/theme problems
- a new profile
- a reinstall in a new empty folder?
http://kb.mozillazine.org/Safe_Mode_(Firefox)
http://kb.mozillazine.org/Profile_Folder
Yes, I have tried safe mode. Yet to try a reinstall, that might do it.
Assignee | ||
Comment 3•16 years ago
|
||
Have you got gfx.color_management.enabled or not?
Glenn: that might be the reason. In my Firefox 3.0 installation I have gfx.color_management.enabled set to false, but in minefield I dont have it, and if i try to add it, when I restart minefield the boolean disappears from about:config. Could this be what is doing it?
Assignee | ||
Comment 5•16 years ago
|
||
That seems a bit weird. But, if you have color_management on, then chances are you have a bad display profile (gfx.c0olor_management.display_profile). Like you, I see the "enabled" boolean is gone and replaced with gfx.color_management.mode which is a user-set integer, "1" in my case. I guess that means color_management enabled, but that's only a guess. I'll start weeding through the code to find out unless someone already knows and posts the meaning of "mode" here.
Assignee: nobody → glennrp
I did a quick google search from gfx.color_management.mode. It seems to replace gfx.color_management.enabled boolean:
gfx.color_management.mode / integer / 0=off, 1=on, 2=taggedonly (Firefox 3.1) and this is the bug that it was addressing: https://bugzilla.mozilla.org/show_bug.cgi?id=449681
got it from here: http://7rd.net/ssb/archives/firefox/
Assignee | ||
Comment 7•16 years ago
|
||
(In reply to comment #6)
> I did a quick google search from gfx.color_management.mode. It seems to replace
> gfx.color_management.enabled boolean:
OK, so back to my question in comment #3. Do you have mode 0 or 1 or 2? If not 0, then what is your display_profile string?
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
i had mode 1, and nothing under display_profile. I took a closed look at mode, and it said it was user set, so, i reset it, and it was changed to 0, and now everything is back to its normal white color.
I just tried making it 2, and when it is 2, most places it is white still, but some places it is tinted yellow as well.
Assignee | ||
Comment 9•16 years ago
|
||
I am running Windows XP and have gfx.color_management.display_profile string set to
"C:\\WINDOWS\\system32\\spool\\drivers\color\sRGB Color Space Profile.icm");
I don't know if those last two characters really belong there, but that's what I have. I don't know if the same string would be appropriate for Vista, but I think leaving it blank is probably wrong.
Assignee | ||
Comment 10•16 years ago
|
||
In the string, \color\ is \\color\\(In reply to comment #9)
> I am running Windows XP and have gfx.color_management.display_profile string
> set to
>
> "C:\\WINDOWS\\system32\\spool\\drivers\color\sRGB Color Space Profile.icm");
\color\ should be \\color\\
Comment 11•16 years ago
|
||
As mentioned in bug 450283, leaving the profile blank causes the OS to be queried for the system profile. As such, it sounds like you have a bad profile for your monitor.
Try doing a google search for an ICC profile set up for your display and install it according to (http://www.redriverpaper.com/blog/2007/09/installing-icc-color-profiles-on.html). That should let you get the benefits of color management (turning it on) and fix the bad color mappings.
What worries me more is that it sounds like you never fussed with the color management settings before. There's currently migration code to detect if the user has the old color_management.enabled pref set to TRUE and, after deleting the old pref, set the new color_management.mode to 1, and 0 otherwise (I believe this detection is done using HasUserValue("color_management.enabled") or something like that). Are you sure you never messed with the color management settings in your old profile? Can you reproduce this issue by making a firefox 3.0 profile, not touch the color settings, upgrading to 3.1, and finding color_management.mode set to 1? If so, it's a bug and I need to fix it.
Updated•16 years ago
|
Component: General → GFX: Thebes
Product: Firefox → Core
Version: unspecified → Trunk
Comment 12•16 years ago
|
||
Not sure if a new evangelism bug should be opened.
It seems that at least some LG monitors don't provide a proper ICC profile,
resulting in a increase of yellow component.
See discussion:
http://forums.mozillazine.org/viewtopic.php?f=23&t=849295&st=0&sk=t&sd=a&start=15
And samples:
http://img357.imageshack.us/my.php?image=yellowtintwt0.jpg (mode 2)
http://carpi.eu/~diegoliz/color-management.png (mode 1)
Comment 14•16 years ago
|
||
As far as I know, Windows XP does not create display profiles on the fly like Mac OS X does. When a display profile is not set, then the OS assumes sRGB and would report that as the Display profile, to be used as the destination profile by FireFox. So right now this bug has insufficient data to draw conclusions.
I would like to see the problem reproduced, and then once the problem is occurring, need three pieces of information, for starters:
The value of gfx.color_management.mode
The value of gfx.color_management.display_profile
The value of "Default monitor profile" found in: Display control panel-> Settings Tab->click Advanced button->Color Management tab
Locate and upload the specified "Default monitor profile" reported by the OS.
Comment 15•16 years ago
|
||
Chris, I was seeing this on vista, see bug #460331
gfx.color_management.mode was 2, I think gfx.color_management.display_profile was "".
Does https://bugzilla.mozilla.org/attachment.cgi?id=343452 or https://bugzilla.mozilla.org/attachment.cgi?id=343453 happen to contain the information you are looking for?
if not, in a couple days when I'm back in front of my vista machine I will get you the information you requested.
Comment 16•16 years ago
|
||
Still need the last two items.
Comment 17•16 years ago
|
||
This is my default icc profile.
Using XP and the yellow background happens only setting gfx.color_management.mode=1
(gfx.color_management.display_profile string is left empty)
Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081017 Minefield/3.1b2pre
Comment 18•16 years ago
|
||
Comment 19•16 years ago
|
||
(In reply to comment #17)
> Created an attachment (id=343734) [details]
> icc profile for lg m1917A monitor
There are only minor issues with this profile (creator and desc tags were invalid), that would not prevent the profile from working normally. I would expect this profile to work.
Could you please go <a href="http://www.color.org/srgbprofiles.xalter">here</a> and download the 2nd to last profile at the bottom of the page "sRGB_IEC61966-2-1_noBPC.icc". Right-control click on the profile once downloaded, and in the contextual menu choose to install it. Then you need to go to Displays control panel, advanced, color management tab as before, add it, and then choose it as the default display profile. Then restart computer and application (just to be sure it takes). And then report back if you're able to reproduce the yellow problem or not.
Comment 20•16 years ago
|
||
It would be useful if someone else could download Diego's "lg m1917A" profile, install it, select it as their default display profile, restart and then try to reproduce this bug with that profile.
Comment 21•16 years ago
|
||
(In reply to comment #19)
>
> Could you please go <a href="http://www.color.org/srgbprofiles.xalter">here</a>
> and download the 2nd to last profile at the bottom of the page
> "sRGB_IEC61966-2-1_noBPC.icc".
> [..] Then restart computer and
> application (just to be sure it takes). And then report back if you're able to
> reproduce the yellow problem or not.
Restarting application has been enough. I can't reproduce it with the above icc profile. No more yellowish background.
Is it still valid what I told in comment #11 ?
Comment 22•16 years ago
|
||
(In reply to comment #21)
>I can't reproduce it with the above icc profile. No more yellowish background.
OK, let's try it again with the profile I'm about to upload.
> Is it still valid what I told in comment #11 ?
I don't understand the question.
Comment 23•16 years ago
|
||
Attachment is an ICC profile for an NEC2180WG with a D65 white point, and corresponding wtpt tag (wtpt tag is NOT D50).
Comment 24•16 years ago
|
||
(In reply to comment #22)
> OK, let's try it again with the profile I'm about to upload.
Still working fine with the NEC ICC profile you uploaded (no more yellow background)
> I don't understand the question.
Is the bug in my old profile or in firefox handling it?
In the first case could the solution be a sort of evangelism bug (i.e.
contacting the monitor driver manufacturer)?
Comment 25•16 years ago
|
||
(In reply to comment #24)
> Still working fine with the NEC ICC profile you uploaded (no more yellow
> background)
Thank you. You can discard the NEC profile. It's a not a good profile to use with any other display.
> Is the bug in my old profile or in firefox handling it?
> In the first case could the solution be a sort of evangelism bug (i.e.
> contacting the monitor driver manufacturer)?
The display profile is the problem. If you contact source of this profile (LG I assume?) you may find it challenging to find someone who can actually understand a.) that there is a problem; b.) what the problem is. They absolutely need to stop distributing the profile.
A fundamental color basic is that red + green + blue = white. If you notice, your display when completely white does not have a single white pixel, it actually gets this by adding red, green and blue pixels together. The profile is supposed to do the same thing.
The XYZ values in the LG display profile, when added up, come to
0.951, 1.001, 1.088. This is consistent with the wtpt tag. The problem is that the PCS illuminant is D50, not D65. The rule is that the primaries are supposed to be adapted to D50. In this case, they would add up to 0.964, 1, 0.825 and in fact all CMS expect that they will add up to this.
This is a rare and pretty silly mistake for them to make, but I can see how they'd goof and just not chromatically adapt the primaries to D50. I didn't think to test this particular problem until you reported back with your results.
Bobby, you could conceivably parse the reported profile and add up the red X value, green X value, blue X value and ensure the result is 0.964, 1, 0.825. If it's not, then ignore the display profile and assume sRGB as the destination profile.
Personally I think this is something OS's should do, and reject the setting of display profile with obviously incorrect contents, so that applications don't have to worry about this. In fact, Photoshop flags me when I set this profile as my display profile, and says it's a bad profile, so it is testing for this very problem.
Comment 26•16 years ago
|
||
(In reply to comment #25)
> Bobby, you could conceivably parse the reported profile and add up the red X
> value, green X value, blue X value and ensure the result is 0.964, 1, 0.825. If
> it's not, then ignore the display profile and assume sRGB as the destination
> profile.
Sure thing - can you file a bug and assign it to me? Should this hold in all cases?
Comment 27•16 years ago
|
||
Yes. Yes.
We need to come up with a tolerance however. Some display profiles do sloppy adaptation and so XYZs don't add up exactly. I think this can be done by reducing the sigfigs to allow some inaccuracy. I will investigate. Otherwise I think this bug can be closed. I'll reference it in the new bug.
Comment 28•16 years ago
|
||
Bug 460629 submitted. Needs to be assigned to the proper component and to Bobby (I'm unable to do this).
Comment 29•16 years ago
|
||
Do you think that can be useful to have other problematic icc profile submitted?
I'm not the only one having this issue:
see forum link in comment 12 and maybe
bug 455077 comment 3 (second monitor in a MacBook, Lightroom works fine, firefox don't).
Comment 30•16 years ago
|
||
> Locate and upload the specified "Default monitor profile" reported by the OS.
sorry for the delay, here's my L1933TR.ICM file, which is the default monitor profile
Comment 31•16 years ago
|
||
(In reply to comment #30)
> here's my L1933TR.ICM file, which is the default monitor profile
I can confirm that with this profile the color shift is bigger than with my LG Monitor profile.
BTW What monitor is this profile for?
So far I've heard this kind of trouble only with LG monitors ICC profiles.
Comment 32•16 years ago
|
||
> BTW What monitor is this profile for?
LG L1933TR(Analog).
http://us.lge.com/products/model/detail/computer%20products_lcd%20monitors_full%20line%20of%20lcd%20monitors_L1933TR-SF.jhtml
Comment 33•16 years ago
|
||
LG is not correctly adapting their primaries. I'd have to do more investigating than I have time for but it appears they may have correctly adapted the red and green primaries but the blue is definitely just wrong (either incorrect original primary value or incorrect adaptation).
Yes it really shouldn't be this difficult, but the spec has been around for quite a while, so they should follow it.
Comment 34•16 years ago
|
||
(In reply to comment #33)
> LG is not correctly adapting their primaries.
Any chance to find a workaround instead of just disabling their profiles?
I think that there are many monitors of this vendor with this kind of ICC profiles around.
Comment 35•16 years ago
|
||
(In reply to comment #34)
> (In reply to comment #33)
> > LG is not correctly adapting their primaries.
>
> Any chance to find a workaround instead of just disabling their profiles?
Maybe.
1. Canned profiles contain questionable primaries anyway. The primaries in the profile may contain the design goal for the display, but not actual manufacturing. It probably doesn't take manufacturing variation into account because the profile applies to the entire display model.
2. If the canned profile is a matrix only profile (rXYZ, gXYZ, bXYZ). In the current examples this is the case. Then..,
3. If the addition of rgb XYZ results in the same value as the wtpt tag XYZ; and
4. If the wtpt XYZ is not D50; then
5. We can surmise the primaries are not D50 adapted and it's a "simple" matter of running them through the Bradford chromatic adaptation algorithm, which you can find here:
http://www.brucelindbloom.com/index.html?Eqn_ChromAdapt.html
Comment 36•16 years ago
|
||
(In reply to comment #34)
> I think that there are many monitors of this vendor with this kind of ICC
> profiles around.
Honestly I think it's better to potty train developers than changing their dirty diapers for them all the time. It would take a comparatively short amount of time for them to fix this and reissue new profiles on their web site (as in, a day for all of them), rather than asking for non-trivial development time to fix their mess on-the-fly.
If anyone has LG contacts to forward, I'll take up the conversation with them.
Comment 37•16 years ago
|
||
Anyone in this bug who's been seeing bad colors -
I've got some promising code over in bug 460629 that should automatically detect bad profiles and use sRGB as the output profile instead.
I've got some builds with this patch posted here: https://build.mozilla.org/tryserver-builds/2008-10-29_19:33-bobbyholley@stanford.edu-bholleycmsdetectbogus3/
If you could all go give those builds a try, that would be great. If you run them from the console, they should spit out a printf about a Bogus Profile if it decides the output profile is bad.
Comment 38•16 years ago
|
||
I've tweaked some of the thresholds a bit, and generated builds. Unfortunately, the win32 builder is down, so right now there's only mac and linux for these ones. If you're on win32, just use the ones in the link I posted above.
https://build.mozilla.org/tryserver-builds/2008-11-02_14:20-bobbyholley@stanford.edu-bholleycmsdetectbogus4/
Comment 39•16 years ago
|
||
> If you could all go give those builds a try, that would be great.
Bobby, thanks for creating those test builds.
I'm seeing this bug on Vista with 3.1b1, and when I ran your test build I did not see the bug.
When I ran from the console:
$ ./firefox.exe
Output color profile looks bogus. Using sRGB...
hope this helps.
Comment 40•16 years ago
|
||
(In reply to comment #39)
> I'm seeing this bug on Vista with 3.1b1, and when I ran your test build I did
> not see the bug.
FWIW, it's not actually a FF bug, but an improperly built display profile. If anyone is so inclined, they could forward this bug report onto LG, and any other producer of a display profile that triggers this new FF behavior (and console warning).
Comment 41•16 years ago
|
||
(In reply to comment #37)
Sorry for the delay, windows build works fine.
It detects correctly the bogus ICC color profile and disable it.
Thank you for the workaround.
Component: GFX: Thebes → GFX: Color Management
QA Contact: general → color-management
Comment 42•16 years ago
|
||
This should be fixed in the 3.2 nightlies already, and in the 3.1 nightlies once they roll tonight. Can someone confirm that this is the case? If so, I'll close this bug.
Comment 43•16 years ago
|
||
Confirmed.
duping to bug 460629 "system Display profile should be ignored/modified if R+G+B does not equal white"
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
Comment 44•13 years ago
|
||
A question for Chris:
I have a Argyll generated profile that stumbles on qcms_profile_is_bogus() when the tolerances are checked. The rendering intent for this profile is relative colorimetric (if that makes any difference) and it was generated by Argyll using a correction matrix to correct for a specific wide gamut display.
My question is if a target whitepoint other than D65, or anything else, might change the expected r, g and b sums to something away from the expected 0.965, 1.000 and 0.825 values?
BTW, the tolerances are not much off from those accepted by the bogus checker.
Thanks for any clarification!
Comment 45•13 years ago
|
||
The RGB XYZs should be chromatically adapted to D50 in any event, regardless of the actual white point of the display. If you don't have a way to inspect this display profile to find out what the RGB XYZ values are, attach it and I'll take a look at it.
Comment 46•13 years ago
|
||
I attached the ICM (Argyll generated..)
I printed the following from gdb as well:
(gdb) p *gCMSOutputProfile
$23 = {class = 1835955314, color_space = 1380401696, rendering_intent = QCMS_INTENT_RELATIVE_COLORIMETRIC,
redColorant = {X = 39642, Y = 20661, Z = 544}, blueColorant = {X = 11094, Y = 5390, Z = 50937},
greenColorant = {X = 14016, Y = 40295, Z = 4708}, redTRC = 0x7fffdfa8a000, blueTRC = 0x7fffdfa8a400,
greenTRC = 0x7fffdfa8a800, grayTRC = 0x0, A2B0 = 0x0, output_table_r = 0x0, output_table_g = 0x0,
output_table_b = 0x0}
(gdb)
Comment 47•13 years ago
|
||
I'm going to guess that the bogus profile check is only checking the XYZs of the RGB tags, and not computing actual XYZ of the RGB's based on both the matrix as well as the TRC. The TRC in the display profile doesn't go all the way up to 100%.
So I think you'll have to file a separate bug against "bogus profile detection" for component GFX: color management so it can be investigated.
Comment 48•13 years ago
|
||
I think you are right, I don't see any reference to the TRC values in the source for the bogus checker. I'll file that bug report. I don't really have a good understanding of the profile parameters yet, so I'll refer to this bug report and your expertise, if I may.
Comment 49•13 years ago
|
||
Yeah definitely cc me, although I'm not a dev, I think I have the permissions necessary to update the bug to assign it to the GFX:Color Management component if you can't. I'd basically write the bug report something like "CMS bogus profile detection flaw" and then how to reproduce you can include the details of your display, what was used to make the display profile (Argyll) and version, and what you expect to happen (that the profile is not bogus and gets used) but what happens instead is that it's flagged as bogus when it's not. And then attach the example profile there. And then I can point out that the profile reported white point is actually correct when the TRCs are taken into account and suggest how this can be fixed.
Comment 50•13 years ago
|
||
Graeme Gill, the developer of Argyll, informs me that you should update your version of Argyll as the current shaper/matrix profiles all have TRCs that go through 1.0. That means the RGB XYZs should pass, rather than fail, the current Firefox bogus profile detection.
Comment 51•13 years ago
|
||
I'm using Argyll 1.3.3 (which is the only version I have had) and seems to be the latest (May 2011). Perhaps it's a bug due to using dispcal with the -X option to specify a correction matrix.
Comment 52•13 years ago
|
||
I contacted Graeme Gill as well to see if it can be established if Argyll or Firefox is at fault, before filing any new FF bug report.
Comment 53•13 years ago
|
||
Here is the new bug report:
https://bugzilla.mozilla.org/show_bug.cgi?id=663212
You need to log in
before you can comment on or make changes to this bug.
Description
•