deep colour support (10-bit colour)

[lapsio]

I'm not sure if it's difficult or just few lines of code but in case it's quick fix it'd be nice to have 40 bit color (for Quadro) support, doesn't matter png (which supports 10bpc) or raw, whatever just anything to transport deep color. I happen to work in environment supporting 10bpc. If you care, ATI FirePro support 12bpc? if i remember well. It's ofc supported by normal X server.

[Antoine Martin]

Neither Xvfb nor wiki/Xdummy support bpp higher than 24/32 at present.
This is what you get with Xdummy:

[  8081.079] (EE) DUMMY(0): Given depth (30) is not supported by this driver

And in the code we see:

    if (!xf86SetDepthBpp(pScrn, 0, 0, 0,  Support24bppFb | Support32bppFb))

So this driver would require some work (not sure how much) to support anything other than 24 / 32.

Until then, we could support such modes by running against a real X11 server instead of a virtual one, but this would limit us to one session per GPU at best...

As for the xpra code itself, the pixel compression would not be too much of a problem (I think vp9 supports 10bpp and even alpha channels) - though the client would require some work to take advantage of the extra colours depth.

[Antoine Martin]

Maybe we can add support for this using desktop mode (#1247), this would at least ensure that we can handle those pixels formats in both server and client code before we add support for it in Xvfb or the dummy driver.

AFAICT, even though png supports 48-bit colour, there is no support for it in pillow, see: ​Creating a 48-bit TIFF file in Python with PIL, so we will need another encoder even the simplest case..

[lapsio]

30 bit support in Linux is still kind of poor, every app implementing it is small step forward. I still really hope this functionality can be implemented in xpra.

Also nVidia drivers support dithered 10bpc on 8bpc displays and it works really well so something like this would be extremely useful if implemented in xpra as it'd actually enable people without Quadro GPUs to display dithered 10bpc on any hardware, even Intel GPUs as long as host does have Quadro/FirePro? to launch X server in 30bit mode.

So host launches X server in 30 bit color, then xpra captures it, possibly performs 10->8 bit dithering and displays on client PC which can have some crappy consumer GPU. It'd be really awesome feature saving money for a lot of people because many of 2d artists are getting cards like Quadro or FirePro? just to get 30bit color and it's not cheap. In laptops Quadro cards are even more expensive as it's only offered in pure top-end mobile workstations.

Being able to get one professional card like this and then use its 30 bit capabilities on all PCs in home no matter what hardware they have would be simply killer feature for some artists.

[Antoine Martin]

See ticket:1260#comment:1 and ​Anandtech: NVidia Pascal - Display Matters: New Display Controller, HDR, & HEVC: For Pascal, NVIDIA is opening things up a bit more, but they are still going to keep the most important aspect of that feature differentiation in place. 10bit color is being enabled for fullscreen exclusive OpenGL applications – so your typical OpenGL game would be able to tap into deeper colors and HDR – however 10bit OpenGL windowed support is still limited to the Quadro cards. So professional users will still need Quadro cards for 10bit support in their common applications.

For enabling 30-bit output: ​How to Enable 30-bit color on Linux
For verifying 30-bit output: ​30-bit depth with Linux driver does not produce 30-bit output on monitor.

[Antoine Martin]

Initial support for "r210" added in r13741, tested with a shadow server.
Works with all non-video encodings, including mmap.

Still TODO:

• we need a CSC module for converting to YUV420 (and preferably a fast one..), none of the existing modules can handle this format
• speedup the argb module, as r210_to_rgba will be used a lot
• try to add 30-bpp mode to the dummy driver (or try with plain Xvfb: ​Add 12bit PseudoColor visual support to Xvfb - caused: ​Xvfb segfault on server regeneration or exit?)

Later:

• add a CSC conversion to Y410 or P010 (or whatever NVENC / libvpx take as input for 10-bit colour, but not x264 which requires a build time option: ​10-bit with libx264) - see ​10-bit and 16-bit YUV Video Formats
• support 30-bit output in the opengl client (see ​nvidia 30 bit color technology)

[Antoine Martin]

changes needed to xorg.conf for running in 30bpp mode

[Antoine Martin]

changes needed to dummy driver for supporting 30bpp mode

[Antoine Martin]

• big performance improvement in r13751 (12 times faster, yet still 12 times slower than xxhash!)
• r13752 adds r210 support to csc_cython (now included again by default in rpm and deb builds) so we have video support (downsampled to 8-bit)
• with the 2 patches above, dummy can be used in 30bpp mode as long as we also set resize-display=no (randr is broken with this change and causes Xorg to crash hard)
• nvenc support for HEVC 10-bit modes moved to #1308, vpx in #1310, could also be done in libva (#451)
• opengl client support for 30-bit colour moved to #1309
• related: lower bit depth support in #1315

Still TODO:

• push dummy fixes, xorg-devel posts: ​30-bpp mode for dummy - exposes a bug somewhere else? and ​DUMMYAdjustFrame does nothing useful
• try Xvfb
• try 12-bit?

[Antoine Martin]

simplest test config for 30 bpp with Xdummy

[Antoine Martin]

• dummy patches submitted upstream: ​support for 30 bit depth in dummy driver, ​remove dead code in dummy driver
• patches applied to the latest dummy beta rpm builds: r13780 (centos 7 and fedora only for now)
• default 30-bit display section added to default xorg.conf: r13781

Running in 30-bit mode now only requires changing the DefaultDepth 30 in the xorg.conf, or adding -depth 30 to the xdummy command line.

@lapsio / rektide: does that work for you? (will continue improving this in future releases, see ticket links from comment:7)

[Antoine Martin]

The patch in comment:8 was incomplete, updated version in r13785 also sent to the mailing list.

[Antoine Martin]

Related:

• ​Linux and High Dynamic Range Display
• ​HDR Demystified
• ​What are the practical differences when working with colors in a linear vs. a non-linear RGB space?

[Antoine Martin]

See also: ticket:56#comment:22

[Antoine Martin]

Relevant talk: ​Linux and high dynamic range displays

[Antoine Martin]

Not heard back, closing.

Will follow up in #1308, #1310 and #1309

[Antoine Martin]

Relevant X11 discussion: ​RFC: Visual Class for On-Screen HDR Drawables

[Antoine Martin]

As of r15028, the display's bit depth will be shown in the server output (here with 30-bit):

xpra X11 version 2.0-r15028 64-bit
 uid=1000 (antoine), gid=1000 (antoine)
 running with pid 22114 on Linux Fedora 25 TwentyFive
 connected to X11 display :10 with 30 bit colors

The client bit depth is now also displayed, see ticket:1309#comment:1

[Antoine Martin]

r15072 makes it possible to use jpeg and png by downsampling the original 30-bit image. That's only used if we have no other choice.

[Antoine Martin]

New wiki page and command line option to switch bit depth, see wiki/ImageDepth

[Antoine Martin]

Some minor fixes:

• r15586
• r15595

[Antoine Martin]

The dummy patch has been merged: ​PATCH: support for 30 bit depth in dummy driver

[migration script]

this ticket has been moved to: ​https://github.com/Xpra-org/xpra/issues/909