Re: Gamma correct rendering with Wayland and Weston
On Sun, 30 Sep 2012 08:45:55 -0700 Bill Spitzak spit...@gmail.com wrote: On 09/29/2012 01:28 AM, John Kåre Alsaker wrote: Wayland also does scaling and rotations but the difference between linear and srgb is much smaller for these. I think the real solution for this is to allow clients to know the actual transform of their surfaces to the screen and be allowed to draw the transformed image, since this will avoid resampling and filtering, as well as letting the clients choose the color space. Part of the point of Wayland is that clients shouldn't know about how they are placed or transformed, even if they did, the compositor would still have to compose them and know about the gamma encoding they use. Clients certainly should not *have* to know about the transformation, and the shell will transform for them. However, even thought there is a deliberate attempt to make clients not know it in current Wayland, I think client awareness of the transform is going to be needed eventually. Lots of clients could draw their transformed windows enormously faster and higher quality than then if they drew the non-transformed one and the shell then transformed the image. And you would like to kill all innovative uses like: http://www.youtube.com/watch?v=_FjuPn7MXMs right? And spherical VR displays, too? No, this is not yet the reason to expose transformations to clients. You are only suggesting to make the protocol a huge deal more complex and restrictive, to optimize a tiny detail prematurely, again. On a regular desktop, the transformed case is very rare, and even more rare on cases where the image quality would actually matter that much. - pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Gamma correct rendering with Wayland and Weston
On Sun, 30 Sep 2012 16:10:42 +0200 (CEST) Kai-Uwe Behrmann k...@gmx.de wrote: In reply to John Kåre Alsaker Fri Sep 28 08:52:17 PDT 2012 - srgb: Rendering in linear gamma: If the hardware supports sRGB textures: EGL: Use sRGB textures and present it as linear gamma to shaders. If the hardware doesn't support sRGB textures: Shader: Convert from sRGB to linear gamma. - rgb: Rendering in sRGB gamma: Shader: Convert from linear to sRGB gamma. sRGB textures implies supporting the sRGB colour space on textures. Is such a texture meant to tell the display system to do final colour conversion from sRGB to monitor colour space? Are non sRGB colour spaces still possible like CIE*XYZ or LStar-RGB.icc for sRGB textures? However you write only about gamma. That is confusing. sRGB is defined with colour primaries inside the CIE*XYZ space + gamma encoding, that is what you appear to be referring to, and exact viewing conditions [1]. Gamma is only one part of the sRGB standard. If you realy refere to just gamma, then your functions can not be standard compliant and logical you should avoid sRGB or make clear that you only refere to a subset of that standard. The term sRGB texture would be highly inappropriate for gamma encoding. Gamma, including the sRGB gamma flavor, belongs to a logical layer called gamma correction [2]. On the opposite, colour management needs proper knowledge of the used gamma, in order to work properly. Note, that this proposal does *not* discuss color spaces. It only discusses gamma, as defined for sRGB. The term sRGB is used, because it defines the gamma function, and the same term is used in EGL and GL specifications, where it refers to gamma, not color space in general. You can go and shoot the GL spec writers for that. Color management with proper color space handling and conversions is outside of this proposal, and a subject to different, new protocol. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Gamma correct rendering with Wayland and Weston
Pekka Paalanen wrote: And you would like to kill all innovative uses like: http://www.youtube.com/watch?v=_FjuPn7MXMs right? And spherical VR displays, too? No, this is not yet the reason to expose transformations to clients. You are only suggesting to make the protocol a huge deal more complex and restrictive, to optimize a tiny detail prematurely, again. On a regular desktop, the transformed case is very rare, and even more rare on cases where the image quality would actually matter that much. The clients don't *HAVE* to do the transform. It's just that they *CAN*. And yes transformed images are used a lot, for icons and desktop overviews, and for full-screen. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Gamma correct rendering with Wayland and Weston
In reply to John Kåre Alsaker Fri Sep 28 08:52:17 PDT 2012 - srgb: Rendering in linear gamma: If the hardware supports sRGB textures: EGL: Use sRGB textures and present it as linear gamma to shaders. If the hardware doesn't support sRGB textures: Shader: Convert from sRGB to linear gamma. - rgb: Rendering in sRGB gamma: Shader: Convert from linear to sRGB gamma. sRGB textures implies supporting the sRGB colour space on textures. Is such a texture meant to tell the display system to do final colour conversion from sRGB to monitor colour space? Are non sRGB colour spaces still possible like CIE*XYZ or LStar-RGB.icc for sRGB textures? However you write only about gamma. That is confusing. sRGB is defined with colour primaries inside the CIE*XYZ space + gamma encoding, that is what you appear to be referring to, and exact viewing conditions [1]. Gamma is only one part of the sRGB standard. If you realy refere to just gamma, then your functions can not be standard compliant and logical you should avoid sRGB or make clear that you only refere to a subset of that standard. The term sRGB texture would be highly inappropriate for gamma encoding. Gamma, including the sRGB gamma flavor, belongs to a logical layer called gamma correction [2]. On the opposite, colour management needs proper knowledge of the used gamma, in order to work properly. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org [1] http://en.wikipedia.org/wiki/SRGB [2] http://en.wikipedia.org/wiki/Gamma_correction ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Gamma correct rendering with Wayland and Weston
Can we have a tool like 'xgamma' now? On Sun, Sep 30, 2012 at 4:10 PM, Kai-Uwe Behrmann k...@gmx.de wrote: In reply to John Kåre Alsaker Fri Sep 28 08:52:17 PDT 2012 - srgb: Rendering in linear gamma: If the hardware supports sRGB textures: EGL: Use sRGB textures and present it as linear gamma to shaders. If the hardware doesn't support sRGB textures: Shader: Convert from sRGB to linear gamma. - rgb: Rendering in sRGB gamma: Shader: Convert from linear to sRGB gamma. sRGB textures implies supporting the sRGB colour space on textures. Is such a texture meant to tell the display system to do final colour conversion from sRGB to monitor colour space? Are non sRGB colour spaces still possible like CIE*XYZ or LStar-RGB.icc for sRGB textures? However you write only about gamma. That is confusing. sRGB is defined with colour primaries inside the CIE*XYZ space + gamma encoding, that is what you appear to be referring to, and exact viewing conditions [1]. Gamma is only one part of the sRGB standard. If you realy refere to just gamma, then your functions can not be standard compliant and logical you should avoid sRGB or make clear that you only refere to a subset of that standard. The term sRGB texture would be highly inappropriate for gamma encoding. Gamma, including the sRGB gamma flavor, belongs to a logical layer called gamma correction [2]. On the opposite, colour management needs proper knowledge of the used gamma, in order to work properly. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org [1] http://en.wikipedia.org/wiki/SRGB [2] http://en.wikipedia.org/wiki/Gamma_correction ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Gamma correct rendering with Wayland and Weston
On 09/29/2012 01:28 AM, John Kåre Alsaker wrote: You seemed to have gotten the impression that I suggested we blend each surface in either sRGB or linear depending on it's encoding. That's not what I was suggesting. The compositor won't pick it's blending gamma space per surface. It's either completely linear or sRGB. So all clients with the same alpha values (and colors) will look equal independent of their gamma encoding. We should probably expose the blending gamma space, so clients have a chance to adjust their translucent parts, even if most of them will ignore it. Actually what you say is EXACTLY what I was suggesting. If all the clients have identical-looking shadows, it is because they all wrote the same numerical values to their images in the shadow area. Even if they use different compositing rules for the opaque regions. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Gamma correct rendering with Wayland and Weston
On 09/29/2012 01:28 AM, John Kåre Alsaker wrote: Wayland also does scaling and rotations but the difference between linear and srgb is much smaller for these. I think the real solution for this is to allow clients to know the actual transform of their surfaces to the screen and be allowed to draw the transformed image, since this will avoid resampling and filtering, as well as letting the clients choose the color space. Part of the point of Wayland is that clients shouldn't know about how they are placed or transformed, even if they did, the compositor would still have to compose them and know about the gamma encoding they use. Clients certainly should not *have* to know about the transformation, and the shell will transform for them. However, even thought there is a deliberate attempt to make clients not know it in current Wayland, I think client awareness of the transform is going to be needed eventually. Lots of clients could draw their transformed windows enormously faster and higher quality than then if they drew the non-transformed one and the shell then transformed the image. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Gamma correct rendering with Wayland and Weston
On Fri, Sep 28, 2012 at 10:51 PM, Bill Spitzak spit...@gmail.com wrote: Actual rendering of window contents is not done by Wayland so it should not effect this. However wayland and the shells do some compositing, and gamma changes how any partially-transparent pixels work. In current shells these are: 1. shadows, which are typically drawn by the client as partially-transparent black and composited over the contents of lower windows. 2. semi-transparent objects, such as some of the drag icons. Drawn by the clients as pre-multiplied srgb. 3. The anti-aliased edges of any non-rectangular opaque objects, such as any windows that are not rectangular, the cursor, drag icons. Depending on the application these may be srgb or linear, though the difference is hard to see. Doing compositing in linear space would change the appearance of transparent objects, and in the case of shadows, for example, clients might be interested to know about the compositing space. I don't think legacy clients doing blending in sRGB will care much (they look all wrong anyway), but perhaps clients doing blending in linear space will care when the compositor is blending in sRGB. Wayland also does scaling and rotations but the difference between linear and srgb is much smaller for these. I think the real solution for this is to allow clients to know the actual transform of their surfaces to the screen and be allowed to draw the transformed image, since this will avoid resampling and filtering, as well as letting the clients choose the color space. Part of the point of Wayland is that clients shouldn't know about how they are placed or transformed, even if they did, the compositor would still have to compose them and know about the gamma encoding they use. I suspect that if there are two windows and one is linear and another is srgb, that it will be impossible to make the shadows of these two windows look identical, even if the shadows are drawn in different colors and opacity. It may work for black, but not for any color shadows, and it certainly will not work for semi-transparent objects. If two windows have different encodings, they unlikely to be using the same toolkit and will look completely different anyway. Therefore I feel that wayland shells should use the same compositing rules for all windows, so it is possible for them to all match. The client is free to use linear compositing into a window but this will not change how wayland composites that window with otehrs. When drawing the shadow it just has to draw whatever will produce the correct srgb values in the buffer. In the future wayland may do linear compositing. But this will change for all windows at once. The appearance library that should be used to draw all the widgets and shadows will be aware of this and alter how it draws them. You seemed to have gotten the impression that I suggested we blend each surface in either sRGB or linear depending on it's encoding. That's not what I was suggesting. The compositor won't pick it's blending gamma space per surface. It's either completely linear or sRGB. So all clients with the same alpha values (and colors) will look equal independent of their gamma encoding. We should probably expose the blending gamma space, so clients have a chance to adjust their translucent parts, even if most of them will ignore it. John Kåre Alsaker wrote: Currently most applications are blissfully unaware of the concept of gamma which affects pretty much all rendering operations. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Gamma correct rendering with Wayland and Weston
On Fri, Sep 28, 2012 at 5:52 PM, John Kåre Alsaker john.kare.alsa...@gmail.com wrote: - srgb_a: Rendering in linear gamma: Shader: Undo the alpha premultiplying, convert from sRGB to linear gamma and premultiply the alpha after. When rendering srgb_a in linear gamma, we can use sRGB hardware texture support for opaque regions. This means that the EGL interface needs some changes and that Weston needs to be able to toggle the sRGB decoding. I see to options for doing this, and I think I'm favoring the first one: - Give Weston two EGL images, one which decodes sRGB, one which doesn't. A new attribute for eglCreateImageKHR could be added for this. This would also allow EGL to expose the encodings more directly to Weston and let it pick when to use hardware sRGB decoding and EGL wouldn't need to know about blending space of Weston. - Use the existing GL_EXT_texture_sRGB_decode extension. When the hardware supports sRGB decoding it would return EGL_TEXTURE_RGB_A_WL instead of EGL_TEXTURE_SRGB_A_WL. - srgba: This encoding requires hardware support for sRGB textures. EGL: Use hardware sRGB textures and present it as linear gamma to shaders. Rendering in sRGB gamma: Shader: Convert from linear to sRGB gamma. The shader conversion here would actually be the same as with the rgba encoding. - rgba: Rendering in sRGB gamma: Shader: Undo the alpha premultiplying, convert from linear to sRGB gamma and premultiply the alpha after. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Gamma correct rendering with Wayland and Weston
Actual rendering of window contents is not done by Wayland so it should not effect this. However wayland and the shells do some compositing, and gamma changes how any partially-transparent pixels work. In current shells these are: 1. shadows, which are typically drawn by the client as partially-transparent black and composited over the contents of lower windows. 2. semi-transparent objects, such as some of the drag icons. Drawn by the clients as pre-multiplied srgb. 3. The anti-aliased edges of any non-rectangular opaque objects, such as any windows that are not rectangular, the cursor, drag icons. Depending on the application these may be srgb or linear, though the difference is hard to see. Wayland also does scaling and rotations but the difference between linear and srgb is much smaller for these. I think the real solution for this is to allow clients to know the actual transform of their surfaces to the screen and be allowed to draw the transformed image, since this will avoid resampling and filtering, as well as letting the clients choose the color space. I suspect that if there are two windows and one is linear and another is srgb, that it will be impossible to make the shadows of these two windows look identical, even if the shadows are drawn in different colors and opacity. It may work for black, but not for any color shadows, and it certainly will not work for semi-transparent objects. Therefore I feel that wayland shells should use the same compositing rules for all windows, so it is possible for them to all match. The client is free to use linear compositing into a window but this will not change how wayland composites that window with otehrs. When drawing the shadow it just has to draw whatever will produce the correct srgb values in the buffer. In the future wayland may do linear compositing. But this will change for all windows at once. The appearance library that should be used to draw all the widgets and shadows will be aware of this and alter how it draws them. John Kåre Alsaker wrote: Currently most applications are blissfully unaware of the concept of gamma which affects pretty much all rendering operations. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
