[Development] HDR Support in Qt and Angle
Allan Sandfeld Jensen
kde at carewolf.com
Mon Nov 26 13:14:12 CET 2018
On Montag, 26. November 2018 12:23:15 CET Boudewijn Rempt wrote:
> On maandag 26 november 2018 09:10:33 CET Allan Sandfeld Jensen wrote:
> > I have been working on it and have a plan for it. The first steps is a
> > color space system, see https://codereview.qt-project.org/234095.
> >
> > Then the very basic of extended colors https://codereview.qt-project.org/
> > 233735
> >
> > Next I have some work toward an 4xfp16 based rendering backend and image
> > support, possibly removing the 4xuint16 backend at the same time so there
> > is only one high-color precision backend.
> >
> > Then we just need a way to connect that to a backing store, such as using
> > scRGB in OpenGL which looks like what you have been wokring on :)
>
> Ah, no, that's not what we're doing. OpenGL simply does not support HDR at
> all in any meaningful way. Sending f16 textures looks like it works, on
> nvidia cards, but it will not work on an intel gpu. And scRGB is something
> that's very controversial -- Charles Poynton says this:
> https://twitter.com/momaku/ status/1059239827244306432
>
It depends on what you want. Using Display P3 for instance is just wide-gamut
not HDR. You can get that with just the new color-space support and higher
non-extended color precision. That is the primary motivation for doing that
first as wide-gamut monitors are already on the market and in the hands of
many (high-) end-users. Where HDR is still mostly non-standardized on PC
monitors.
The use of extended RGB, as scRGB is also known, is very useful behind the
scenes in any case, as using that you can map to and from any color-space
without clamping, so we can keep something that is internally like sRGB, while
still supporting wide-gamut by later taking the extended-sRGB and turning it
back into a non-extended wide-gamut image. This makes it possibly to put the
clamping and final color-space conversion in the QPA, while keeping the rest
generic. So I would still support at least linear-scRGB (aka extended-linear-
sRGB), even if only as an intermediate format.
It is arguably a strange non-sensical format with many impossible colors, but
it is also very useful.
Also doesn't BT.2020 also require extended color-values above (1.0, 1,0, 1.0)
in most encodings?
'Allan
More information about the Development
mailing list