Describe the process of color calibration

[asm0dey]

Feature request

What problem does this feature solve?

Currently it's not clear how to match my wled + led strip colors to the colors on my TV

What does the proposed API look like?

It might be just a page in docs somewhere, like this one
https://github.com/AEtHeLsYn/hyperion/wiki/Color-Calibration. I imagine it's somewhat outdated, given it's for another product and 8 years old.

How should this be implemented in your opinion?

But in a perfect world it's should be android app, of course, that looks at pictures of TV with ambilight enabled and changes settings on the fly

Are you willing to work on this yourself?

I'm not sure. I can help a bit, but I'll not sure how

[awawa-dev]

Hi

Would you like to know my opinion and an explanation why I didn't create such a guide myself? Because it would require a model behind this process and it does not exist. There are individual concepts there (like gamma correction or HSL), but they have nothing to do with this subject as a whole... so it's something like voodooo or something that could be more neutrally described as a dynamic and holistic process of adapting the LED characteristics to the individual user preferences 😉 The mechanism itself is transferred here from Hyperion (classic one with HSL model, originally removed in Hyperion.ng, present from the beginning in HyperHDR, after a few years it made a mysterious come-back also in Hyperion.ng) and Hyperion.ng (more advanced with a lot of options, which no one really has a clue how they work, but they exist... unfortunately, user friendly HSL is removed) when I forked the project in 2020.

You usually want to apply color correction if for one of the following reasons... or more than one, which only makes the problem more hopeless:

• Change of LED characteristics, unfortunately, but each component in the case of RGB diodes has different non-linear characteristics and it's nice if you manage to calibrate the board that displays light purple... but it will most likely diverge a bit at lower brightness levels. But the biggest problem is white and shades of gray to which the human eye is particularly sensitive. All RGB LEDs that I had the opportunity to test are shades of blue and this cannot be corrected using this calibration.
  The solution is to use the recommended RGBW LED, which have a separate channel for this purpose. Only we can't correct it in this respect, so if you choose the neutral version instead of the cold version, gray or white will be a bit yellowish.. we can only correct the shades and we will force to decrease usage of the W neutral channel, but not here because the calibration works on the RGB model, so you have to do it in the driver settings for the protocol I created for HyperHDR (which also magically appeared in Hyperion.ng some time ago), e.g.: Adalight HyperSerial or HyperSPI.
  
  As an interesting fact: using the calibration available in the AWA protocol, you can turn off the white channel for a moment for testing purposes and convert sk6812 RGBW to RGB. Then you will see with your own eyes that suddenly the displayed white color (255,255,255) which was previously displayed as white on the LEDs suddenly became bluish. And this is what the everyday life of RGB LED users looks like, but they cannot turn the W channel back on. And we can't fix it... we can't even solve the simple task of calibrating to achieve pure white on an RGB LED strip across the entire brightness spectrum due to non-linear behavior of LED R/G/B color components. So why we should be able to fix other similar LED colors issues with the calibration?

• Correction of certain user preferences. We want very expressive colors in bright scenes? ok, we increase the gamma or saturation in HSL. Only in a moment we get very distorted and disgusting colors in dark scenes. We have a beige wall behind the TV. Ok, let's reduce the share of red component. Sisyphean task in an advanced calibration model, it is much easier to do it in the old one (the one with HSL) where there are only the basic red, green and blue components. But even if you removed the red color completely, it would still appear after diffraction on the beige wall.

• I'm sure the whole calibration process is not about calibrating the application for displaying static test boards, but about ensuring that the LEDs display colors that reasonably well reflect the colors we have on the TV. To do this, we must have a relatively real captured image. This usually works well for SDR, but in the case of HDR you cannot convert SDR to HDR using e.g. HSL. The calculations are so complex that currently they cannot be done in real-time, but we can do them in advance and save them. This is where LUT comes in, the support of which led to the birth of HyperHDR. But it was a long time ago and many other things were added, often having absolutely nothing to do with HDR, and existing concepts were optimized, because what good will even LUT do if you have inefficient video processing?

To summary:

• do not use calibration because there is no model that would be the basis for the entire process. So all you get is a kind of placebo.
• you use calibration because you think it makes the colors more pleasant for you? That's totally fine, keep using calibration. That's why it's in HyperHDR 😉 All to make the user satisfied.

I hope you now understand whether such a guide has not been created or will be created (at least for the current mechanism in the processing tab) and why I will not remove the calibration from HyperHDR 😉

[asm0dey]

I think the most important part is not having a "perfect white", but having colors matching TV as close as possible. My TV is constantly running is the "Night shift" or whatever this thing is called when the level of blues is lower than it should be.

So yes, my goal is not to make the colors pleasant, my goal is to make the match TV's colors as good as possible to have this "augmentation" effect. And this thingie, I think, can even be automated, at least for SDR.

And yes, I totally agree that the gamma correction is to make LED colors match TV colors. And I don't think it's voodoo, At least for static images, it should be quite a deterministic process, I just don't understand how to perform it.

[awawa-dev]

At least for static images
...
my goal is to make the match TV's colors

So these are exactly the cases no. 1 and 3 described by me 😉 As I have already explained, from my point of view it is unrealistic and I will not undertake it myself, but I am open to suggestions along with their possible implementation in the code if changes are needed. So I leave this request feature opened for others.

[asm0dey]

I think the current code shouldn't be touched at all, it's more a question of an external android/iOS application, that takes photos and tunes parameters accordingly. Contrary to the human eye phone can catch differences and the tune settings very quickly.

But I get your point, thanks for the answer