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 <b...@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 > developm...@lists.qt-project.org > https://lists.qt-project.org/listinfo/development > -- Dmitry Kazakov
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
