Hi everyone, hoping someone here can point me in the right direction.
I’m putting together a Python GUI app around a 64MP Hawkeye camera on a Pi. What I need:
a live preview embedded inside the app window
a manual focus slider (I don’t want autofocus) that keeps updating the preview while I move it
the ability to capture 32MP or 64MP stills
Environment is Bullseye on a Pi inside a “Reterminal” device, OS build 2022-06-19, 32-bit.
From the terminal libcamera-still / libcamera-hello etc. all work fine, so the sensor is being detected. But the moment I try to do the same thing through picamera2, the capture call just hangs and never returns.
So my question: does picamera2 on this 2022-06-19 32-bit Bullseye build support the 64MP Hawkeye yet? And if it does, what’s the correct way to implement preview + manual focus + 32/64MP capture in a Python GUI? Any pointers appreciated.
Hi, thanks for the detailed writeup. A few things to pin down before we go further:
What picamera2 version do you have? pip show picamera2 will tell you.
What does libcamera-still --list-cameras report? I want to confirm how the sensor shows up and what modes are exposed.
Which call exactly is hanging - Picamera2(), picam2.start(), or picam2.capture_file() / capture_array()?
Could you try the smallest possible script, with no GUI at all, just to isolate it? Something like:
from picamera2 import Picamera2
import time
picam2 = Picamera2()
print("created")
picam2.start()
print("started")
time.sleep(2)
picam2.capture_file("test.jpg")
print("done")
If it hangs, tell me the last line that prints. That tells us whether it’s a camera bring-up issue or a capture/format issue. Also useful: dmesg | tail -50 right after the hang, to see if the sensor is throwing errors.
pip show picamera2 gives me a 0.2.x version (I can grab the exact string if it matters).
libcamera-still --list-cameras does list the camera and shows the full-resolution 64MP mode as available, so the sensor is definitely seen.
It hangs on the capture. With your minimal script: “created” prints, “started” prints, then nothing. “done” never appears and I have to Ctrl-C out of it.
So start() is fine but the capture never comes back. dmesg doesn’t show anything obviously bad at the point of the hang, just the usual pipeline messages.
I haven’t really written any code yet beyond that test because I wanted to know if this combination is even supported before building the whole GUI.
Good, that’s a useful data point - if start() succeeds and only the capture stalls, it’s usually configuration rather than the camera being unsupported.
Short answer to your question: yes, the 64MP camera can be used with picamera2. You don’t need to go through libcamera-still for your app.
Rather than build your GUI around the default config, start from the ArduCAM picamera2 OpenCV example, which sets up the streams and capture path the way the 64MP sensor actually expects:
Run that example outside your GUI first, exactly as-is, and see whether it previews and captures cleanly for you. If it does, we can then lift the camera/stream configuration from it into your app. If it still hangs, paste the output here and we’ll go deeper.
does it open the preview and close cleanly without hanging?
does a capture succeed, and at what resolution?
any traceback or stall, note which line it stops on.
Once we know the standalone example is stable, the next step is to reproduce the same stream setup inside your GUI so the preview runs at one resolution while still allowing a full-res 64MP capture on demand.
OK, update after some more digging - this has moved on a bit.
I got picamera2 integrated with our GUI, and the preview + manual focus slider side is now working the way I wanted. The remaining problem is capture resolution.
I’m trying to have the preview at one (smaller) resolution while capturing at the full 64MP. But because of memory issues on this setup I can only capture at a max resolution of 4k. For anything higher resolution there seem to be some workarounds needed.
Still running Bullseye 32-bit on the Pi in the Reterminal, same setup as before. I’ve attached a couple of screenshots showing what I’m seeing.
So - is 4k the realistic ceiling here, or is there a supported way to get to the 32MP/64MP stills while keeping a live preview in the app?
Thanks for following up with the details - that lines up with what we usually see on 32-bit systems with this sensor.
To recap where things stand:
picamera2 does support the 64MP camera, and the OpenCV example is the reference setup for getting the streams configured correctly.
You now have preview + manual focus working inside the GUI.
The current blocker isn’t the camera or picamera2 support, it’s memory: with the preview stream running, the app is effectively limited to a 4k capture before it runs out of buffers.
That’s consistent with running 32-bit Bullseye - the address space and buffer requirements for a full 64MP frame alongside a live preview are the tight part, not the sensor.
The practical workaround people use is to treat preview and still capture as separate stream configurations rather than trying to hold both at once at full size: keep the preview/lores stream small for the GUI, and switch to a full-resolution still configuration only for the moment of capture, then drop back to preview afterwards. If it still fails at 64MP, work down through the larger capture sizes to find the highest resolution that’s actually stable on your board, and keep the preview stream as light as you can.
So: 4k is the ceiling with the current single-config approach, and higher-resolution stills require reworking the stream setup + buffer usage rather than a simple resolution setting. If the standalone OpenCV example can hit the full-res capture on its own, that confirms it’s the GUI/preview coexistence eating the memory and tells you where to focus.