Posts by Awawa

Thanks for the feedback
Already uploaded fixed installers as some system libraries could be missing too in some scenarios Windows_Installer_11.2.0.8_with_LUT_preview

Yep, some downsides of the first release
Please install official libturbo for now https://sourceforge.net/projects/libjp…vc.exe/download and see if it helps.
If not copy dll from their installation forlder (turbojpeg.dll is there) to HyperHDR installation bin folder (where hyperiond.exe is).
I will include them in the next roll out.

@sergoo_lbt I will look into it
@Puck this feature is coming in the next version

BTW...this how it works under Windows for the first time with USB grabbers :geek: Need brave testers

You can use it without 4k or HDR input signal. Simply turn off HDR to SDR tone mapping in the grabber configuration as probably you wont need it.
There some significant changes mainly in v4l2 grabber (grabber's process capture optimization, support for multi-threading instead single thread in Hyperion.NG, YUV/HDR tone mapping), color transformation (color calibration, extended image to LED color transformation) and it's targeted for newer Debian Buster so you can test it how it works for you.

And support for USB grabbers in Windows is coming

Possible solution would be to insert a splitter like FeinTech (with TV output as priority) BEFORE Denon and make Denon to output HDR->SDR video to grabber only. But in my case I want the setup to be the simplest as possible (have some issues with FeinTech before anyway) and I dont want to play like that.
In this scenario x2700 for HDR is overshot, simply x1.00 with one HDMI output should be sufficient.

Seems it should be supported, but please continue on PM I will try to help. First install latest of my release (SD card image) and send me output of dmesg, v4l2-ctl --all, v4l2-ctl --list-formats-ext, v4l2-ctl --list-devices commands after you ssh to the HyperHDR raspberry pi unit. It could be insufficient power supply for Rpi but it's wild guess.

It seems like a kind of simply image recognition Anyway, I don't gave a plan for any support for an analog solutions in a future and that "no signal" screen is a sign of that past technology. Modern HDMI grabbers simply output a black image.. there are cheap, more advanced (FullHD resolutions without downscaling, accept various FPS and color formats including HDR10) and reliable than counterfeit UTV0007 clones. This fork is focused on high quality image processing including HDR. I hope you understand my reasons.

No, thats not the case. TV didnt received the HDR if that grabber was connected to the denon. The image was downgraded.

No, because I dont want to set any constant resolution on TV as my player PC using best resolution (both 1080 & 4K and various refresh rate, always HDR) for each movie. Possible solution would be passthrou on OUTPUT1 (TV) and forced format on OUTPUT2 (ezcap 269 grabber) but it seems that it's not possible, Ezcap can handle HDR for some extend but if I connect it to the OUTPUT2 on AUTO denon disables HDR for both: TV and ezcap.

Currently my PC has graphic card with 2 outputs and I use it: one to the ezcap->tv, second to the denon only for sound output.

That's the limitation of the signal detection algorithm that depends on the brightness/black level. And it works as it's designed, causes some side effects.
In this situation some kind of image (rainbow) recognition is needed, and as it various from one kind of grabber to other (and from one saturation/luminescence levels to others), maybe detection by neural network would be preferred. Out of my skills unfortunately

@NeeeeB it's already uploaded. untested

Out of schedule but I've got some new ideas and time due to the pandemic situation in the country.

• I found some place to improve how the mean color from the input source (grabber or other) is computed.
  In Hyperion.NG it's done by averaging red,green,blue.
  

  Why it isn't optimal algorithm is explained here:
  

  External Content www.youtube.com

  Content embedded from external sources will not be displayed without your consent.

  Display all external content

  Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

  So I've introduced two new option for LED color processing
  

  • Advanced option:
    Mean color is computed as square root of average color component to second power.
    LED are generally brighter.
    You can see the difference on the following screenshots.
    

    Hyperion default mean color:
    averaging sum of color component causes red to be reduced by the black surrounding.
    

    New advanced option:
    preserves the brightness
    

    
    

  • Advanced weighted: the algorithm I prefer.
    For each led the input image box is divided in a half: first closer to the (TV) edge and the second.
    The mean color is computed as advanced option for each box, then final mean color is computed as 3/4 of 1' and 1/4 of 2".
    This cause that the part of the image that is closer to the TV edge has greater impact on the LED.

  Algorithms are optimized so it shouldn't have any significant impact on the main thread performance (we have a lot of room as the grabber is moved to other threads)

  
  

• Improved LUT table. The first idea came from the FastHDR project. I understand now what it works. I think that was a lucky shot...but really good one.
  Even now I think that it produces far better results than ITE base algorithm. But it lost some details in the dark scenes so I've introduced some elements of ITE to bring them back. But FastHDR concept is still dominant.
  BT2020 to BT709 option is removed as it wasn't necessary and it shifted image towards the red.
  

  
  

• At last LUT table now is included in the DEB & RPM installers! But check logs in the debug mode to make sure if it's work as it's the first release of that type.
  

  
  

• @pclin I've added luminescence,saturation & temperature control for hyperion-remote. Option 'Hyperion classic calibration" must be activated first in the color calibration web panel.

Make sure that you removed LUT table from the previous version!
https://github.com/awawa-dev/Hype…/tag/v10.2.0.8A
This is a pre-release for advanced users for now.

Feel really stupid, now...I've got solution before eyes.
The problem was solved in ITU-R BT.2446-0 and I missed it few months ago. No more guessing color correction now.

Please download again https://github.com/awawa-dev/Hype…t_lin_tables.7z

HDR to SDR is perfect color matching now with bt2020 HDR10.
Really need take a break now...

use expert level settings in Hyperion.NG, things that you are missing are hidden on default

@pclin I will look into this.

And for advanced users as I don't have a plan to release new version in a few next weeks:

After some experiments I think I improved the LUT table generator. Main changes:
- gamma promotion was too strong, a lot of details were lost in the dark scenes. Now I reduced a bit gamma curve to bring the details back, at least for some level as we cant have real HDR on SDR capture device.
- promote blue, and some red for a cost of a green component.

First LUT generator was optimized for HDR promo demos as a proof of concept. The problem was that they were too bright, real movies aren't.
For example in Avanpost in the dark scene dark blue color turns into celadon and that was annoying.

New improved LUT table for tests.
https://github.com/awawa-dev/Hype…t_lin_tables.7z

Dont know about hyperion-remote but controlling saturation/luminescence/temperature is possible by JSON api already as a side effect.
https://docs.hyperion-project.org/en/json/Server…tml#adjustments
New proprieties:
"temperatureRed"
"temperatureGreen"
"temperatureBlue"
"saturationGain"
"luminanceGain"

I dont have that type of Led. Did you read the prerequirement?
SDR & HDR 1080p/4k capable setup with Hyperion-NG for Media Center
I suggest you to build & install Hyperion.NG from the current master branch to compare results.

Hard to say...as I tested moment ago on my setup it worked.

Quote from sPOiDar

In addition, the docker compilation script in the repo does not allow targeting Ubuntu, as it requires custom base images with all the deps pre-installed, and the Dockerfile for those images doesn't appear to be in the repos.

In the end I managed to hack together a build script by combining the documentation on manually building, slotting it into a hacked docker-compile.sh script, and adding deps that were missing from the docs, until it compiled successfully.

Not an enjoyable process though - debs for multiple host environments added to CI would certainly be a welcome change.

I've got quite opposite feelings. Debian Buster with Qt5 is already supported. No need to hack, docker scripts are in hyperion.docker-ci repo with all needed dependencies. Using Git Action the installer can be even build on our own fork by the git himself. Buster or Stretch ...all you need to do is modify few lines in git action. For me it's quite impressive how it's done in the project.

As Hyperion.NG in the Hyperbian system is not installed as a package (extracted archive exactly, I think it's rather inconvenience, I've changed it anyway and can provide pull request if necessary) the simplest way is to backup the configuration (/home/pi/.hyperion folder I think) and install new release of Hyberbian on the SD card. Removing previous version by a hand is rather difficult task.