Hi, posting two things here since they’re kind of related. First, I think there’s a typo in the Arducam 64MP Pi camera PDF manual. The instructions show:
libcamera-still -list-cameras
but that should be:
libcamera-still --list-cameras
Reference PDF: https://www.arducam.com/downloads/arducam_64mp_pi_camera_manual.pdf
Second (and bigger problem), I’m trying to install the driver for the 64MP Pi Hawk Eye camera on my Pi and the install script won’t find a package. Anyone seen this?
Thanks for flagging that, and yes you’re right — the manual has a typo. It should be libcamera-still --list-cameras (double dash). I’ll make sure that gets corrected in the docs going forward.
For the install problem, can you share the full output of the install script and a bit of your setup? Specifically:
uname -aThat’ll help me pin down what’s happening.
Sure, here’s what I ran and got back.
Command:
./install_pivariety_pkgs.sh -p 64mp_pi_hawk_eye_kernel_driver
Output:
Cannot find the corresponding package, please send the following information to [email protected]
Hardware Revision: d03114
Kernel Version: 5.15.73-v8+
Package: 64mp_pi_hawk_eye_kernel_driver -- bullseye-arm64-v5
You are using an unsupported kernel version, please install the official SD Card image(do not execute rpi-update): https://www.raspberrypi.com/software/operating-systems/
My setup:
That output tells us pretty much everything. The root cause is that the 64MP Pi Hawk Eye driver package doesn’t support kernel version 5.15.73. Because of that, the install script can’t find a matching driver package and bails out.
Here’s what’s going on under the hood. The script downloads a link map file:
64mp_pi_hawk_eye_kernel_driver_links.txt
from https://github.com/ArduCAM/Arducam-Pivariety-V4L2-Driver/releases/download/install_script/64mp_pi_hawk_eye_kernel_driver_links.txt
That link map matches your kernel version to a driver tarball. It looks roughly like this:
5.10.17+ through 5.10.103-v8+ → arducam_64mp_kernel_driver_5.10.y.tar.gz5.15.30+ through 5.15.32-v8+ → arducam_64mp_kernel_driver_5.15.y.tar.gz5.15.56+ through 5.15.56-v8+ → arducam_64mp_kernel_driver_5.15.56.tar.gz5.15.61+ through 5.15.61-v8+ → arducam_64mp_kernel_driver_5.15.61.tar.gzNotice 5.15.73-v8+ isn’t in that list — there’s no mapping entry for it, so the script has nothing to install. That’s the whole failure.
You can check the link map yourself with:
cat 64mp_pi_hawk_eye_kernel_driver_links.txt
Can you paste the output of uname -a too so I can confirm the exact kernel string?
Here you go:
uname -a
Linux drone 5.15.73-v8+ #1593 SMP PREEMPT Wed Oct 12 14:24:59 BST 2022 aarch64 GNU/Linux
So yeah, 5.15.73-v8+. What are my options here? I’d rather not nuke my whole setup.
Two ways forward:
If you want to try the rollback, this is the usual command:
sudo apt-get update; sudo apt-get install --reinstall raspberrypi-bootloader raspberrypi-kernel
Then reboot and check uname -a again. Ideally you want to land on one of the versions that has a mapping (like 5.15.56 or 5.15.61) so the install script finds a driver.
The kernel rollback fixed it. Ran:
sudo apt-get update; sudo apt-get install --reinstall raspberrypi-bootloader raspberrypi-kernel
rebooted, and now:
uname -a
Linux drone 5.15.74-v8+ #1595 SMP PREEMPT Wed Oct 26 11:07:24 BST 2022 aarch64 GNU/Linux
The driver installed fine after that. Might be worth noting this workaround somewhere for other people hitting the same unsupported-kernel wall.
Nice, glad the rollback worked for you. Definitely a useful workaround for anyone stuck on an unsupported kernel.
To confirm the driver is actually active, try:
libcamera-still -t 0
If the video stream opens, the driver is installed successfully. And just to close the loop on the doc issue — in the PDF it should read libcamera-still --list-cameras, not libcamera-still -list-cameras.
Let me know how the stream test goes.
The stream test works, so the driver’s good. But now I’ve got a new problem — I can’t get the 64MP camera working with OpenCV. cv2.imshow keeps throwing an assertion error.
Environment:
uname -a
Linux drone 5.15.74-v8+ #1595 SMP PREEMPT Wed Oct 26 11:07:24 BST 2022 aarch64 GNU/Linux
OpenCV 4.6.0
When I run python3 test.py it just prints None and then dies. Here’s the traceback:
Traceback (most recent call last):
File "/home/pi/projectfiles/CNN/test.py", line 7, in <module>
cv2.imshow('frame',frame)
cv2.error: OpenCV(4.6.0) /io/opencv/modules/highgui/src/window.cpp:967: error: (-215:Assertion failed) size.width>0 && size.height>0 in function 'imshow'
Line 7 in my script is just:
cv2.imshow('frame',frame)
Any idea what’s going on?
That error is OpenCV complaining that the frame you’re handing to imshow has zero width/height — basically it’s an empty image. The None your script printed is the clue: whatever read/capture step is producing frame is returning None, and then imshow chokes on it.
So the real question is how frame is being created in test.py. Can you paste the whole script? Specifically I want to see:
cv2.VideoCapture(...) and what index/backend).read() return value before calling imshowOn the Pi, OpenCV usually can’t talk to the Arducam sensor directly through cv2.VideoCapture unless you feed it a proper pipeline or use the libcamera-based capture path. If the capture never returns a valid frame, you’ll keep seeing exactly this assertion.
Here’s the whole thing:
import cv2
cap = cv2.VideoCapture(0)
while True:
ret, frame = cap.read()
print(frame)
cv2.imshow('frame', frame)
if cv2.waitKey(1) & 0xFF == ord('q'):
break
cap.release()
cv2.destroyAllWindows()
ret comes back but frame is None (that’s the None I keep seeing printed), then imshow fails. I’ve tried cv2.VideoCapture(0) and a couple of other indices and it’s the same.
Yeah, that confirms it — cap.read() is returning an empty frame, so frame is None and imshow blows up on the zero-size image. It’s not an imshow bug, it’s an upstream capture problem.
A couple of things to try:
imshow so you can see what’s failing:ret, frame = cap.read()
if not ret or frame is None:
print("no frame from capture")
continue
cv2.imshow('frame', frame)
Check whether the default V4L2 path even exposes the camera properly — libcamera-still -t 0 working proves the sensor/driver is fine, but it doesn’t mean cv2.VideoCapture(0) can use it. On Bullseye, OpenCV 4.6.0 built without the right backend won’t get frames from the Arducam this way.
If you’re on a libcamera-based stack, you typically need to either open the camera through a pipeline string, or capture with libcamera/picamera2 and pass the frames into OpenCV instead of relying on cv2.VideoCapture.
Can you tell me how your OpenCV was built (pip or apt), and whether you’re on the 64-bit Bullseye (aarch64)? That’ll decide which capture route actually works.
It’s pip-installed OpenCV 4.6.0 on 64-bit Bullseye (aarch64), matching the uname -a I posted. So if cv2.VideoCapture isn’t the way, what’s the recommended path to get frames from the 64MP Hawk Eye into OpenCV? I mostly need it for a CNN script that reads frames and processes them.
For your setup the usual route is to capture outside of cv2.VideoCapture and hand the frames to OpenCV as arrays — grab them via the libcamera/picamera2 stack (or an explicit pipeline) and then do your OpenCV processing on the resulting frame. The pure cv2.VideoCapture(0) path is what’s giving you the None frames here.
So to summarize where we’re at on this thread:
sudo apt-get update; sudo apt-get install --reinstall raspberrypi-bootloader raspberrypi-kernel) got it onto a supported version and the driver installed. Verifying with libcamera-still -t 0 and confirming the stream opens proves the driver is good.imshow assertion is a separate issue: cap.read() is returning an empty frame, so imshow gets a zero-size image. imshow isn’t the culprit — the capture isn’t producing frames via cv2.VideoCapture.libcamera-still --list-cameras (double dash), not -list-cameras.If you can share how you’re sourcing frames (picamera2 vs. a pipeline string) I can help wire that into your CNN script, but the driver side is sorted. The OpenCV capture piece is still open.