New LUT calibration based on mp4 test videos (part I) #896
Conversation
awawa-dev
force-pushed
the
ai_calibration
branch
from
337ecec to
fa7eff8
Compare
awawa-dev
force-pushed
the
ai_calibration
branch
from
b97f332 to
1ab1a2c
Compare
|
I've managed to calibrate using extended P010 range: result ~75 (yuv 420 limited) without tweaking anything and the perfect image without quantization. I have to think whether to throw the RPi in the trash since it doesn't support P010 or whether the current result will be enough for me... At most, there will be another tutorial on the blog :) |
|
@awawa-dev |
|
Hi @satgit62 If you look at the logs when HyperHDR is being built https://github.com/awawa-dev/HyperHDR/actions/runs/11621071484 So we have for RPi Bookworm: #pragma message "P010 is supported on the build machine" so theoretically the patch is not needed. In Ubuntu24.04 also: #pragma message "P010 is supported on the build machine" but in the older Ubuntu 22.04: #pragma message "P010 is NOT supported on the build machine" Of course this only means the presence of P010 in the header files, it does not mean that the kernel supports it. We are slowly moving here: #967 |
@awawa-dev
|
|
Who knows.. maybe I'll add P010 support for the grabbers I have myself, although I was hoping that I had finished developing at the kernel drivers level after my adventure with tvboxes ;-) It's possible that elgato is a broken exception (even Corsair claims that Linux is not supported) and these new grabbers with new chipsets will be supported
There is a significant difference: for grabbers you set these settings in the grabber properties and for flatbuffers these settings are dynamic based on what's came |
|
Just for your information: we found a bug (I guess we can call it that) in the Kodi (at least Intel is confirmed) configuration where it turns out that HDR test files must have a master-display tag for HDR passthrough to be enabled at all. Otherwise, you risk calibrating SDR mode, because Kodi will treat the HDR test file that way. |
|
I created a small tutorial, not as detailed as @satgit62's :) but I needed some documentation for HyperHDR too: https://github.com/awawa-dev/HyperHDR/wiki/lut-calibration |
|
@satgit62 @NatyaSadella @s1mptom |
|
The bug is here: https://github.com/webosbrew/hyperion-webos/blob/a27ad43d4c6e961c53a7534de723866307aee667/src/json_rpc_client.c#L202 |
|
Thank you @awawa-dev, I'll take a look at that. If this is a bug, then it was like this from the beginning and made sense for a single LUT. |
|
This method containing a bug also manages LUT switching and I don't see that the option you mention is considered there. Maybe it is checked before and then it is not called at all. Generally for webOS one LUT does not make sense: SDR is not SDR on webOS, so a special LUT is needed. If you disable tone mapping while having one LUT for HDR or SDR, webOS SDR colors will definitely not be fixed correctly just a standard NV12 to RGB. To summarize: on webOS tone mapping should always be enabled, the distribution should contain several LUTs or a note that it is only intended for eg. HDR having only one LUT. |
Yes, the preview image is better with HDR switched on with SDR.
|
|
or just 1 |
Yes, that is correct, we already use different LUTs. |
|
@awawa-dev |
|
No need to recalibrate SDR LUT if you have one. Simply that calibrated LUT didnt work after calibration if tone mapping was disabled. The difference should be visible in the video live preview on some SDR content while switching tone mapping on & off when SDR LUT is selected. |
|
I think the mistake could have been because there is no SDR on webOS like in the case of grabbers (even when the input signal was in SDR format). It is the same mode that requires correction like HDR or DV. So if we are dealing with calibrated LUTs, tone mapping must always be active to apply this correction from the selected LUT. |
|
So my system isn't working correctly when HyperHDR shows: [FLATBUFSERVER] (LutLoader.cpp:74) Index 2 for YUV when I switch from HDR to SDR? If I toggle HDR in HyperHDR when watching SDR content, the live preview is barely different. Only a slightly red hue is added to the picture. HDR toggle off looks like Warm40 on LG OLED's white point settings and HDR toggle on looks like Warm50. When I toggle HDR on while watching SDR, HyperHDR shows the same lines in the log. So in both cases the same LUT is "found and loaded", doesn't matter if the toggle is on or off. |
Does this LUT is calibrated for SDR? Or it's shipped with the package on webos?
Index 2 is just basic decoding NV12 to RGB without any correction from the calibration (tone mapping is DISABLED). Index 1 is calibrated for NV12 and Index 0 is calibrated for RGB (tone mapping is ENABLED). |
|
The lut_lin_tables.3d file is the calibrated SDR LUT. I have three LUT's, one for SDR, HDR and DV. |
|
There is a verification procedure for SDR: #1000 (comment) |
This indicates that you have disabled tone mapping in flatbutffers configuration if Index does not switch to 1 when you enable tone mapping. |
|
Hello, Here I have made the change: |
|
@satgit62 Thank you but I'm not really sure if I should do that. I need a way to have different LED gamma values at different picture modes and if HyperHDR is in HDR-always-on mode that wouldn't work anymore |
I don't know what the final effect will be, but since AI is currently very popular ;) Let's use Deep Learning Function Approximation to calibrate SDR/HDR/whatever video source. We will use Python and its related libraries here but it is an optional functionality and you do not have to use it nor will we install it: it must be present in the system.
But first, let's sort out the calibrator code because it needs cleaning before further work. We will use a new library for linear algebra that will help us.
Main changes (non-AI):
Old method using Windows 10 and a web browser is no longer mandatory, you can use the old method using browser or simply play the video test file in your favorite video player.
New algos that support even video source trans-coded to full BT2020 range and provide better quality
Captured colors are saved in the HyperHDR directory after calibration as calibration_captured_yuv.txt and can be provided to me for analysis if I have some spare time.
Support only for YUV/NV12/MJPEG modes. RGB mode is not supported anymore.
Confirmed support for webos calibration with backend that supports NV12 flatbuffers communication. Each webos mode (SDR/HDR/DV) may require its own calibration.
Grabber benchmark supports flatbuffers source
Video source noise detection
multi-threading support for calibration and LUT creation. But what we gained by using all cores went to...
LCH color corrector. Jokes aside, this algorithm eats up huge amounts of CPU resources, but I think the effect is worth it because we get clean main colors and I didn't notice any side effects. If anything, you can disable it. More at the end.
Increased the number of test vertices focusing on the most problematic issues: yellow (green shift) and magenta (red shift).
USB grabber and flatbuffer server are disabled during calibration to save resources. We enable them at the end. Known issue: there is some issue on the webos client side that does not detect that the connection has been lost and does not reconnect it later. You have to manually restart the piccap service.
Added PQ in sRGB linear signal detection for AV access grabber. You can see in the first post what this grabber is capable of due to its wide range, it avoids quantization characteristic of all other grabbers.
Added 2-step calibration which allowed to speed up the whole process. The first step is general and is only intended to detect the appropriate tactic. The second step is detailed.
Moved calibration to a separate thread. Thanks to this we do not block the interface which now displays information about the progress on an ongoing basis.
Change some backlight behavior: only turn on the background light if the LED would otherwise be off.
If calibrating using Windows (using the web browser or the video player as a video source) please disable features like 'Night mode' or 'Auto-HDR'. Do not change the color balance in your graphic driver.
Video test files:
https://github.com/awawa-dev/awawa-dev.github.io/tree/master/calibration
Use SDR video only if your OS or video player will automatically apply SDR to HDR tone mapping. Or if you are calibrating eg. webos.
The web browser method and playing yuv444 file usually provides the best calibration quality but yuv444 is supported probably only by the PC players. yuv420 has better compatibility but worse quality (the risk the player is starting using its own filters like dithering).
Presenting capabilities of new tone mapping algos:
Source desktop (Windows 11 HDR enabled):
AV Access 4KVC00 (this wide-range grabber was ahead of its time + HDR/SDR detection on the COM port 👍 )
Captured by MS2130 (F3 firmware !!!) with and without tone mapping: