#909 closed enhancement (fixed)
deep colour support (10-bit colour)
Reported by: | lapsio | Owned by: | lapsio |
---|---|---|---|
Priority: | trivial | Milestone: | 1.0 |
Component: | encodings | Version: | trunk |
Keywords: | color, 10bpc, 30bit, deep color | Cc: | rektide@… |
Description (last modified by )
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.
Attachments (3)
Change History (23)
comment:1 Changed 7 years ago by
Description: | modified (diff) |
---|---|
Milestone: | 0.16 → future |
Status: | new → assigned |
Version: | 0.15.x → trunk |
comment:2 Changed 7 years ago by
Cc: | rektide@… added |
---|
comment:3 Changed 6 years ago by
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..
comment:4 Changed 6 years ago by
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.
comment:5 Changed 6 years ago by
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.
comment:6 Changed 6 years ago by
Summary: | 10bpc support (40 bit color) → 10bpc support (30 / 40 bit color) |
---|
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)
Changed 6 years ago by
Attachment: | xorg-30bpp.diff added |
---|
changes needed to xorg.conf for running in 30bpp mode
Changed 6 years ago by
Attachment: | dummy-30bpp.patch added |
---|
changes needed to dummy driver for supporting 30bpp mode
comment:7 Changed 6 years ago by
Milestone: | future → 1.0 |
---|
- 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?
comment:8 Changed 6 years ago by
Owner: | changed from Antoine Martin to lapsio |
---|---|
Status: | assigned → new |
- 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)
comment:9 Changed 6 years ago by
comment:12 Changed 6 years ago by
Summary: | 10bpc support (30 / 40 bit color) → deep colour support (10-bit colour) |
---|
Relevant talk: Linux and high dynamic range displays
comment:13 Changed 6 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:14 Changed 5 years ago by
Relevant X11 discussion: RFC: Visual Class for On-Screen HDR Drawables
comment:15 Changed 5 years ago by
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
comment:16 Changed 5 years ago by
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.
comment:17 Changed 5 years ago by
New wiki page and command line option to switch bit depth, see wiki/ImageDepth
comment:19 Changed 5 years ago by
The dummy patch has been merged: PATCH: support for 30 bit depth in dummy driver
comment:20 Changed 16 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/909
Neither Xvfb nor wiki/Xdummy support bpp higher than 24/32 at present.
This is what you get with Xdummy:
And in the code we see:
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.