Posts by Awawa

Good news!
How to eat a cake and have a cake? Yes, now it's possible for the color calibration at least.
I added old Hyperion calibration panel with most settings.
And yes, saturation & luminance control is back now

It's possible now to switch between new/old calibration panel to compare result. On default settings there will be no difference of course.
Dont know..maybe I'm too stupid, there are too many settings or my lack of patient cause I could not set calibration with new Hyperion.NG panel.
Old one was clean & simply.

And one more important thing.
Because I included latest patches from Hyperion.NG there is a support for sk9822 now.
Most users think that they have APA102.
In fact most (if not all) models of leds sold on Aliexpress are their chipper clone sk9822.
You can find on the internet how to recognize them.
However the protocol is not 100% compatible with APA102 and it may cause different problems (flickering?).
I think even after included it the Hyperion.NG the protocol isn't fixed.
In my fork I added patch found in FastLed to make it work better but I could not test it.

New prerelease:
https://github.com/awawa-dev/HyperHDR/releases/tag/v9.2.0.8

Quote from rysuq

Pi zero is too slow to handle this or what ?

Cpu could handle it perhaps. 270 is a lot ...maybe there is a chance to control them with Rpi zero without hyperion with grabber...timing control for WS2812B is tricky for multitasking system on Rpi (all models). Not without reason most use arduino for that purpose.

I very doubt it will ever work on Pi zero with WS2812B and 270 leds to handle anyway.

definitely some bug but remove /home/pi/.hyperion folder to reset settings

missing cec package

sudo apt install libcec4

now execute:

/usr/bin/hyperiond -d

I tested similar setup on newest Denon x2700h (HDR10+ and Dolby Vision theoretically possible) and I failed with simply HDR output on both devices. The devices received the split & processed signal but the quality was affected. I suspect the grabber is the problem as it probably reports EDID that causes amplifier to choose wrong (not optimal) format that fits both.

Quote from pclin

The Hyperion default values do not give me a satisfactory result.
Mainly I use hyperion (classic) and there the colors (details) are much better for me.
With the settings for hyperion-ng I come at least closer.

As I write earlier I experience the same. Could not calibrated it in SDR as I want.
I've got idea than maybe I can revert color processing procedure and restore old configuration from the classic Hyperion but it's one way ticket.
Must be remembered that HDR lut correction isn't 100% bulletproof: there are some information lost and it's only a try (good one I think) to make it look as on the TV and even with old color procedure there will be some differences. Fortunately mainly in dark areas of the frame.

You have set it correctly targeting black vertical bar. I've explained it on the example:
SDR & HDR 1080p/4k capable setup with Hyperion-NG for Media Center

I've tested on default settings for signal detection and it works as intended:

2020-10-04T20:55:53.584Z [hyperiond V4L2:/DEV/VIDEO0] (DEBUG) (V4L2Grabber.cpp:766:init_device()) Set framerate to 30 fps
2020-10-04T20:55:53.584Z [hyperiond V4L2:/DEV/VIDEO0] (DEBUG) (V4L2Grabber.cpp:100:loadLutFile()) LUT file found: /home/pi/.hyperion/lut_lin_tables.3d
2020-10-04T20:55:53.584Z [hyperiond V4L2:/DEV/VIDEO0] (DEBUG) (V4L2Grabber.cpp:109:loadLutFile()) Index 1 for HDR YUV
2020-10-04T20:55:53.682Z [hyperiond V4L2:/DEV/VIDEO0] (DEBUG) (V4L2Grabber.cpp:131:loadLutFile()) LUT file has been loaded
2020-10-04T20:55:53.682Z [hyperiond V4L2:/DEV/VIDEO0] (DEBUG) (V4L2Grabber.cpp:790:init_device()) Pixel format=YUYV
2020-10-04T20:55:53.691Z [hyperiond V4L2:/DEV/VIDEO0] (INFO) Multithreading for V4L2 is enabled. Available thread's count 4
2020-10-04T20:55:53.694Z [hyperiond V4L2:/DEV/VIDEO0] (INFO) Started
2020-10-04T20:55:53.695Z [hyperiond V4L2:/DEV/VIDEO0] (ERROR) Frame too small: 0 != 1572864
2020-10-04T20:55:55.449Z [hyperiond V4L2:/DEV/VIDEO0] (ERROR) Previous line repeats 3 times
2020-10-04T20:55:55.450Z [hyperiond V4L2:/DEV/VIDEO0] (INFO) Signal lost
2020-10-04T20:55:56.468Z [hyperiond HYPERION] (DEBUG) (PriorityMuxer.cpp:238:setInputImage()) Priority 240 is now inactive
2020-10-04T20:55:56.468Z [hyperiond HYPERION] (DEBUG) (PriorityMuxer.cpp:333:setCurrentTime()) Set visible priority to 255
2020-10-04T20:55:56.468Z [hyperiond HYPERION] (DEBUG) (Hyperion.cpp:538:handlPriorityChangedLedDevice()) priority[255], previousPriority[240]
2020-10-04T20:55:56.468Z [hyperiond HYPERION] (DEBUG) (Hyperion.cpp:541:handlPriorityChangedLedDevice()) No source left -> switch LED-Device off
2020-10-04T20:56:08.785Z [hyperiond V4L2:/DEV/VIDEO0] (INFO) Signal detected
2020-10-04T20:56:08.785Z [hyperiond HYPERION] (DEBUG) (PriorityMuxer.cpp:238:setInputImage()) Priority 240 is now active
2020-10-04T20:56:08.785Z [hyperiond HYPERION] (DEBUG) (PriorityMuxer.cpp:333:setCurrentTime()) Set visible priority to 240

