[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 

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?


More information about the Development mailing list