Allow LUT calibration when no USB grabber is present

[awawa-dev]

Allows to use other than USB video source for the HDR to SDR tone mapping LUT calibration, when the grabber is not present or the video grabber support was disabled in the build configuration.
Should make the calibration work e.g. for Webos graber-less build.

[satgit62]

Hi, since there is no documentation here for the LUT calibration for LG webOS, wanted to know if the calibration for webOS still requires using a Windows computer capable of displaying HDR content and having HyperHDR installed. The Windows computer must be connected to the HDMI input of the TV so that the calibration page is displayed on the TV screen (as HDR content) and live preview in HyperHDR (captured by the grabber). Does HyperHDR then have to get data from webOS Grabber via flatbuffer, or the calculation simply follows via the instance screen capture with priority 245 and the tone mapping from HDR to SDR in software screen capture should be switched off?
What is the best way to proceed here?
Thanks in advance.

[asturel]

I'm also unable to get calibration to start with flatbuffer, seems like the LutCalibrator::assignHandler method:

HyperHDR/sources/utils/LutCalibrator.cpp

Line 106 in 5950b22

void LutCalibrator::assignHandler(hyperhdr::Components defaultComp, int checksum, ColorRgb startColor, ColorRgb endColor, bool limitedRange, double saturation, double luminance, double gammaR, double gammaG, double gammaB, int coef)

never called when flatbuffer is the source (I tried adding extra logging by asturel@caa2bc8). The JsonAPi lut-calibration method returns

{"success": true, "command": "lut-calibration", "tan": 1} 

HyperHDR/sources/api/JsonAPI.cpp

Line 1346 in 5950b22

sendSuccessReply(command, tan);

But there's nothing in the logs with "CALIBRATOR".

[awawa-dev]

Hi
It's very outdated sources but it's invoked by

HyperHDR/sources/api/JsonAPI.cpp

Line 1342 in 5950b22

emit LutCalibrator::getInstance()->assign(getActiveComponent(), checksum, _startColor, _endColor, limitedRange, saturation, luminance, gammaR, gammaG, gammaB, coef);

via signal.
I just want to explain that the changes in the beta were available for 3 months for testing and you could then submit comments that were taken into account on an ongoing basis. Currently, I'm taking a long well-deserved break from coding after the release of v20. The configuration without a grabber is not included in my tests because I treat it as a niche setup and I dont have grabberless setup like WebOS (BTW which limit performance of calibration by performing YUV to RGB conversion on its own). But of course, if you find a problem and are able to propose a solution, open a PR. If I have an idea, I will try to advise you.

[asturel]

Thanks, yeah sorry for that, I found that call, but "for some" reason the connected signal actually never runs in the lut calibrator, my guess was the same: its because we have no grabber, I've checked the ifdefs, some events but couldn't figure out, i hoped you have some idea how should/could debug this. Thanks for v20, enjoy your deserved relaxing.

[awawa-dev]

Thanks. The model (both calibrator and grabber handler) was rewritten before beta1 and it has changed completely. But now that I looked into current code the issue may be here:

HyperHDR/sources/api/HyperAPI.cpp

Line 1031 in 52f12b4

_lutCalibrator->incomingCommand(_instanceManager->getRootPath(), _videoGrabber->grabberWrapper(), getActiveComponent(), checksum, _startColor, _endColor, limitedRange, saturation, luminance, gammaR, gammaG, gammaB, coef);

it should be checked for nullptr:
_lutCalibrator->incomingCommand(_instanceManager->getRootPath(), (_videoGrabber != nullptr) ? _videoGrabber->grabberWrapper() : nullptr, getActiveComponent(), checksum, _startColor, _endColor, limitedRange, saturation, luminance, gammaR, gammaG, gammaB, coef);

[asturel]

Thanks, turned out the issue was "related to grabbers", I haven't checked that the issue is persist on the latest codebase, but it was the following:
Every grabber ctor registered the ColorRgb metatype:

qRegisterMetaType<Image<ColorRgb>>("Image<ColorRgb>");

, but since we had no grabber, we run into this error:

QObject::connect: Cannot queue arguments of type 'ColorRgb'
(Make sure 'ColorRgb' is registered using qRegisterMetaType().)

[awawa-dev]

Strange... the type is registered when the main daemon starts

HyperHDR/sources/hyperhdr/HyperHdrDaemon.cpp

Line 89 in 52f12b4

qRegisterMetaType<Image<ColorRgb>>("Image<ColorRgb>");

[awawa-dev]

Probably ColorRgb could be also registered there.

[asturel]

I dont know why, but qRegisterMetaType<Image<ColorRgb>>("Image<ColorRgb>"); didnt worked for me, only qRegisterMetaType<ColorRgb>("ColorRgb"); (i did it in LutCalibrator ctor)
(I'm not really familiar with qt, sorry for being noob :D)

[awawa-dev]

If the Image type was not registered, you would not have a preview in the live preview window because it is also sent there by signals. I suspect that in the older version this could have resulted from a different life cycle of the calibrator (the moment in which it was created), but this was later changed. You will definitely need a fix #518 (comment) in the latest version and it should work.
BTW you probably also need to disable tone mapping in flatbuffer before you start calibration. Otherwise strange things may happen.