Announcement

Collapse
No announcement yet.

XWayland GLX Path Enables sRGB Support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • XWayland GLX Path Enables sRGB Support

    Phoronix: XWayland GLX Path Enables sRGB Support

    Another item is now crossed off the XWayland TODO list with OpenGL sRGB support wired up...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    What does it mean? Color correction for games maybe? Am I asking too much? Gaming on super wide gamut displays is a terrible experience.
    ## VGA ##
    AMD: X1950XTX, HD3870, HD5870
    Intel: GMA45, HD3000 (Core i5 2500K)

    Comment


    • #3
      It means what it says. It now supports the sRGB color gamut which has been a very common SDR color gamut on computers for years. And it doesn't mean color correction for games so much as it means correct color for all software that requires it.

      Comment


      • #4
        It now supports the sRGB color gamut
        And what the hell does it mean? Having a color space means color correction to me, otherwise what's the advantage compared to raw pixel mapping?
        ## VGA ##
        AMD: X1950XTX, HD3870, HD5870
        Intel: GMA45, HD3000 (Core i5 2500K)

        Comment


        • #5
          Originally posted by Myownfriend View Post
          It means what it says. It now supports the sRGB color gamut which has been a very common SDR color gamut on computers for years. And it doesn't mean color correction for games so much as it means correct color for all software that requires it.
          GL_FRAMEBUFFER_SRGB is only one part that can be used for color correction, the only thing it does is tell the openGL driver that the either the input buffer or output buffer is in sRGB so it can do a correct blend in linear space. (See documentation here https://www.khronos.org/opengl/wiki/...fer#Colorspace note that the linear space in this case is still only the sRGB gamut!) This is very useful (correct blending in linear space) but not sufficient for correct color (most consumer monitors are far from 100% sRGB and even many professional monitors can benefit from profiling, and then we have monitors that have a wider gamut)

          Comment


          • #6
            Originally posted by Deetwenty View Post

            GL_FRAMEBUFFER_SRGB is only one part that can be used for color correction, the only thing it does is tell the openGL driver that the either the input buffer or output buffer is in sRGB so it can do a correct blend in linear space. (See documentation here https://www.khronos.org/opengl/wiki/...fer#Colorspace note that the linear space in this case is still only the sRGB gamut!) This is very useful (correct blending in linear space) but not sufficient for correct color (most consumer monitors are far from 100% sRGB and even many professional monitors can benefit from profiling, and then we have monitors that have a wider gamut)
            True, but If you know your framebuffers colorspace and have your display's color correction profile, you can perform correct color correction.

            Comment


            • #7
              Originally posted by blacknova View Post

              True, but If you know your framebuffers colorspace and have your display's color correction profile, you can perform correct color correction.
              Although true that misses a couple of things, firstly very slowly things are moving to wider gamut screens even in the consumer market (e.g. all HDR monitors have a wider gamut) in which case just sRGB isn't enough (internal color blending inside to compositor will probably need to be a linear space with e.g. rec.2020 gamut), secondly for many types of applications you want to render directly into monitor space from the application and not have the compositor touch the colors (e.g. desktop publishing that works in CMYK wanting to get reasonable accurate print proof), this will require some way to communicate between compositor and application, so as I said GL_FRAMEBUFFER_SRGB is nice to support but far from sufficient for color management.

              Comment


              • #8
                I still would love to have the possibility to color correct color-unaware applications from the compositor.
                ## VGA ##
                AMD: X1950XTX, HD3870, HD5870
                Intel: GMA45, HD3000 (Core i5 2500K)

                Comment


                • #9
                  Originally posted by darkbasic View Post
                  I still would love to have the possibility to color correct color-unaware applications from the compositor.
                  Let's hope that this will work with the Wayland protocol that's in the making. We can probably forget about this for Xorg. Some vibrance setting on top of the gamut mapping would be nice, as a lot of sRGB content actually looks terribly pale when displayed with correct gamut mapping.

                  Comment


                  • #10
                    Originally posted by Myownfriend View Post
                    the sRGB color gamut which has been a very common SDR color gamut on computers for years.
                    you mean it was common denominator aka the shittiest color gamut supportable by any monitor

                    Comment

                    Working...
                    X