чт, 8 июн. 2023 г., 05:04 Andrew Randrianasulu <[email protected]>:
Found this tidbit
http://psychtoolbox.org/news.html
in 3.0.18 beta
16 bit native (effective 12 bit) framebuffer support for Linux with AMD Polaris and later.
====
This commit switches PsychImaging() to only expose 16 bpc framebuffers on such Linux + X11 + AMD Polaris+ + amdvlk + Linux 5.14 systems, but then at much better reliability and performance than our old dead code.
It allows to get up to 12 bpc per color-channel color output, ie. 4096 intensity levels for red, green, blue, grayscale/luminance and a total of 64 billion shades of color, either on suitable 12 bpc capable high-end displays, or via spatial dithering by the gpu on the more common 10 bpc capable displays or even - at a lower quality - standard 8 bpc capable displays.
This makes Linux the first operating system to my knowledge to support this color precision on out of the box on commodity graphics hardware and displays, natively at full performance without any compromise in timing precision or reliability.
Basic testing has been performed with a CRS ColorCal-2 on a HDR-10 10 bpc capable monitor and on a MacBookPro 2017 Retina display under Linux, with AMD RavenRidge and Polaris.
====
test apps apparently even include gstreamer-based movie player (never thought I'll find HDR player in medical software ...)
http://psychtoolbox.org/docs/PsychHDR
http://psychtoolbox.org/docs/PlayMoviesDemo
===
If the optional flag ‘hdr’ is specified as non-zero, then the demo expects the onscreen window to display on a HDR-10 capable display device and system, and tries to switch to HDR mode. If the operating system+gpu driver+gpu+display combo does not support HDR, the demo will abort with an error. Otherwise it will expect the movies to be HDR-10 encoded and try to display them appropriately. A flag of 1 does just that. A flag of 2 will manually force the assumed EOTF of movies to be of type PQ, iow. assume the movie is a HDR-10 movie in typical Perceptual Quantizer encoding. This is useful if you want to play back HDR content on a system with a [GStreamer <http://psychtoolbox.org/docs/GStreamer>](GStreamer) <http://psychtoolbox.org/docs/%28GStreamer%29> version older than 1.18.0 installed, where [GStreamer <http://psychtoolbox.org/docs/GStreamer>](GStreamer) <http://psychtoolbox.org/docs/%28GStreamer%29> is not fully HDR capable, but this hack may get you limping along. Another restriction would be lack of returned HDR metadata, so if your HDR display expects that, you will not get the best possible quality. Upgrading to [GStreamer <http://psychtoolbox.org/docs/GStreamer>] (GStreamer) <http://psychtoolbox.org/docs/%28GStreamer%29> 1.18 or later is advised for HDR playback. A flag of 3 or 4 will use an alternative HDR display method only available on Linux/X11, with 4 applying the same hack to cope with older [GStreamer <http://psychtoolbox.org/docs/GStreamer>](GStreamer) <http://psychtoolbox.org/docs/%28GStreamer%29> versions as a setting of 2.
====
happy psyching! (???)
from psychdr.m ===== % End of enable sequence, now we kill ourselves: Today is a good day to die! % This will kill the Vulkan driver and hosting Octave/Matlab process without % closing the Vulkan window. As a result, the Linux kernel will clean up after % our dead process, releasing all resources and also releasing the HDR monitor/ % RandR output back to the X-Server and thereby to the regular Screen() fullscreen % onscreen window that we want to use for purely OpenGL driven HDR stimulus % presentation without any further involvement of Vulkan. % We do the kill, because if our driver/process gets killed, the one thing % the Linux kernel does not do (as of Linux 5.8 at least) is disable HDR % metadata transmission to the HDR monitor. So the HDR monitor continues to % receive our static HDR metadata and stays in HDR-10 mode with the statically % assigned HDR properties, ready to receive OpenGL rendered and displayed HDR % PQ encoded visual stimuli for display: kill(getpid, 9); ==== this made me laugh!