7 Replies Latest reply on Jan 30, 2015 12:43 PM by WarGawd

    Suspected Flaw in Firefox 35 Color Management Behavior


      I hope I can keep this concise, but bear with me if my confusion causes me to include some extraneous info. The info below is what I think is required for someone else to fully understand the issue.



      - NECPA271W wide gamut monitor in dual monitor setup with a standard gamut Samsung 245BW

      - Windows 8.1 Pro 64-bit

      - Nvidia Quadro K4000

      - Latest versions of FireFox (v35 32-bit), IE11 (11.0.9600.17498 updated to 11.0.15 32-bit) & Avant (Ultimate 2015 build 7, in use for testing because it incorporates the rendering engines of 3 major browsers, IE v 11.0.9600.17496, FireFox v 34.05.5464, & Chrome v39.0.2172.95)

      - i1Display Pro (not the NEC SVSensor version), SpectraView II, NEC Multiprofiler & i1 Profiler

      - Both monitors are calibrated and profiled. The NEC is calibrated using SVII, but since that software only supports NEC monitors, the 245BW has to be done using i1Profiler software that comes with the i1Display Pro. SVII is only capable of generating v2 ICC profiles, i1 Profiler is capable of v2 & v4, and recommends v4. Nevertheless, I think this entire bullet point is irrelevant to the effect I'm observing.

      - I've lately started selling some of my photography on a fine art website.  As a result I started digging deeper into how those images are viewed by others & subsequently printed. Images optimized in sRGB for the best possible display results across a widely varied viewer base are not going to give the same results as images that are soft-proofed and optimized for specific media/printer/ink combinations. This is especially true of my images which tend to lean in the direction of being more heavily saturated & wider gamut

      - I've been exhaustively over the info here COLOR MANAGEMENT PHOTOSHOP CC CS6 Basic ColorManagement Theory ICC Profiles Color Spaces Calibrated Monitor Professional… & here http://cameratico.com/tools/web-browser-color-management-test/  among many others.


      I had reached a point where I thought I understood things pretty well, but now I'm not so sure again Here's the problem:

      I followed the guidance and info on how to set FireFox for FULL color management  (value 1 with associated monitor profile) that allows the handling of non-tagged images and web page elements, http://cameratico.com/guides/firefox-color-management/. Upon restarting Firefox with the updated configuration, I return to the test at http://cameratico.com/tools/web-browser-color-management-test/  The last two tests there are designed to show a) how much wider your display gamut is than sRGB, and b) how the browser handles untagged images and elements.


      The behavior I observe is different from the behavior I expect! Specifically, setting FIrefox to color management value 1 and telling it my monitor profile causes Firefox to display the sRGB tagged images as if they were not tagged. With the default value 2/no monitor profile, I can see a difference between the display of sRGB tagged images and either the ProPhoto RGB tagged image or the untagged sRBG & untagged CSS elements. I would expect that the change to value 1 with monitor profile should have no impact on the display of tagged images and elements, and yet that switch ONLY causes a  change in the display behavior of the tagged images it shouldn't have affected, and I can no longer see a difference between the various images because everything is fully saturated


      A marked up screen capture showing the comparative behaviors between the various applications and browsers would probably be worth more than the proverbial 1000 words, I'm new here & haven't figured that part out yet, but will post this as is while I work on that.


      Can anybody replicate the behavior I observe? Is anybody spotting an error in my thinking?





      *EDIT - I have annotated a screen shot comparing the results across 4 browsers. The screenshot has an embedded Adobe RGB profile which best represents the effects & changes that I was/am seeing but may not be preserved if posted here. It may be best to download and view in CS6 so as to not introduce any additional confusion arising from which browser YOU may be using :-) If needed the full res 2560x1440 version is available, but scaling to meet the forum limits of 900x900 makes the text unreadable. Can anyone suggest a means of supplying the full res file with the embedded profile retained?

        • 1. Re: Suspected Flaw in Firefox 35 Color Management Behavior
          D Fosse Adobe Community Professional & MVP

          Using Firefox 35.0 and a wide gamut Eizo CG246, I don't see any problems in the browser CM test (I had to desaturate the gamut test for it to survive the sRGB conversion, but still the green isn't entirely within sRGB. But it's just an illustration anyway):




          So. A couple of things right off the bat:


          Firefox will use the profile for the main display. It does not support a dual monitor setup. If you move FF to the secondary display, it will still use the primary display's profile.


          You don't need to tell Firefox what your display profile is. In fact you probably shouldn't to avoid problems. Just like any other color managed application, Firefox picks up the profile set as system default at startup. No user intervention required. If you change the system default, Firefox needs to be relaunched to load the new profile.


          This is true for both mode 1 and mode 2. They both use the display profile, but mode 1 assigns sRGB to any untagged material. Mode 2 just passes untagged straight through unmanaged. The point of mode 1 is to display untagged material correctly even on a wide gamut display (not oversaturated). Tagged material will be correctly managed in both modes. Mode 0 is the one that is totally un-managed and does not use the display profile.




          All that said, I've noticed that Firefox has some small problems with LUT display profiles. It's nothing immediately noticeable, but on closer inspection the blacks are clipped somewhat. With matrix profiles this clipping doesn't occur, and FF displays absolutely identically to Photoshop. I've not noticed any problems with v4 vs. v2, although v4 support has to be manually enabled.

          • 2. Re: Suspected Flaw in Firefox 35 Color Management Behavior
            WarGawd Level 1

            Thanx twenty_one.


            Actually as you were responding to this here, I was reading another discussion in the Photoshop forum that gave me the idea NOT to associate the monitor profile when setting value 1. I just finished testing it and can confirm the behavior IS different and seems consistent with what I had expected at the outset. It seems counterintuitive to me that overtly telling FF35 to use a profile that it's already expected to be using should give rise to any behavioral changes.


            I guess the Firefox configuration advice at cameartico.com may have been rendered outdated by subsequent updates to FF since his last update of the page May 2013.


            As for dual monitor behavior, it was so close that I initially couldn't tell what was happening for sure. But then I recreated the ProPhoto vs sRGB gamut test in CS6, duplicated the image, and compared CS6 to browser on each monitor. On the wide gamut NEC, it's a direct match. On the standard gamut monitor the difference becomes apparent, except while dragging the  CS6 window around on screen, which makes CS6 and the Firefox match perfectly! That's kinda odd/unexpected but not highly important as far as I can see.


            So, the summary is: setting FF35 gfx.color_management.mode to value 1 color management without setting gfx.color_management.display_profile to match the monitor profile results in the proper/expected color management of untagged images and elements.


            So I think I'm back to understanding almost everything but could use some clarification on something. i1Profiler offers a choice between table based & matrix based profiles and defaults to matrix. My understanding of the NEC Spectraview FAQ SpectraViewII Software FAQs | NEC Display is that SVII creates matrix based profiles. I had the mistaken impression that the difference between v2 and v4 was equivalent to the difference between table and matrix, but looking back at i1Profiler, I see that I can create each type with each version (v2 table or matrix, v4 table or matrix). So I'm not clear on the distinctions, nor do I have a good sense whether I need to know. Feedback?


            Thx again


            • 3. Re: Suspected Flaw in Firefox 35 Color Management Behavior
              D Fosse Adobe Community Professional & MVP

              That's correct. Table-based (LUT means look-up table) and matrix-based are different ways to build the profile. The general consensus seems to be that LUT is more accurate, but matrix simpler and more reliable. Several applications are reported to have problems with LUT profiles, including Lightroom. Personally I have only seen problems with Firefox (and only minor at that), nowhere else.


              v2 and v4 are different versions of the profile format specification from the International Color Consortium (icc), irrespective of the algorithm used to build the profile. Version 4 was published in 2010, but still not widely implemented, so generally it is recommended to stick with v2.


              So the safest bet seems to be matrix, v2.

              • 4. Re: Suspected Flaw in Firefox 35 Color Management Behavior
                WarGawd Level 1

                Perfect thanx


                That's consistent with what I was gathering from other reading while waiting for comments.


                Marked as answered (not a lot of people seem to do that here?)




                • 5. Re: Suspected Flaw in Firefox 35 Color Management Behavior
                  Todd Shaner Adobe Community Professional & MVP

                  twenty_one wrote:


                  Firefox will use the profile for the main display. It does not support a dual monitor setup. If you move FF to the secondary display, it will still use the primary display's profile.


                  There is a Firefox Add-On called Profile Switcher that allows using multiple monitor profiles. You will need to setup a Firefox user profile for each monitor:




                  After installing Profile Switcher Add-On you will find a new entry in the FF File menu 'Open Profile Manager,' which can be used to create and manage the new user profiles (see screenshots below).


                  You can then setup a Firefox Sync account to keep the user profiles synchronized or do this manually using Copy & Paste. I was concerned that Firefox Sync would over-write the configuration data for the monitor profile, but it doesn't. I leave 'gfx.color_management.display_profile' blank on the user profile for the primary NEC 272W monitor, and add the path for the monitor profile on the user profile for my standard gamut secondary display. Here's what I see when launching FF:



                  After installing the Profile Switcher Add-On you'll see two new entries in the FF File menu that allow you to manage and launch other FF user profiles as separate browser instances.

                  It works fine on my Windows 7 system and should also work on Mac OS X systems and Windows 8.x.

                  • 6. Re: Suspected Flaw in Firefox 35 Color Management Behavior
                    D Fosse Adobe Community Professional & MVP

                    trshaner wrote:


                    There is a Firefox Add-On called Profile Switcher

                    Excellent - that should come in handy for a lot of people. I currently work with a single monitor, but back when I had two I usually had the browser on the second display.

                    • 7. Re: Suspected Flaw in Firefox 35 Color Management Behavior
                      WarGawd Level 1

                      My thanx too - I switch monitors frequently depending on circumstance...looks like this lets me have my cake and eat it too :-)