I've paused the movie on the intro black frame and then I resumed it.

OK, I understand as I'm missing some features from old Hyperion too but these (VMin, Hmin, VMax, Hmax) settings are not correlated with colors. They are used only for signal detection area. Anyway grabber should resume on bright full screen scene.

I dont know what's your resulution but assume 1024x768 without any cropping/decimation or whatever.
VMin=Hmin=0.01, VMax=Hmax=0.1
So detection area-rectangle start position is X=10 at left and Y=7 from top. It's offset.
Rectangle ends at X=102 and Y=76.
Default size/position for Hyperion is 0.25 and 0.75. It's very fast detecting procedure that exits when the first pixel above the threshold is found so you could try it.
The real quesion is if the grabber resumes at some point after it lost signal?

Could you post logs in Debug mode? I take a look.

BTW you've set very harsh condition for signal detection on very small area: even black border could trigger no signal. Till now I cant reproduce it on my system but it's still running.

New support pre-release v8.2.0.8A3

It contains some tune up & fixes from feedback + Hyperion.NG latest commits (up to 9d2e442) as bonus:
- migration to Debian Buster caused that libglvnd0 library is necessary. Already included in deb dependency in previous release and now included in tar/lib Rpi containers.
- I suspect there are some issues with Dispmanx (even disabled in config) on certain Rpi setups with USB grabbers. Till it's clear up the Dispmanx is excluded from build.
- fix for cmake config when building with github Docker images as it disabled custom optimization for Rpi 3/4 systems. Previous releases are affected.

Oh, sorry I've got special build that fix it but I wasnt sure so I left it from release
Your log:

2020-10-01T19:26:33.756Z [hyperiond DAEMON] (INFO) set screen capture device to 'dispmanx'
2020-10-01T19:26:33.756Z [hyperiond DISPMANXGRABBER] (DEBUG) (Grabber.cpp:30:setVideoMode()) Set videomode to 0
2020-10-01T19:26:33.758Z [hyperiond DISPMANXGRABBER] (INFO) Display opened with resolution: 4x1053348084
2020-10-01T19:26:33.759Z [hyperiond DISPMANXGRABBER] (DEBUG) (Grabber.cpp:90:setWidthHeight()) Set new width: 80, height: 45 for capture

mine (v8.2.0.8A Hyperion-8.2.0.8A-Linux-Raspbian-Buster-v4l2grabberonly-armv7l.deb on git)

2020-09-25T15:30:26.543Z [hyperiond DAEMON] (WARNING) No platform capture can be instantiated, because all grabbers have been left out from the build
2020-09-25T15:30:26.544Z [hyperiond DAEMON] (INFO) set screen capture device to 'dispmanx'
2020-09-25T15:30:26.544Z [hyperiond DAEMON] (ERROR) The dispmanx framegrabber can not be instantiated, because it has been left out from the build

No disconnection:

