[BUG] Unable to get raw image in raspberry pi 5

[tf4ong]

I am trying to get raw images using a rqspberry pi 5 with a monchrome imx296.
Here is my code

I was using this code in raspberry pi 4 and it worked fine. It seemed liked the libcamera tuning files were changed from vc4 to pisps on the pi5s? Is this change causing the issue?
With libcamera-raw it gave me a MONO_PISP_COMP1 format on the pi5 vs R10 on the pi4.

[davidplowman]

Hi, please could you say what camera you are using. Please confirm that a clean install of the latest OS shows the problem. Could you also post the exact script (as short as possible, please!) that fails in the comments here so that I can copy and paste it - then I can try it for myself. Thanks!

[tf4ong]

Hi, this is my version:
pi@raspberrypi:~ $ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

I am running a 64 bit OS on the pi5

The code is this:

import numpy as np
from picamera2 import Picamera2
import cv2
from libcamera import controls
from time import sleep

cv2.startWindowThread()
width=1920
height=1080
picam2 = Picamera2()
preview_config = picam2.create_preview_configuration(raw={"format": 'R10',"size": (width,height)})
picam2.configure(preview_config)
picam2.set_controls({"AeEnable": False,"ExposureTime": 30000,
"AnalogueGain":1,"FrameRate": 40,"NoiseReductionMode": controls.draft.NoiseReductionModeEnum.Off,"Sharpness" :0})
sleep(1)

picam2.start()
while True:
raw_image = picam2.capture_array("raw")
data = np.frombuffer(raw_image,np.uint16).reshape(height,width)
data = data*255/1023
cv2.imshow('img',img2show.astype(np.uint8))
if cv2.waitKey(1) & 0xFF == ord('q'):
break
I am using a monochrom imx296 from innomaker which should be equivilent to the GS picamera. Libcamera-vid, libcamera-raw works fine thou.

[davidplowman]

Thanks very much for the update. There's a fix here (actually just the second commit), and I'll merge that shortly for the next release.

Note that a Pi 5 will give you an "R16" raw image - after configuring the camera, check

picam2.camera_configuration()['raw']

so your loop should look like this:

while True:
    raw_image = picam2.capture_array('raw')
    cv2.imshow('img', raw_image.view(np.uint16))
    if cv2.waitKey(1) & 0xFF == ord('q'):
        break

[tf4ong]

Thanks, I will pull and give it a try. Just wondering if it is possible to pull out the exact bit depth as the camera, like before? Like for the imx296, it would be 10 bit values?

[davidplowman]

Yes, look at picam2.camera_configuration()['sensor']. The manual does talk about this (section 4.2.2.3 I think), though it gets more complicated than I would like because of backward compatibility issues, and the fact that we still aren't recommending Bookworm for Pi 3 or earlier devices.

[tf4ong]

Thanks, I can get raw. I have looked at the manual and tried setting sensor={'bit_depth':10} when creating the configuration. If ran but still produced 16 bit data in the raw image

[davidplowman]

Yes, it's 10 bit from the sensor, but you always get full 16-bit range values in the raw file (in this case the bottom 6 bits will always be zero). You can't get the "right shifted" version. There are some benefits:

• It's often easier and more efficient to process like this (e.g. OpenCV understands these images properly, for example you can display them without having to rescale all the numbers).
• The same code works whether the sensor gives you 10 or 12 bits.
• Obviously if you need to shift the numbers down, you can.

[tf4ong]

Do you think there will be any work around to get the exact bit depth as before on the raspberry pi 4 (10/12 bit)? I am binning the images (8x8, on 10 bit data in 16 bit array) on the go so I can get a 16 bit image right afterwards. If I do the shifts as well, it will probably drop my frame rate abit.

[davidplowman]

No. Pi 5 gives you 16-bit values for all raw formats. If you want to reduce the dynamic range you will have to shift the values. In your case, I'd compute the sums of the 8x8 pixels (or whatever it is that you're doing!), and right-shift by 6 (substitute the correct value if that one is wrong!) at the end. In the previous case you had to have different code for 10/12 bit sensors, now they're all the same. On a Pi 5, this will be way faster than what you were doing on a Pi 4.

[tf4ong]

Just one last thing, about shiftting. I might be misunderstanding shifiting. Do you mean I have to compute each new pixel value of the 16 bit array to 10 bit by mutiplying with 1023/65536 to shift it? Or is there an easier way to convert the 16 bit value to 10 bit while keeping the 16 bit array numpy structure?

[davidplowman]

I would do image_10bit = image_16bit >> 6 on your numpy array (or whatever it is!).

[tf4ong]

Perfect! thanks for speedy replies. I think the probelm is solved and I will give that a go