4 Replies Latest reply: Mar 18, 2014 6:14 PM by tozzy RSS

    Strange sRGB soft-proofing behavior

    tozzy

      I am wondering if the CMS gurus might have an idea about this:

       

      I am using Photoshop CC, but had a similar experience with the previous version and on a different machine.

       

      I have a wide gamut NEC monitor which has been profiled using i1 Display. The generated profile is selected in Windows as default profile. Everything seems OK with this side of things.

       

      So I have a bitmap file with sRGB embedded profile, and my working space is sRGB.  Colour appears correct in 'normal' editing view, i.e. PS is already adjusting what it is sending to the monitor based on the fact that it is an sRGB image. To confirm, I can look at the same graphic in Firefox with CMS switched on, and it looks the same as in Photoshop. And it looks "correct". Furthermore, if I soft-proof to "Monitor", what I see makes sense too. (Overly vibrant colours). And that's also visually consistent with looking at it in Firefox with CMS switched off.

       

      So far so good. The fun begins when I ask PS to softproof the image to sRGB.  Now, you might ask what would be the point of that, since in theory I'm already looking at it being rendered into sRGB colour space. Regardless, what I expect to happen is that soft-proofing to sRGB makes absolutely no difference to what I see. However this is not the case! The on-screen representation changes markedly... not only is it overly saturated but there is a colour shift as well!  To make matters more confusing, when I use the Info box to show the raw and the softproof colour values, they are identical, as they should be. So the numbers seem OK, but the on-screen rendering is clearly wrong.

       

      I also see a similar effect if I do a "convert to profile sRGB" with preview switched on. Up until I hit the OK button, the preview rendering is "wrong". Once the conversion completes (which did nothing because it was already in sRGB space) it renders as it did before.

       

      I'm wondering if this is some kind of weird bug that happens when you softproof to the space you're already in?

       

      MT

        • 1. Re: Strange sRGB soft-proofing behavior
          twenty_one Community Member

          You're right, this doesn't make sense. I suspect there is a bug hidden somewhere in all this, because similar erratic behavior has been reported in other cases. The preview thing I've seen myself.

           

          It doesn't have to be the Photoshop code. Since this affects display, it could be video driver / OpenGL. I haven't checked if this still happens with Open GL basic or off (where display color management is shifted back from the GPU to the CPU).

          • 2. Re: Strange sRGB soft-proofing behavior
            tozzy Community Member

            Yes you're right. I had my suspicions that had something to do with OpenGL.  I turned the preference setting back to Basic and the "problem" went away. i think this needs to be fixed... it's very confusing behavior and leads you to wonder if there are other times when the on-screen CMS rendering behavior can't be trusted. Is it a bug in Photoshop, OpenGL, or the video drivers though? I think we need to let Adobe figure that out. How to report this as a bug?

            • 3. Re: Strange sRGB soft-proofing behavior
              Noel Carboni Community Member

              tozzy wrote:


              it's very confusing behavior and leads you to wonder if there are other times when the on-screen CMS rendering behavior can't be trusted.

               

              In my observation there are two forms of color-management implementation, both controlled by Adobe:  The first is the traditional Adobe Color Engine as executed by the CPU - this is run if you have the [ ] Enable Graphics Processor setting unchecked or have it checked but are using Basic drawing mode in the Advanced Settings section.  Phtotoshop also reverts to this CPU-resident color-management while you are moving a window and when you're using View - Gamut Warning.

               

              The second form is executed by the GPU and is used when in Normal and Advanced drawing modes.  This GPU implementation is presumably faster, but is also observably inaccurate under certain specific conditions.  For example, if your document is in the ProPhoto RGB color space, it will show subtle color banding in a pure gray gradient.

               

              The GPU-resident color management transforms have also been seen to add multi-value output level jumps, resulting in visible banding, in high bit depth gray gradients, where the CPU-resident code does not.

               

              I reported these inaccuracies to Adobe some time ago, but either the GPU-resident color-management code is inscrutable or they just have other priorities, because the inaccuracies remain.

               

              I just brought all this up, tozzy, since you mention the problem going away when the CPU-resident color-management code is invoked.  To retain GPU acceleration for other things, but use CPU color-management, try using Basic drawing mode if you're concerned about getting the most accurate displays from color-management.  Remember that you have to close and restart Photoshop after making changes in these settings.

               

              -Noel

              • 4. Re: Strange sRGB soft-proofing behavior
                tozzy Community Member

                Thanks Noel - yes as per my previous post, dropping back to Basic fixed the problem. I'm going to leave it on that. I've got enough grunt in the cpu that I don't think I'm going to notice too much of a performance difference.  toz