Program halts before writing file with -t 0 flag

I’m working with an Arducam IMX230 (Pivariety) on a Raspberry Pi 4 running Bullseye. I’m trying to use a custom lens with it and need to apply a lens shading correction. I’ve been trying to generate a tuning file and update the firmware, but I’m running into all sorts of issues. First off, when I run libcamera-still -t 0 -o test.jpg, the program just hangs indefinitely and never writes the file. Any ideas?

The -t 0 flag sets an indefinite delay in milliseconds, so the camera waits forever before capturing. Try changing it to -t 1 (or any positive value) so it captures after 1ms and writes the file:

libcamera-still -t 1 -o test.jpg

That should resolve the hang. Let me know if that works, and then we can move onto the lens shading and tuning file issues.

Yep, -t 1 fixed the hang, thanks. Now I’m onto the bigger issue — I need to generate a custom tuning file for this IMX230 with a third-party lens so the lens shading correction works properly. I’ve been reading the Raspberry Pi camera guide (https://datasheets.raspberrypi.org/camera/raspberry-pi-camera-guide.pdf) about generating tuning files, but what’s the actual process for updating it on the Arducam module?

Good, glad that worked. For the custom lens on the IMX230, you’re right that you need a custom lens shading table (LSC) in a tuning file. The process is:

  1. First, you need to generate a tuning file — but the update method for the Pivariety cameras is a bit different from stock Pi cameras.
  2. You’ll need an integrating sphere and a colorimeter to produce a proper calibration tuning file.
  3. Once you have the tuning file generated, I can provide you with a firmware update tool to write it to the device.

Do you have access to calibration equipment? If so, let me know and I’ll send the update tool.

I managed to get hold of an X-Rite MacBeth ColorChecker (Callibrite Classic) and took a set of calibration images. Here’s the set I shot: https://www.dropbox.com/s/qi4wrn6923cznne/Calibration_Image_Set.zip?dl=0

I generated a calibration file and tried using the update tool you mentioned. I ran:
./firmware_update -m imx230_lanes2_firmware -i 10

But I got this error:

Still capture image received
Bayer format is BGGR-10
1.dng: Failed to allocate memory ...
Assertion `datalength<0x80000000UL' failed.
Aborted

What’s going on there?

Ah, that error looks like the old update tool is having trouble with the new firmware format. A couple of things to check:

  1. The new tuning file is gzip-compressed, which is a different format from the original firmware. I realize I packaged the wrong executable with that last message — sorry about that. Let me send you the correct update program.

  2. Also, when you transfer the new update program to the Pi, make sure you’re using binary mode for the transfer, not ASCII mode. If you get a segmentation fault when running it, that’s usually the cause — just re-transfer in binary mode and it should go through.

Okay, I got the new update tool you attached and transferred it in binary mode. The firmware update went through this time. But now when I capture images with the new tuning file applied, there’s a noticeable green smudge in the center of the image. The calibration images I took were of the ColorChecker under good lighting. Any idea what’s causing the green tint?

A green smudge usually indicates the lens shading table isn’t calibrated correctly. A few things to check:

  1. Were the calibration images taken with the lens focused at infinity? For LSC calibration, you want to capture a uniformly illuminated flat field (like an integrating sphere or a well-lit white wall), and the lens should be focused far away — not on close objects.

  2. How obvious is the green? Is it a slight tint or very pronounced?

  3. Can you send me both the calibration image you used and a sample image after updating the tuning file? That would help me diagnose what went wrong.

Additionally — a note for the future: there’s currently no way to set the focus area to a centered square of definable size in the stock libcamera stack, so if you need that functionality, keep that in mind for your project.

The green is pretty obvious in the center. Also, I tried running libcamera-still again and now I’m getting a new assertion error:

libcamera-still: ../src/ipa/raspberrypi/controller/rpi/awb.cpp:45: 
void read_ct_curve(RPiController::Pwl&, RPiController::Pwl&, const ptree&): 
Assertion `it == params.begin() || ct != ct_r.Domain().end' failed.
Aborted

Looks like an AWB crash this time. And to answer your question — no, I didn’t focus at infinity. I was shooting the ColorChecker up close. Should I redo the calibration?

Yes, definitely redo the calibration with the lens focused at infinity on a uniformly lit surface — that’s likely the cause of the green smudge.

For the AWB assertion error, here’s what’s happening: the tuning data on the device is corrupted/incompatible with the current libcamera build. Use the empty_tuning_data update tool I’m attaching to clear the tuning data from the device first. Then specify the local JSON tuning file directly when running libcamera-still:

./empty_tuning_data
libcamera-still -t 1 --tuning-file custom_2_imx230.json -o test.jpg

That should bypass the corrupted on-device data and use your local file instead.

Clearing the tuning data and using --tuning-file worked — no more AWB crash. I also shot new calibration images with the lens at infinity and generated a fresh tuning file. The green smudge is much reduced but still slightly visible in the center.

Also, I noticed that when I remove the lens mount completely (to test without autofocus), the camera stalls with this message:
INFO RPISTREAM rpi_stream.cpp:122 No buffers available for ISP Output0

Is the autofocus deactivation causing the stall?

Two things here:

On the green smudge: If it’s only slightly visible now, you might need to implement the lens shading correction yourself on the RAW output. The Raspberry Pi ISP does apply lens shading on the RAW image during format conversion, but it doesn’t support RAW-in/RAW-out passthrough. So if you need lens-shading-corrected RAW files, you’ll need to implement the algorithm in software on the output RAW data.

On removing the lens: I strongly recommend NOT removing the lens mount — it can easily damage the sensor. The error message “No buffers available for ISP Output0” means libcamera can’t receive data from the camera sensor at all, which is unrelated to the focus motor. If you really need a lens-less or fixed-focus configuration without the motor, please contact [email protected] for a customized module. Removing parts yourself can permanently damage the hardware.

Good to know about the lens — I’ll leave it on. One last thing: I had to re-flash my Raspberry Pi OS with a fresh Bullseye image, and now libcamera-still -r (raw capture) fails with:

Failed to allocate memory for custom tag binary object ...

Same memory allocation error I saw before. Is this a known issue with the stock Bullseye libcamera packages?

Yes, that’s a known issue with the stock Bullseye packages. My colleague Wong has reproduced it and will review it for a permanent fix. In the meantime, the solution is to recompile libcamera-apps from source and use the latest installation script:

  1. Reference the Arducam guide Section 1.2 “Build from source code”: Redirecting...

  2. Also, if you need autofocus support in libcamera-apps, you’ll need to use the Raspberry Pi’s patched source code specifically. Check this forum thread for details: Libcamera-apps built from source does not have autofocus option - #5 by wong

Recompiling with the latest installation script should resolve both the memory allocation error and give you the latest features. Let me know if you need any more help getting the tuning file dialed in!