[Development] HDR Support in Qt and Angle

Dmitry Kazakov dimula73 at gmail.com
Mon Nov 26 16:11:12 CET 2018

Hi, Allan!

It is nice to ear you are working is a adjoint part of color management 
in Qt! I think we should coordinate a couple of things to make sure we 
can merge our efforts later.

Basically, for implementing correct frame buffer compositing I need to 
know the following points:

1) Color space of the framebuffer (swap chain) of the root window. It is 
usually set by QSurfaceFormat::setDefaultFormat(). Right now I 
implemented that by extending QSurfaceFormat::ColorSpace enum (see [1]). 
Do you think it is okay?

2) When rendering legacy Qt widgets, I assume that all of them just have 
sRGB color when converting them into the framebuffer's color space. See 
[2]. Is such assumption okay?

3) When composing QOpenGLWidgets into the framebuffer I need to know 
their color space as well. Should I also reuse enum from 
QSurfaceFormat::ColorSpace or better introduce some other enum to avoid 
dependency to QSurfaceFormat? See TODO note in [3]

4) Btw, do you have any idea how ICC calibrated and profiled displays 
are expected to behave when an application uses p2020-pq or p709-g10 for 
the framebuffer color space?

[1] - 
[2] - 
[3] - 

On 26.11.2018 11:10, Allan Sandfeld Jensen wrote:
> On Mittwoch, 21. November 2018 10:43:57 CET Boudewijn Rempt wrote:
>> We've been working with Intel for some time now on figuring out how to
>> support HDR in Krita. Dmitry has made some initial progress, hacking on
>> Angle and Qt to make this possible. Right now, only Windows and Direct3D
>> support HDR, though Intel is also working on support on Linux.
>> Other Qt applications, like VLC, implement a custom Direct3D widget, but
>> since all our code is opengl, that wouldn't have worked for Krita.
>> Here's the first report with some links to code: https://
>> dimula73.blogspot.com/2018/11/krita-fall-2018-sprint-results-hdr.html
>> What I'm wondering is, have other people been working on this as well, or
>> thinking about it? And what would be needed to get our code upstreamed. I
>> remember that trying to get the modernized code for QOpenGLPainter pushed
>> was quite hard, so I wanted to reach out as soon as possible.
> 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 :)
> Best Regards
> 'Allan
> _______________________________________________
> Development mailing list
> Development at lists.qt-project.org
> https://lists.qt-project.org/listinfo/development

Dmitry Kazakov

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

More information about the Development mailing list