[Development] HDR Support in Qt and Angle

[Dmitry Kazakov]

Hi, all!

I have finally published my HDR patchset in gerrit! It was the first time I
pushed something into gerrit, so if I did something wrongly, please tell :)

https://codereview.qt-project.org/#/c/252187/

There are a few general questions I would like to ask your opinion about:

1) Is it okay to list all the available colorspaces in
QSurfaceFormat::ColorSpace? It leads to the fact that qsurfaceformat.h
should be included in quite a lot of places. I wonder if you think it is
okay.
2) Is API for color space support
(QOpenGLContext::isSurfaceColorSpaceSupported()) actually needed for Qt?
See patch [1]. I first implemented it, but then found that I will have to
do "config probing" anyway. So, technically, this API is not needed for
Krita and HDR implementation, but it might be used as a first-line check by
someone...
3) Ideally, setTextureColorSpace() method should also be implemented for
QOpenGLWindow. Right now it just defaults to DefaultColorSpace.
4) Should I add some tests to Qt? If yes, where?

To test HDR, you can use this simple app:
https://github.com/dimula73/hdrtest


[1] - https://codereview.qt-project.org/#/c/252185/1


On Mon, Nov 26, 2018 at 6:14 PM Boudewijn Rempt <boud at valdyas.org> wrote:

> On maandag 26 november 2018 13:14:12 CET Allan Sandfeld Jensen wrote:
>
> > 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.
>
> We're specifically working on support for the VESA DisplayHDR standard:
> https://displayhdr.org/ . I'm testing with a ASUS ROG Swift PG27UQ
> monitor.
>
> > 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?
>
> Well... We're not doing image manipulation using Qt classes. We simply
> have a
> buffer, handle that using opencolorio (which has suddenly seen a huge
> amount
> of development) to generate another buffer that gets stuffed into f16
> textures
> and displayed. The amazing thing is that we've actually massaged Angle and
> Qt
> into making that possible using QOpenGLWidget.
>
> The result is a set of patches that we want to clean up and upstream :-)
>
> --
> https://www.krita.org_______________________________________________
> 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/20190205/53a0c137/attachment.html>