[Development] HDR Support in Qt and Angle

[Dmitry Kazakov]

Hi, Allan!

On 26.11.2018 15:14, Allan Sandfeld Jensen wrote:
> 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.
As far as I can tell, the most arguable point in scRGB from color 
scientists' point of view is that scRGB allows negative values. If we 
just don't use negative values, the color space becomes basically a 
standard p709-g10 color space, which is widely accepted by everyone.

So the thing we, as developers, should avoid is trying to access wider 
color gamut by utilizing negative part of scRGB. Instead we should just 
use p2020 primaries directly (DXGI interface supports that perfectly for 
the swap chains and my HDR patch supports that as well).


> Also doesn't BT.2020 also require extended color-values above (1.0, 1,0, 1.0)
> in most encodings?

No, BT.2020-PQ doesn't require values higher than 1.0, because the 
entire range of 0...10000 nits is compressed into the range of 
0.0...1.0. At least by definition by EGL:

https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_gl_colorspace_bt2020_linear.txt

But, anyway, the problem is not in values higher than 1.0.The problem in 
negative numbers :)

-- 
Dmitry Kazakov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20181126/161aa020/attachment-0001.html>