error using tuning tool for rpi5

[JeanPoire]

Hello, I am currently trying to use the ctt tool to generate a tuning file for my camera. I captured all the images and named them according to https://datasheets.raspberrypi.com/camera/raspberry-pi-camera-guide.pdf .

I am facing some error during the AWB calibration: SVD did not converge in Linear Least Squares. (cf attached pictures)

I found this related topic #49 but the answer given to check the black level did not solve my issue.

I started to debug, and I realized that the tool is perfectly working for vc4 with the same calibration images. I did dome printing to find the difference

when I run for vc4 or pisp and I discover that the variable colourcals is always set to nan when I run for pisp.

Do you have an idea from where this issue can come from?
Thank you very much for your time and support,
best regards.

[naushir]

@davidplowman

[davidplowman]

Hi, I've not seen anything like that before. Quite honestly, rather than messing around with lots of over-the-internet debugging, the easiest thing might be to upload your calibration images somewhere so that we can try them for ourselves. Would that be possible? Thanks!

[JeanPoire]

Sure! Here are the captures. I am really sorry, I was not able to upload directly the zipped folder of all the captures I had to upload them one by one. My apologies for the troubles.

2400K_2100l.zip
3000K_950l.zip
5000K_1350l.zip
6500K_1440l.zip
alsc_2400K_1.zip
alsc_2400K_2.zip
alsc_2400K_3.zip
alsc_2400K_4.zip
alsc_3000K_1.zip
alsc_3000K_2.zip
alsc_3000K_3.zip
alsc_3000K_4.zip
alsc_5000K_1.zip
alsc_5000K_2.zip
alsc_5000K_3.zip
alsc_5000K_4.zip
alsc_6500K_1.zip
alsc_6500K_2.zip
alsc_6500K_3.zip
alsc_6500K_4.zip
cac_2400K.zip
cac_3000K.zip
cac_5000K.zip
cac_6500K.zip

[davidplowman]

Thanks for sending those. I've had a look at what's going on and have fixed a couple of things. You can grab the ctt-fixes branch (see #257) if you want to try it.

There were a couple of obvious problems, a regular bug in the LSC calibration, and then the CAC calibration was failing in a bad way instead of giving a sensible error message.

1. LSC

Here, in some respects you were "unlucky", because your image happens to tickle a numeric corner case. It's the image height of 1364 and, for Pi 5, the need to divide this into 32 cells, that was causing some off-by-1 problems. The first commit I added to the ctt-fixes branch should take care of this.

2. CAC

Here the problem is that not enough of the images contain the "black dots" where it wants to take measurements. This was causing it to produce more Not-a-Number values. I've patched this so that it will print a warning message and not produce a calibration (so CAC is disabled).

A couple of Suggestions

To be honest, the number of occasions I've seen where CAC makes any difference is extremely small, and I don't see big problems here, so I'd be tempted simply to remove those images.

The LSC calibration images look somewhat "unflat" to me, I don't know how sensitive your application is to this, but I would worry that illumination highlights from the lighting is going to be affecting your tables. My life improved a lot when I started using a cheap LED video lamp, with a 3000K and 5000K dial. Even though it has some imperfections it was just so much easier to use that I got much better results. Maybe that would help you too?

Anyway, let us know if that code branch helps, and then we can get it merged.

[JeanPoire]

Thank you very much for your help, I was able to run the tool with the new branch.
However, the json produced seems to not work. The error messages are not really explicit could you provide some support on it.

vd56g3.json

[davidplowman]

Edit: actually I'm not sure what's going on. I'll give the tuning file a try on my system.

[davidplowman]

Right, so I've had a go now with the tuning file that I made from your images yesterday. For me, the tuning file loads and runs fine - obviously I have a different sensor, so the images are a slightly funny colour, but nothing is failing.

Normally I'd expect to get some kind of a complaint if a tuning file fails to load, and I don't see your file mentioned, so I wonder if it's not looking for it, or not finding it?

You can force it to use a specific tuning file like this:

LIBCAMERA_RPI_TUNING_FILE=/path/to/your/tuning_file.json rpicam-hello

so you could experiment with that and see if it makes a difference.

You might get some more helpful debug information if you set the LIBCAMERA_LOG_LEVELS variable, like so:

LIBCAMERA_LOG_LEVELS=RPI:0 rpicam-hello

I was slightly bothered by some of those messages talking about IPCPipe and IPAProxy. libcamera has a mode where it runs IPAs (control algorithms) in a sandbox process, but that shouldn't be happening on the Pi because we distribute source code. So I'm not sure what's going on there, or if it matters. I assume you're building libcamera in the usual way, having added your tuning file and cam_helper?

[kbingham]

Those IPA errors mean you need openssl or libgnutls when you build ilbcamera (and available at runtime).

https://git.libcamera.org/libcamera/libcamera.git/tree/README.rst#n52

for IPA module signing: [recommended]
Either libgnutls28-dev or libssl-dev, openssl

    Without IPA module signing, all IPA modules will be isolated in a
    separate process. This adds an unnecessary extra overhead at runtime.

The Raspberry Pi doesn't run (correctly?well?) in isolated mode - which happens if the signatures can't be validated - and because we expect RPi to have valid signatures - I don't think anyone has investigated why the IPA doesn't run well in isolated mode.

[JeanPoire]

Hello @kbingham, I installed openssl and I have now a new error:

Any ideas to solve the issue?

[kbingham]

That explains why the IPA was failing to load before, and when run in isolated mode (before you installed OpenSSL) that error was likely happening but being lost as it reports in a different process so you couldn't see the error message.

The IPA is reporting an assertion on the colour temperature curve parsing.

So I would recommend reading the assert at the log line mentioned. And then try to see why it can load what it expected or needs from the tuning file.

[kbingham]

Interestingly the code looks like it already has checks before it parses the list, but then there is an issue between the position and the content of the incoming ctR?

[davidplowman]

Not clear to me why that assert should be firing. Both the vc4 and pisp tuning files that I made from the calibration images have this:

                "ct_curve":
                [
                    3000.0, 1.2153, 0.4581,
                    6500.0, 0.6714, 0.7544
                ],

which seems fair enough (and as I said, loaded OK for me). Can you check the equivalent bit of your tuning files?

[JeanPoire]

Hello @davidplowman, thank you for your comment. I realize that I had two lines for ct 3000 because I had two calibration pictures @3000k for two different lux levels. I removed one and it is perfectly working now. Thank you all for your support!

[davidplowman]

Great, glad it's working!