HyperHDR v18 release

After nearly a year of intensive development and testing, we are pleased to announce the latest stable version of HyperHDR v18. With the new functionalities introduced, we can safely say that no other software available for the most popular operating systems will provide you in this area with the same highest ambient lighting quality and performance using the popular USB grabbers for both HDR and SDR signal. This version also introduces a new unique functionality for the sk6812 RGBW LED strips, allowing it to be fully adapted to our expectations.

Parallel to the development of HyperHDR, tests were carried out on devices that could be alternative platforms for the Rapsberry Pi in connection with global problems with their supply. The results turned out very well, especially in the case of the Amlogic s905x3, which you can read about in the previous blog posts. Of course you can use HyperHDR on Windows, Linux(x64/arm) or macOS as well and it's perfectly fine. New USB grabbers for use with HyperHDR were also tested for compatibility, quality and performance. All this was possible thanks to the research work under the HyperHDR project with devices purchased with the support of our Github sponsors, for which I would like to thank them.

Key features:

1. One of the most important novelties are the dedicated LUTs, which allow you to achieve excellent color reproduction results for the HDR signal. At the same time, the tests showed that the very popular series of grabbers based on MS2109 requires a special approach also for the standard SDR signal! The use of these LUTs is highly recommended, and if your grabber is not listed, you can generate it yourself using a special wizard available in the new version. After calibration, you will find detailed information about its course in the logs.

   Concrete results dispel any doubts that such an approach cannot produce brilliant and accurate colors. For selected grabers, we achieve nearly an industrial level of tonal mapping quality from HDR10 to SDR. And there is nothing to cheat that there is a simple alternative for LUT that allows you to get a similar result in the real-time, e.g. by just modifying HSL/HSV (hue, saturation, lightness/value) colorspace parameters alone: it certainly will not work for HDR and won't even fix SDR for the full-range YUV grabbers, such as MS2109 clones, when they are treated as limited ones. The calibrated HyperHDR LUT can solve both problems, and as it is a flexible solution, it can also be adapted to other real-time video processing in the future.
   Read more here: https://www.hyperhdr.eu/2022/04/usb-grabbers-hdr-to-sdr-quality-test.html
   

   



2. The previous versions of HyperHDR video processing were very well optimized. Nevertheless, the latest version has increased further improvements. A cache for video frames was introduced to prevent memory fragmentation, their processing was optimized, and in the case of MJPEG codecs, we were able to eliminate a very expensive conversion from YUV to RGB for HDR using existing pre-calculated LUT table. Thanks to this, in the case of MJPEG, we achieved a 30% increase in performance with reduced processor load. And Hyperhdr V18 on Rapsberry Pi 4 is now able to process 1080p120 NV12 video without any size decimation. Of course, I absolutely do not encourage you to choose such high resolution and capturing rate in the application because much lower settings are usually enough, but it shows how much these improvements have introduced for the stability and the performance.



3. The new dashboard can help you diagnose problems and bottlenecks in your setup. You can find important information about the CPU, RAM, temperature that could be throttling the system, or if an undervoltage event occurred. There is also information about the actual frame rate of the video source such as USB grabber or flatbuffer server, the time it takes to decode the grabber video frame (try to keep it well below 20ms using the grabber's settings, usually it should take 2-4ms depending on the hardware) and the number of frames that were sent to the LED device by each HyperHDR instance.
   



4. A tool for testing the performance of a USB grabber has been added. It allowed to test many popular devices available on the market. The best time was a delay of less than 50ms including HyperHDR processing. The rest were in ~60-70ms range. Note that the TV also has a lag as it takes time to process the incoming signal before it can be displayed. It is especially high in the TV's cinema modes with all the fancy tweaks and filters turned on, and lower in gaming modes. For certain systems, with HyperHDR's smoothing turned off, the response of the LEDs will often be slightly faster than changing of the TV picture.
   

   This allows us to refute another myth and if you experience for a single instance clear and visible delay above, for example: half a second, then it is certainly the result of incorrect configuration of your system, the choice of software other than HyperHDR that is not optimized, stealing resources by another process or a problem with the LED driver, e.g. weak/unstable wifi signal or other driver's own problem in the case of WLED.

   


5. Another unique feature is the support for dynamic white color calibration for the sk6812 RGBW LED strips. The light driver must be HyperSerialEsp8266, HyperSerialESP32 or HyperSPI in this case as it is an exclusive functionality reserved for projects related to HyperHDR. Thanks to this, you can get a real natural white color corresponding to the factory characteristics of your LED strip and the color of your wall behind the TV. This is not only important for pure white/gray colors, as this channel is also used for mixed colors.
   



6. Support for system events has been added. From now on, HyperHDR will turn off the LED devices and the grabber when the operating system goes to sleep/hibernation. And it will turn them back on when the operating system wakes up. It should also fix some problems with USB devices like LED drivers or video grabbers, when their handles have been lost due to the OS sleep/wake up process.



7. You may like Wayland or not: it does not change the fact and it slowly becomes a popular standard and is also used in the latest Ubuntu 22.04 LTS. HyperHDR V18 brings a software grabber that allows you to capture Wayland sessions along with a support for persistent authentication. As a bonus, new software frame-buffer grabber was also added to capture the screen in Linux OS that do not use the window system.
   



8. Thanks to the community, it is now possible to apply HDR tone mapping for an external flatbuffer source. Also the protobuffer server has been migrated to nanopb and now offers similar feature to improve HDR to SDR video quality, for example with external Android screen grabbers using protocol buffer communication.



9. MQTT support is another feature that will extend the HyperHDR IoT capabilities. From now on, you can use this interface analogically to the JSON API, sending commands and listening for responses.
   



10. The new udpraw server allows you to send RGB colors directly to the selected HyperHDR instance. This can be used to easily control the colors from your own application using UDP protocol and it ensures also the fastest remote instance synchronization ... much faster than using a flatbuffer or protobuffer communication and without the risk of network saturation, which is a problem when transmitting uncompressed images over Wifi.

    Example of usage: on Windows you run HyperHDR with DirectX 11 software screen capturing, disabled smoothing and selected the driver for the udpraw light (the same one you can use e.g. for WLED). You give the IP of the second HyperHDR instance running, for example, on Raspberry Pi with an active udpraw server. From now on, the Raspberry Pi will receive and display colors captured on Windows, using its own light drivers attached to it. Remember to have smoothing enabled only on one unit, otherwise it will be applied twice causing delay!

    
    

Enjoy!