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)

Product:
Core
Component:
Graphics: Color Management
Platform:
x86
Windows Vista
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 460629

People

(Reporter: 14kgary, Assigned: glennrp+bmo)

References

(Blocks 1 open bug,
URL
)

Details

Attachments

(5 files)

icc profile for lg m1917A monitor
616 bytes, application/octet-stream
Details
screenshot of part of comment #11
42.75 KB, image/jpeg
Details
display profile for testing
2.93 KB, application/octet-stream
Details
here's my L1933TR.ICM file, which is the default monitor profile
616 bytes, application/octet-stream
Details
Argyll generated display profile for Dell U2410 (with corr matrix)
3.61 KB, application/octet-stream
Details 
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.
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.
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?
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/
(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.
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.
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\\
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.
Component: General → GFX: Thebes
Product: Firefox → Core
Version: unspecified → Trunk
Blocks: 455077
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)
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.
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.
Still need the last two items.
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

    
    

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

    
    

    
  
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.

    
    

    
  
(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 ?

    
    

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

    
    

    
  


  
Attachment is an ICC profile for an NEC2180WG with a D65 white point, and corresponding wtpt tag (wtpt tag is NOT D50).

    
    

    
  
(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)?

    
    

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

    
    

    
  
(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?

    
    

    
  
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.

    
    

    
  
Bug 460629 submitted. Needs to be assigned to the proper component and to Bobby (I'm unable to do this).

    
    

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

    
    

    
  


  
> 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

    
    

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

    
    

    
  
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.

    
    

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

    
    

    
  
(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

    
    

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

    
    

    
  
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.

    
    

    
  
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/

    
    

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

    
    

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

    
    

    
  
(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

    
    

    
  
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.

    
    

    
  
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

    
    

    
  
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!

    
    

    
  
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.

    
    

    
  


  
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)

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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.

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: