Add support for Artificial Intelligence LUT calibration #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
|
And with latest BT.2100 OOTF detection is even better: So webos is using HLG inverse OETF but later it skips OOTF . |
@awawa-dev Hello, |
|
I have tested this the last couple hours:
Thank you all so much for this changes. This new method and the changes to PicCap made Ambilight fun again :) |
with hyperion-webos only 1080p works without errors about noise and resolution
I have similar thing, but I'm still in testing) my picture has a bit of a greenish tint to it.... can't get a consistent result (gods know what happens in webos)
Yes, you need to bypass the conversion from NV12 to RGB in the hyperion-webos backend - you can try that with my modifications (I think it's here https://github.com/s1mptom/hyperion-webos/actions/runs/10435701393) |
When using the old calibration method, I was able to get around that MaxLuminance thing by just deactivating HDR in windows before calibrating. Picture looked the same but with super accurate Max Luminance |
I can confirm there was a problem when the grabber resolution wasnt set to 1080p. It's fixed now
Currently our HDR video test files are calibrated for ~200nits but webos (or nvidia with tone mapping) can disrespect this depending on some settings and the brightness must be detected. What is more interesting webos is changing gamma from PQ to HLG even if the source material is using PQ gamma. There is possibility to provide test files for other than 200 nits target brightness using ffmpeg.
Yes, I completely dropped RGB for calibration due to many unpredictable problems so standard flatbuffers/RGB wont work. You need webos client using flatbuffer/NV12.
We are just starting...BTW by pure accident we calibrated also full Rec.2020 thanks to NVidia Shield tone mapping ;-) And can anyone help us with converting our test video files from HDR10 to DV? :-) Probably special software is necessary. |
That was the weird part, PicCap is always set to 1920x1080-60 when I start calibrating. I have tried setting ATV to 1080p too, no dice. But the new version works perfect, no errors, every board is immediately captured. Processing is noticeably faster too. Thank you for the quick fix!
I always look at the log and the numbers after calibrating and I was never able to see a higher nit score than 90. Is this good or bad? I know SDR brightness is around 100-120 nits so I guess I should be close to SDR norms? Or should I see a score closer to your mentioned 200 nits target? One observation: When I change the video format in webOS from Auto to Full, the nit score drops from 90 to around 50. The LUT looks much closer to the screen when I select the wrong video format. If I calibrate with Low video format, I get 90 nits and a superbright image. In terms of accuracy, it's way too bright. In my case, this is good because I can use 2.0 LED Gamma for both SDR and HDR. But in terms of pure accuracy it's way off. When I select the wrong video format, it's way more accurate. This was a observation with the old calibration method too, if I set LG to Low HyperHDR says Full detected and vice versa. Is this the desired effect? |
|
Well this part is unclear to me why webos treats it this way. Since it can transform the image from PQ to HLG anyway it can also ignore the original brightness: why it does this - I don't know. Maybe because this stream also is used for its video recorder and HLG will handle SDR and HDR and it also applies all the possible user settings from the LG menu? In the case of SDR @s1mptom provided me with the logs and here is an additional thing I need to pay attention to: Look at WHITE_0. Despite the fact that YUV was detected as limited and that after processing and deleting limit in RGB is still limited in the range of 16-235 (or 29-217 YUV)... but it may not be about YUV anymore but about the TV range of 16-235. If you are able to calibrate on the SDR file, see if the captured brightness behaves the same and provide me calibration_captured_yuv.txt file after the calibration. if that is confirmed I can handle such situation. But 2 of 3 LUT tables will be necessary (HyperHDR can switch them on fly and webos also can detect HDR/SDR type of video input). |
Hi, |
I will do a sample SDR calibration later and attach the .txt for analysis. I`ve done some testing with SDR calibrating and I have to say, this is the way to go for my setup. If I calibrate with the SDR test file, I get a much higher score (around 3000) but also a much higher nit score. Depending on how you setup your LG SDR picture mode, I got a range of 450-660 nits reported by HyperHDR. This also eliminates the Maximum Luminance behaviour, as you can see in my attached screens, this is Dolby Vision: New calibration method with HDR420 test file image
New calibration method with SDR420 test file image
Photo of TV:
The second live preview snapshot is actually much closer to what's on the screen in terms of colors, even if it does look the other way on my photo. I have also looked at how to convert that hdr file to dolby vision but if I try to extract the HDR metadata from the test file, every tool says: No HDR Metadata available I have send the MediaInfo for that file to some internet guys and the answer I got was this: "Yeah this doesn't have the correct HDR10 metadata. Your TV probably is ignoring the missing metadata and assuming HDR because it's PQ Rec. 2020." I don't know how correct that is but it would match the errors I got when I try to extract the metadata |
|
@NatyaSadella I'm not an encoder expert, just try to use ffmpeg for YUV420 there should be HDR metatag ( but I can be wrong and there is still a room for improvement |
I`m still using HyperHDR on computer with the new backends for piccap you send to me a couple of weeks ago. Trying to get the new backends to run with HyperHDR on webOS results in endless "Socket closed" errors. Only with a vanilla installation of PicCap it works again but then I can't use the new calibration method because of NV12 errors. After endless re-installs and reboots I just gave up on it. |
PicCap is not related to NV12 support, you need @s1mptom hyperion-webos backend fork |
I will look into that, I have just replaced the backend files. I have now come a little further in the calibration and have done some fine-tuning to the webOS settings and getting closer and closer. I don't know if the old "the lower the better" score still counts, but I got a score of 56 instead of 3000 and above for the first time during an SDR calibration. Nit Score says 445 nits and the LUT looks like the best of both worlds. Very good brightness as with the HDR calibration with only a very small bit of maximum luminance errors: SDR cal new:
SDR cal old:
HDR cal:
|
|
Ok, I've just added support for SDR/SRGB calibration so we have another progress and more surprises:
So calibration using old methods were invalid for webos at least for such input data. To avoid ambiguity, I still base my development on @s1mptom provided results, which in this case he obtained using an SDR test file using his fork which supports calibration via NV12 (results attached). Regarding these captured colors (#896 (comment)) here is the result |
|
ohhh boy and I thought I was done with calibrating for tonight 😃 @s1mptom @awawa-dev Absurdly great score, what webOS SDR picture mode did you use and what were the settings you choose for like contrast or color depth to achieve this score? I need to replicate this, the best I saw was a score of 14 now but the LUT was super dark. I've tried to lower the contrast so the LUT gets brighter but on the level I need, sRGB gets lost and it's HLG again. Was this a tonemapped SDR calibration or a raw sdr calibration? Just to clarify. I do not tonemap in HDR/DV while calibrating with the sdr420 file and want to make sure I'm doing it right. |
|
Hi,
|
New calibration_captured_yuv.txt format
|
LG C9 libdile_vt (GUI capturing disabled),yuv420_hdr test file, windows10 + HDR, 1080p for calibration, excellent score better than most grabbers. HyperHDR (v21 from this PR) runs on the external PC. Captured colors: calibration_captured_yuv_c9.txt New version from @s1mptom with manual: still in early testing phase so you run it on your own risk, must restart the webos service few times to make it work properly |
|
Yep the score can get very very low when you tweak some things. That brings another question to the table: If those scores are better than what USB grabbers can achieve.. isn't this the perfect time to create a PicCap successor or at least officially support webOS now? A Awawa-made webOS grabber with HyperHDR and HyperSerial in mind would be awesome. I mean we are still at version 0.4.3 and we need a totally modified version of PicCap now with HyperHDR v21. It doesn't look like PicCap is in development anymore so all changes to HyperHDR from now can not be used by webOS users when v21 launches. I know your time is limited and you run on limited resources. But to be honest, we need a new webOS grabber, PicCap is a dead end. Unrelated to the grabber idea: Is AI in use now and fully implemented or is this feature still to come? If it's not implemented yet, what can we expect from this when were hitting scores of 3 right now without it? What could be the real benefit for HyperHDR and how could AI help with the calibration process? |
Personally I do not have such plans.
Changes to piccap would be minimal (new option to enable NV12). The key for NV12 support is in the @s1mptom backend. Who knows...Maybe we'll see hyperhdr-webos someday? But not in HyperHDR project. There are still many unknown factors, when we switched to libdile it turned out that SDR behaves differently than in the second system, gamma is shifted differently and the colors are no longer in sRGB. More tests are needed, but at least HDR works perfectly. I still focus more on USB grabbers.
I treat it as an interesting experiment, I don't know what the result will be, although @s1mptom has already started working on it. I will also investigate other approaches, although I assume that the system based on ITU equations will be more accurate if we decipher all the paths in which the video was processed. If we can't determine this, then AI should step in, although there is always a risk that it will start hallucinating. |
|
Added SDR support for libdile (and maybe other TV models): turns out it's BT2020 with sRGB gamma. My PC player played a trick on me and I had to reset its settings to default because it was working on HDR settings. Anyway, I have confirmation with the yuv420_SDR file played in Windows (with HDR disabled using madvr) and from the USB drive using the LG player: madVR/WIndows10/HDR disabled:
Internal LG C9 video player yuv420_sdr file:
on the other hand using LG player to calibrate HDR file is not a good idea: the LG player tone mapping is very aggressive although the colors are still acceptable despite high error:
At the moment it seems to me that all webos paths are supported. Tests show that using test video files makes calibration much easier, but on the other hand there is a factor that was not there before: various player enhancers or other settings that the user has enabled, so you have to be very vigilant and control everything. The rest is now in the hands of users. |
I don't know what the final effect will be, but since AI is currently very popular ;) I willlet'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 nNew library for linear algebra herewill help us.
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.
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.
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.