Hi, I’m getting a big delay when capturing an image with libcamera and I can’t figure out how to get rid of it.
I’m running libcamera-still -t 1000 -o img.jpg and it takes around 5 seconds before I actually get the img.jpg file. Even with -t 1000 the wait is still roughly 5 seconds.
What I really want is to capture a picture as soon as the command is run, without a preview first. I don’t need the preview at all.
The reason this matters: I trigger the capture from a sensor value. When the sensor sends the value 1, my command that grabs the image fires. But the resulting image is not right / not aligned for that moment, because there’s this waiting time while the libcamera command runs.
What I don’t understand is whether I can get rid of this wait without using external trigger mode? Or is external trigger the only way to avoid the delay between running the command and getting the image file?
Thanks for the details. Can you confirm the exact camera and the environment you’re on so I can point you at the right stuff?
For reference, the behavior you describe is expected with libcamera: it uses streaming mode, and the efficiency of saving a picture that way isn’t high. For various reasons a frame (and its timestamp) can be lost, which is why the total time ends up longer.
If your use case needs a picture immediately when a signal happens, external trigger mode is generally the way to go. When users have strict delay requirements, that’s the mode they typically pick.
Thanks, that’s the setup I suspected. Let me explain the root cause so the difference makes sense:
libcamera works in streaming mode. Its picture-saving efficiency isn’t high, and frames/their timestamps can get dropped along the way, which produces the longer overall capture time you’re seeing. That delay is inherent to the libcamera streaming path. It is not the same as a triggered capture path, which is exactly why your image ends up not aligned to the moment your external sensor signal fires. The trigger fires, but the streaming capture path is still what you’re going through, so the timing drifts.
With external trigger mode you get a picture immediately. That’s the whole point of it for time-critical captures. So if very low latency is what you need, that’s the recommendation.
On the 1.8V question: yes, the external trigger input level is 1.8V, so you’ll need to bring your trigger signal down/level-shift to 1.8V to match it.
On documentation: yes there are updates, and there’s improvement/updated docs for external trigger planned to land in roughly the next two weeks. Until that’s out, you can read up on the external trigger pattern online.
Okay that makes sense about the streaming path. So to confirm: the delay is basically because libcamera is streaming and dropping frame timing, not because of my command, correct?
Two more things while I wait for the updated docs:
Is there anything I can try right now to reduce the wait on my current setup?
Can you give me a pointer to the external trigger snapshot mode configuration so I can start setting it up?
Correct, the delay comes from the libcamera streaming capture path, not really from your command itself. The trigger timing and the frame timestamping don’t line up because of that path.
Things you can try right now:
Add the -n flag to your libcamera command to skip the preview. That removes some of the wait before the capture. So for example: libcamera-still -n -t 1000 -o img.jpg
For the real fix though, set up external trigger snapshot mode. That’s the mode that gives you an immediate capture when the trigger fires.
Tried adding -n, so libcamera-still -n -t 1000 -o img.jpg. The preview is gone which is nice but the wait is still much longer than I’d expect. Definitely not capturing the moment the trigger fires. It looks like the -n flag helps a bit but doesn’t solve the alignment problem at all.
Going through the external trigger snapshot doc now. I’ll need a level shift to 1.8V for my trigger signal, right?
Right, -n only removes the preview portion of the wait, it doesn’t change the streaming capture path itself, so the frame timing issue (and the misaligned image) stays. That’s why the trigger-fired moment still doesn’t line up with what you get.
And yes, since the external trigger input level is 1.8V, you’ll need to level shift your trigger signal to 1.8V to match the input.
So to wrap up where we are:
Root cause: libcamera uses streaming mode; saving pictures that way isn’t efficient, frames/timestamps can be lost, and the delay is inherent to that streaming path rather than your command. That’s also why the image isn’t aligned to your sensor’s signal.
Workaround on current setup: use the -n parameter to drop the preview.
Proper fix for very low latency / immediate capture: use external trigger snapshot mode, configured per the AR0234 external trigger doc linked above. That’s the recommended approach over libcamera streaming when delay matters.
Your original command for reference: libcamera-still -t 1000 -o img.jpg
Note: the external trigger documentation is being improved/updated, expected within about two weeks; until then the online pattern + the linked doc are the best reference.
Give the external trigger snapshot mode a shot and post back if the trigger timing still isn’t lining up.
