deep colour support (10-bit colour)

[totaam]

Issue migrated from trac ticket # 909

component: encodings | priority: trivial | resolution: fixed | keywords: color, 10bpc, 30bit, deep color

2015-07-07 15:57:31: lapsio created the issue

---

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.

[totaam]

Neither Xvfb nor 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.

[totaam]

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..

[totaam]

2016-07-12 15:41:18: lapsio commented

---

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.

[totaam]

See #1260 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.

[totaam]

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)

[totaam]

2016-09-16 07:37:06: antoine uploaded file xorg-30bpp.diff (0.7 KiB)

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

[totaam]

2016-09-16 07:37:32: antoine uploaded file dummy-30bpp.patch (0.7 KiB)

changes needed to dummy driver for supporting 30bpp mode

[totaam]

• 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 nvenc support for 10-bit modes with HEVC #1308, vpx in vpx 10-bit colour encoding support #1310, could also be done in libva (libva accelerated encoding #451)
• opengl client support for 30-bit colour moved to 10-bit color support in opengl client #1309
• related: lower bit depth support in support 16-bit depth #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?

[totaam]

2016-09-16 10:34:55: antoine uploaded file xorg.conf (0.8 KiB)

simplest test config for 30 bpp with Xdummy

[totaam]

• 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)

[totaam]

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

[totaam]

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?

[totaam]

See also: #56#comment:22

[totaam]

Relevant talk: Linux and high dynamic range displays

[totaam]

Not heard back, closing.

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

[totaam]

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

[totaam]

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](../commit/8099628e5f41ebc46d686c49eacdac7d241e425d) 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 #1309#comment:1

[totaam]

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.

[totaam]

New wiki page and command line option to switch bit depth, see Image Depth

[totaam]

Some minor fixes:

• r15586
• r15595

[totaam]

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