Flatbuffer calibration

[Benik3]

Hello.

Is possible to make calibration on flatbuffer?
I tried it and in log I got error [V4L2:AUTO] Could not find any capture device , but for flatbuffer there is of course not V4L2 device.

I'm working on project of grabbing using camera and sending it to flatbuffer. I have it working, but color calibration even for SDR is very appreciated, so I wanted to use the function of HyperHDR to load 3DLUT.

[awawa-dev]

Hi
Yes, it should be possible to calibrate using only flatbuffers. Your error suggests rather that some wild & unofficial version of HyperHDR is used (with completely removed grabber module while building). USB grabber isn't necessary but the module e.g. v4l2 for Linux should be left intact while building because LUT calibrator depends on it.

[awawa-dev]

OK, I reproduced it on my system. I will take a look if it's possible to find a solution.

[awawa-dev]

But I think it wont work for the camera anyway. Each calibration frame has a signature (embedded in the image in specific location) and capturing using camera won't catch it.

[Benik3]

I'm using official Release on RaspBerry Pi 4 with Raspbian OS Lite 64bit. No custom build.

But I think it wont work for the camera anyway. Each calibration frame has a signature (embedded in the image in specific location) and capturing using camera won't catch it.

I was afraid about this. I will try it and I will see. Maybe something like Argyll Dispcal would be better option for this, but don't know if it's even usable this way (without real calibration instrument).

I have at home a colorimeter so I will try to overcome it with it. Unfortunately the instrument doesn't like output of the LED strip, so I can't calibrate directly the output from LEDs. But at least calibrate the camera output.

[awawa-dev]

Using a colorimeter offers alternative solution. But it would require some programming skills to change the code a bit and pass the captured values for around ~20-30 test colors/gray directly to the calibration procedure instead of capturing them from the video source like grabber or camera.

[Benik3]

I have a two proposal of improvement, which I discovered while working with HyperHDR:
1 - Show LEDs in live view with their "full color" (now they are partially transparent and darker).
2- Have a button for showing live view in 1:1 resolution. Or at least make the screen shot in native resolution. This can help to check the grabbed image.
What do you think?

[awawa-dev]

1. Maybe I implement it as an option because some LEDs area are very large e.g. Philips Hue and probably we don't want to hide the preview stream completely. Unfortunately then is little room to add more buttons in the live preview dialog. Maybe multiple mouse click on the 'show the LEDs' button to switch the mode?

2. I have spent a lot (really a lot) of time troubleshooting this preview feature. On Rpi when certain circumstances are met, the preview can even crash your system. And there are multiple reasons causing this. It happened despite the fact that the frame is compressed to jpeg format to reduce the size before sending to the client (which already causes loss of quality). I think it is now fixed, well balanced and above all is stable, so I will not touch it again in the near future ;)

[awawa-dev]

@Benik3 I forgot that there is already option for developers to make a screenshot 1:1 taken directly from the video grabber processing. It's not in the live preview and you need to enable it in the code.

1. fork the HyperHDR and enable github action
2. in your new HyperHDR repo (not mine ;) ) edit following file
3. Uncomment

   HyperHDR/sources/utils/FrameDecoder.cpp

   Line 32 in d5564ff

   //#define TAKE_SCREEN_SHOT

4. Adjust the screenshot destination

   HyperHDR/sources/utils/FrameDecoder.cpp

   Line 105 in d5564ff

   jpgImage.save("D:/grabber_yuv.png", "png");

   (warning: the are multiple such lines in this document and you need to adjust them all, works for Linux and Windows paths as you like)
5. Click the save button. Github Action will compile the installers for you.

300th frame is captured and save to the disk for analysis. You can adjust this parameter in the same source file.

You can adjust it to capture also the flatbuffer source, because the capturing procedure is using typical Image object used in HyperHDR for the frame storage, converts it to the QImage and stores it on the disk.

[Benik3]

1 - True, maybe toggling off - partial transparent - full color with the one button
2 - Ok, I understand :D Thanks for pointing the developer function.

[Benik3]

I'm thinking about something like simple node.js app, which will show a color of LED sent e.g. by UDP RAW protocol from hyperHDR. I know that this will bring some inaccuracy due to measuring on monitor, but because I can also calibrate the monitor before (and I have pretty good VA monitor with high color coverage) it should be negligible.