[Development] HDR Support in Qt and Angle

[Frederik Gladhorn]

Hi Dmitry,

Thanks for all the hard work :) It's not my area, so I won't be able to 
comment on the patches as such.

Please add reviewers to all patches, so they don't get forgotten. While that's 
quite some work, many people will only see email notifications from gerrit, or 
look at their dashboards, and it's easy to miss a dependency like that.

Cheers,
Frederik


On tirsdag 5. februar 2019 17:19:29 CET Dmitry Kazakov wrote:
> 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