2020-10-01T20:12:56.789Z [hyperiond V4L2:/DEV/VIDEO0] (DEBUG) (V4L2Grabber.cpp:992:process_image()) Video FPS: 30.02, av. delay: 12ms, good: 1801, bad: 0 (60.03,15)
2020-10-01T20:13:56.821Z [hyperiond V4L2:/DEV/VIDEO0] (DEBUG) (V4L2Grabber.cpp:992:process_image()) Video FPS: 30.02, av. delay: 13ms, good: 1801, bad: 0 (60.03,15)
2020-10-01T20:14:19.165Z [hyperiond WEBSOCKET] (DEBUG) (WebSocketClient.cpp:204:sendClose()) send close: 1000
2020-10-01T20:14:56.853Z [hyperiond V4L2:/DEV/VIDEO0] (DEBUG) (V4L2Grabber.cpp:992:process_image()) Video FPS: 29.98, av. delay: 13ms, good: 1799, bad: 0 (60.03,15)
2020-10-01T20:15:56.885Z [hyperiond V4L2:/DEV/VIDEO0] (DEBUG) (V4L2Grabber.cpp:992:process_image()) Video FPS: 30.02, av. delay: 12ms, good: 1801, bad: 0 (60.03,15)
2020-10-01T20:16:56.917Z [hyperiond V4L2:/DEV/VIDEO0] (DEBUG) (V4L2Grabber.cpp:992:process_image()) Video FPS: 30.02, av. delay: 13ms, good: 1801, bad: 0 (60.03,15)
2020-10-01T20:18:56.973Z [hyperiond V4L2:/DEV/VIDEO0] (DEBUG) (V4L2Grabber.cpp:992:process_image()) Previous line repeats 1 times
2020-10-01T20:18:56.973Z [hyperiond V4L2:/DEV/VIDEO0] (DEBUG) (V4L2Grabber.cpp:992:process_image()) Video FPS: 30.02, av. delay: 12ms, good: 1801, bad: 0 (60.03,15)
2020-10-01T20:19:57.002Z [hyperiond V4L2:/DEV/VIDEO0] (DEBUG) (V4L2Grabber.cpp:992:process_image()) Video FPS: 30.02, av. delay: 13ms, good: 1801, bad: 0 (60.03,15)
2020-10-01T20:20:57.033Z [hyperiond V4L2:/DEV/VIDEO0] (DEBUG) (V4L2Grabber.cpp:992:process_image()) Video FPS: 30.02, av. delay: 14ms, good: 1801, bad: 0 (60.03,15)
2020-10-01T20:23:57.126Z [hyperiond V4L2:/DEV/VIDEO0] (DEBUG) (V4L2Grabber.cpp:992:process_image()) Previous line repeats 2 times
2020-10-01T20:23:57.126Z [hyperiond V4L2:/DEV/VIDEO0] (DEBUG) (V4L2Grabber.cpp:992:process_image()) Video FPS: 30.00, av. delay: 14ms, good: 1800, bad: 0 (60.03,15)
2020-10-01T20:25:57.187Z [hyperiond V4L2:/DEV/VIDEO0] (DEBUG) (V4L2Grabber.cpp:992:process_image()) Previous line repeats 1 times
2020-10-01T20:25:57.188Z [hyperiond V4L2:/DEV/VIDEO0] (DEBUG) (V4L2Grabber.cpp:992:process_image()) Video FPS: 30.02, av. delay: 14ms, good: 1801, bad: 0 (60.03,15)
2020-10-01T20:26:57.218Z [hyperiond V4L2:/DEV/VIDEO0] (DEBUG) (V4L2Grabber.cpp:992:process_image()) Video FPS: 30.00, av. delay: 13ms, good: 1800, bad: 0 (60.03,15)
2020-10-01T20:27:57.249Z [hyperiond V4L2:/DEV/VIDEO0] (DEBUG) (V4L2Grabber.cpp:992:process_image()) Video FPS: 30.02, av. delay: 12ms, good: 1801, bad: 0 (60.03,15)
2020-10-01T20:28:57.280Z [hyperiond V4L2:/DEV/VIDEO0] (DEBUG) (V4L2Grabber.cpp:992:process_image()) Video FPS: 30.00, av. delay: 14ms, good: 1800, bad: 0 (60.03,15)

platform capture:

Probably it's a jumping for some reason effects source 254 but I think it's related to displamanx somehow (240 is usb grabber). I've experienced the same.
Disable system grabber (dispmax).

OK. BTW if you still have the old Pi zero then you can perform full test connecting Rp4 and Pi zero using SPI in master/slave communication. But before that verify wiring. EDIT: seems Rpi can be only master...arduino could help.

One detail picture would tell much more Anyway, double check again connection or verify if MOSI is working properly (connecting it to MISO in a loop and use one of test programs for SPI troubleshooting )