v15.0.0.0

Main feature of this release is brand new kind of effect: music visualization. In addition to that there are some important new features/changes for video processing, bug fixes, optimization and structural changes so please read the change log carefully because new version brings some breaking changes.

Most modern HDMI grabbers offer both audio and video capturing. Till now we could only use led visualization for the video content. Don't you think that it's kind of waste and we couldn't use the system for other activities? But that's the past because HyperHDR v15 introduces the audio visualization. Best effect is achieved of course with low latency grabbers and led system like new Ezcap's grabbers family and HyperSerialEsp8266 / HyperSerialWLED. But it was tested using various grabbers including popular MacroSilicone MS2109 on Windows/Linux also.

You can enable sound effect for the selected instance so you can have video visualization on the led strip and sound visualization for Philips Hue lamps simultaneously. Or go full party mode with sound visualization on both devices. For large areas lamps like Philips Hue is best to use full-screen pulse effect. Refer to the live video preview to see how the effect is visualized.

Keep in mind that your current system is configured specifically for video capturing and you must make sure that the grabber is receiving sound also. In case of troubles please refer to the HyperHDR log as there are all needed information.

• Effects: music API for effects is introduced. First configure your sound device in the 'Effects' tab and then run selected music effect from the 'Remote' tab. Please be aware that they are causing much more flickering than the standard video visualization... just like the disco lightning does.

• Video processing: quarter of frame mode. New feature has strong, positive performance impact especially for slower devices like Raspberry Pi Zero. The frame is fast scaled to 50% of original width and height resulting in a quarter of the original frame. For me it's a kind of controversial change because such feature as side-effect allows to hide some unoptimized code from user but at this stage I think the video processing is quite well optimized and tested. Beside some of new grabbers don't allow to change the resolution and 1080p capturing is not always best choice for fast ambilight setups. And NV12/I420 are delivering only a quarter of color information anyway so only some part of luminescence data is lost during the down-scaling process.

• Image processing: sparse processing. Enabling this option for selected instance causes to process only 25% of the captured frame. Effect similar to new 'quarter of frame' mode in the USB grabber settings but it's for selected instances for example: for an instance with large areas for Philips Hue lamps where we don't need such precision and we can turn on sparse processing. Both options have positive, cumulative impact on performance.

• Effects: python module is removed once and for all. That has a positive aspect for stability and resources usage. Most of old effects were rewritten and migrated to the new, fast in-app API. During the process I discovered that one, quite popular configuration of effects stole a lot of resources from the CPU without your attention ... even if you didn't use them during the session (fixed).

• Fixes: better instances interaction and many of discovered bugs were fixed including critical ones like heap corruption while picking up a color during calibration.

• Build system: removing python module and introduced music capability caused rework of the build system. The installers are much smaller now and all the needed dependencies should be provided for most minimal systems even if installed from tar archive. The only needed dependency for deb/rpm installers is xz-utils to extract and to install default LUT table.

• Philips Hue: minimal and maximum brightness were moved to the 'Processing' tab where they belong. Using these settings in the internal Philips driver caused out of gamut situations where orange/blue colors appeared instead of gray at minimal/maximal level. In the Philips' driver there was always hard-coded gamma correction ('candy gamma') and now you have opportunity to disable it as it has quite heavy impact on the lamps and it's not always a good option. Also HyperHDR will wait now for the Hue bridge to start up for all configurations: fix introduced in the previous version worked only for one instance.

• OpenHab automation system: basic interaction with multiple LED's instances was fixed. May have impact on other integrated external applications that are using JSON API also.

• ⚠️Breaking changes: names of the components, configuration file and folders have changed so to:

  • Start/stop HyperHDR as service run: sudo systemctl start/stop hyperhdr@pi.service
  • Run HyperHDR from command line:  /usr/share/hyperhdr/bin/hyperhdr
  • The configuration folder is .hyperhdr in the user home directory on your system. Your old configuration is kept safe and copied&migrated to the new folder automatically at startup but if you have custom LUT table in old home folder or you are on the read-only system then you must do it by yourself.