wayland: render SDR gamma22 outputs as piece-wise sRGB [chromium/src : main]
Xaver Hugl (Gerrit)
Xaver Hugl added 1 comment![]( "Open in Gerrit")
This doesn't seem right.
It doesn't matter which transfer function is used on the output (meaning both the Wayland surface and the physical display), sRGB needs to be displayed as gamma 2.2.
With this change, if you use gamma22 as the transfer function, the result would look different than if you used PQ, even though the same picture is shown. That wouldn't even be restricted to sRGB, it would affect all content.
Related details
- Dianda Lin
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Dianda Lin (Gerrit)
Dianda Lin added 1 comment![]( "Open in Gerrit")
This doesn't seem right.
It doesn't matter which transfer function is used on the output (meaning both the Wayland surface and the physical display), sRGB needs to be displayed as gamma 2.2.
With this change, if you use gamma22 as the transfer function, the result would look different than if you used PQ, even though the same picture is shown. That wouldn't even be restricted to sRGB, it would affect all content.
Thanks — you're right, and I'll abandon this change.
To confirm I've followed: the transfer function chosen for a Wayland surface or physical output must not change the rendered appearance, because the compositor converts between those encodings. My change made the result depend on the preferred description. Since that description also feeds Chromium's render and blending configuration on this path, the effect would not be limited to sRGB content.
Before trying again, could you clarify the intended source model? Should ordinary SDR web content have a gamma-2.2 reference-display interpretation regardless of the compositor's preferred surface encoding? If so, two possible models seem invariant:
- Keep Chromium's usual sRGB-encoded SDR buffer, describe it as gamma22, and let the compositor convert it to gamma22, piecewise srgb, gamma28, or PQ.
- Render directly into the preferred encoding, but transform from that same gamma-2.2 reference interpretation.
Is either model intended, or have I still misunderstood the protocol semantics?
Related details
- Xaver Hugl
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Xaver Hugl (Gerrit)
Xaver Hugl added 1 comment![]( "Open in Gerrit")
Dianda LinThis doesn't seem right.
It doesn't matter which transfer function is used on the output (meaning both the Wayland surface and the physical display), sRGB needs to be displayed as gamma 2.2.
With this change, if you use gamma22 as the transfer function, the result would look different than if you used PQ, even though the same picture is shown. That wouldn't even be restricted to sRGB, it would affect all content.
Thanks — you're right, and I'll abandon this change.
To confirm I've followed: the transfer function chosen for a Wayland surface or physical output must not change the rendered appearance, because the compositor converts between those encodings. My change made the result depend on the preferred description. Since that description also feeds Chromium's render and blending configuration on this path, the effect would not be limited to sRGB content.
Before trying again, could you clarify the intended source model? Should ordinary SDR web content have a gamma-2.2 reference-display interpretation regardless of the compositor's preferred surface encoding? If so, two possible models seem invariant:
- Keep Chromium's usual sRGB-encoded SDR buffer, describe it as gamma22, and let the compositor convert it to gamma22, piecewise srgb, gamma28, or PQ.
- Render directly into the preferred encoding, but transform from that same gamma-2.2 reference interpretation.
Is either model intended, or have I still misunderstood the protocol semantics?
Keep Chromium's usual sRGB-encoded SDR buffer
That would break every non-sRGB content it attempts to show.
Render directly into the preferred encoding, but transform from that same gamma-2.2 reference interpretation.
- Dianda Lin
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |