9 Replies Latest reply on Aug 1, 2014 9:03 AM by Noel Carboni

    OpenGL inaccuracies and black levels

    D Fosse Adobe Community Professional & MVP

      Here is an sRGB file consisting of 0,0,0 background, with five overlaid squares at one level increments, from 1 to 5.

       

      On my Eizo CG246, calibrated with Eizo ColorNavigator, all five squares are discernible against the black background, as long as Graphics Processor > Advanced is set to "Basic" mode. This means that the color management logic (the conversion to the display profile) is performed in the CPU.

       

      In "Normal" and "Advanced" modes, color management is shifted to the GPU. With these settings, black levels disappear. It's not dramatic, but it's there. The difference can be illustrated in a screenshot, as long as the display profile is assigned and the screenshot is pasted in the Basic mode. Here's how it looks straight up (should be viewed against a dark background):

      black_crush_straight.png

       

      Here I put a Curves layer on top to exaggerate:

      black_crush_curves.png

       

      And here I read out the numbers from this exaggerated version:

      black_crush_numbers.png

       

      So far it seems this can not be reproduced on another monitor I have, an NEC P232W calibrated with Spectraview II. It also seemed a bit more pronounced on a different Eizo I no longer use, an S2243W, calibrated with Eizo EasyPix.

       

      This suggests that the problem is in the interaction between the display profile and the Open GL engine that does the conversion. I think this is related to the ProPhoto cyan banding issue previously reported, because that also seems to behave differently between these two systems (I'll do some more testing on that).

       

      In all cases and all scenarios, all irregularities disappear with Open GL in the "Basic" setting.



        • 1. Re: OpenGL inaccuracies and black levels
          Noel Carboni Level 8

          You neglected to include your test image with black and levels (1,1,1) through (5,5,5), but no matter, I have the one I made...

           

          http://Noel.ProDigitalSoftware.com/ForumPosts/DarkGrayColorLevels16Bit.png

           

          I've found that here I'm not seeing a visible difference between GPU and CPU color-management with the image in the sRGB color space.  In other words, no crush.  With the image in the ProPhoto RGB color space, some slight crush was apparent, along with color shifts almost exclusively toward red.

           

          However, that's not to say there are no differences between the two.  They're just more subtle than what you're seeing.  What I did to test was this:

           

          • Open the image I linked to above using Advanced mode OpenGL.
          • Float it in a window.
          • Screen grab it.
          • Pick it up and start to drag it.
          • While still dragging, screen grab it again.
          • Overlay the two images, and pixel align them.
          • Set the top image to "Difference" blending.
          • Add a couple of Curves layers over the top to greatly enhance the differences to make them more visible.

           

          Since my test image has a dark grayscale gradient expressed in 16 bits/channel, it's not only testing for accuracy at the visible level, but also for very subtle changes.  Lo and behold, changes are revealed.  Note:

           

          Enhanced differences between GPU and CPU rendering of the image in the sRGB color space:

           

          sRGBDifferences.png

           

          Assigning the ProPhoto RGB color space to my test image, then comparing GPU vs. CPU rendering...

           

          ProPhotoDifferences.png

           

          -Noel

          • 2. Re: OpenGL inaccuracies and black levels
            Noel Carboni Level 8

            Notably, this is what the ProPhoto image looks like with extreme enhancement (i.e., the image as rendered by the GPU and CPU, just made brighter).  Note that there are visible errors with both types of color-management.  This is with an sRGB IEC61966-2.1 monitor profile.

             

            GPU rendering:

            ProPhotoGPURendering.png

             

             

            CPU rendering:

            ProPhotoCPURendering.png

             

            -Noel

            • 3. Re: OpenGL inaccuracies and black levels
              D Fosse Adobe Community Professional & MVP

              Yep, and we have a smoking gun: Both your gradient and my black levels show a marked anomaly in the red channel vs. the green and blue. Note my numbers above. I'm convinced these two are different expressions of the same underlying problem. BTW my original screenshot was 16 bit before applying the curve, so there shouldn't be rounding errors.

               

              The fact that it's more pronounced in ProPhoto is no surprise, given the compression, particularly in the shadows, in such an extremely large color space (and gamma 1.8 encoded at that).

               

              Why the differences between different display profiles (including sRGB) I have no clue. There are problems in them all, but they take different forms. I need to take an even closer look at the NEC Spectraview system later today. Yesterday I found highly irregular ProPhoto banding, but no cyan. The black levels I need to recheck, because that monitor is currently calibrated to a fairly high black point which may mask it.

               

              Just to be clear, for the benefit of others reading this, it should be emphasized that monitor calibration is out of the equation here (it can cause banding in its own right). These units are all calibrated directly to the monitor hardware and both the video card and the color management system are wholly unaware of it. The profiles contain no gamma table tags. This issue is strictly in the profile conversion/transform, as performed by the CPU vs. the GPU.

              • 4. Re: OpenGL inaccuracies and black levels
                Noel Carboni Level 8

                An additional piece of information...  I use a color-management system in my own software called LittleCMS, and its implementation yields a clean result when color-managing the 16 bit ProPhoto RGB document to an sRGB screen.  This says that there's no inherent problem with the profiles that gives rise to the Photoshop inaccuracy.

                 

                Consider this enhanced screen grab, and compare it to those above captured from Photoshop's preview window...

                 

                ProDigitalColorManagement.png

                 

                Edit:  I wonder if Photoshop's oddball 15 bit + 1 level internal implementation of 16 bits/channel data could have something to do with this.  Notably internally I convert to a true 16 bit format (a full 65536 levels from Photoshop's 32769 levels) when my plug-ins receive a 16 bits/channel image from Photoshop.

                 

                Perhaps the solution is for Adobe to start doing Photoshop's internal math in 32 bit floating point (even 16 bit half float would be an improvement I suspect).  But even then there can be issues with rounding vs. truncation when converting to/from integer formats.  Been there, done that.

                 

                -Noel

                • 5. Re: OpenGL inaccuracies and black levels
                  D Fosse Adobe Community Professional & MVP

                  Confirming my observations on the NEC from yesterday. No cyan banding, but general irregular banding. And there's just no way I can see any black clipping. Nada.

                   

                  But watch...

                   

                  Just for kicks, I set sRGB as display profile and opened the ProPhoto test gradient. Bam:

                  test grad.png

                   

                  And here we all thought sRGB was a safe display profile...    This is clearly the worst of all the three. The Eizo profile shows a little cyan banding, but nowhere near as bad as this. Christ. What's going on here...?

                   

                  And now of course I had to try to reproduce the black clipping. But it was no go, still no clipping. So far the clipping appears to be specific to the Eizo profile.

                   

                  I confess I don't know much about how profiles are built, mathematically speaking. What I do know is that Eizo ColorNavigator makes LUT profiles and NEC Spectraview matrix. What the implications are in this case I don't know.

                   

                  Here's with the Spectraview profile for comparison:

                  test_grad_NEC.png

                  • 6. Re: OpenGL inaccuracies and black levels
                    Noel Carboni Level 8

                    Chris Cox, if you happen to see this thread...  Have you ever looked further into why there's some visible inaccuracy in color-managing documents in the ProPhoto RGB profile?

                     

                    -Noel

                    • 7. Re: OpenGL inaccuracies and black levels
                      Noel Carboni Level 8

                      I wonder if someone, during design, might have thought that, for colors other than pure gray gradients (which don't occur much in real photos), using R, G, and B values where just one of the colors is slightly more or less than the others could emulate brightness levels in between actually displayable brightness levels.  In other words, "it's not a bug, it's a feature"?

                       

                      This, of course, would make more sense if things like the ProPhoto RGB rendering looked smoother than a pure grayscale gradient, but unfortunately it doesn't, really.

                       

                      I've got to find a way to get my setup to present true 30 bit color.  Seems like all the parts should be capable, but something's still missing.  Maybe a special driver.

                       

                      -Noel

                      • 8. Re: OpenGL inaccuracies and black levels
                        D Fosse Adobe Community Professional & MVP

                        Noel Carboni wrote:

                         

                        I wonder if someone, during design, might have thought that, for colors other than pure gray gradients (which don't occur much in real photos), using R, G, and B values where just one of the colors is slightly more or less than the others could emulate brightness levels in between actually displayable brightness levels.  In other words, "it's not a bug, it's a feature"?

                        IOW the ClearType of graphics?

                         

                        The first time I noticed this was in real photographs, not gradients, and precisely in the form of a strange cyan cast in the shadows. My instinct was the monitor calibration or profile at first, until I noticed to my relief that turning OpenGL off cleared it. Then I wrote it off as a bad video driver and thought nothing more of it until Noel demonstrated that it was a universal bug.

                         

                        This was way back with CS4, when it was all pretty new and all you could do was turn it off or on. So if this is a feature, that certainly didn't work for me.

                         

                        My work system should be 10 bit capable with a better video card, but I haven't made that a priority yet. In light of this, though, it would be interesting to see how that behaved.

                        • 9. Re: OpenGL inaccuracies and black levels
                          Noel Carboni Level 8

                          Oh, and I noticed (again) one other thing today while experimenting with monitor profile changes.  I've seen this before but forgotten about it...

                           

                          If you grab a windowed document and move it, while dragging it appears to be color-managed not only by CPU-based color-management logic, but to the PRIMARY monitor's color profile, whether or not you're moving it to or from an alternate monitor!

                           

                          -Noel