Posts made by tj

@veye_xumm Thanks for the offer. While posting the Makefile I noticed I had -overlay.dtbo in the filenames. Compiling now.

@veye_xumm Thanks for having a look. I had already added those lines. However I still get the error.

As the raspberry folks have released a new kernel (20210430), I'm trying to compile the drivers for a new camera of @MK. Following the instructions, at the last build command I get the error:

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- zImage modules dtbs -j2
make[2]: *** No rule to make target 'arch/arm/boot/dts/overlays/csimx307-overlay.dtbo', needed by '__build'.  Stop.
make[1]: *** [scripts/Makefile.build:496: arch/arm/boot/dts/overlays] Error 2

What am I doing wrong? I've double checked that I did the four steps:

• add driver sources
• update Makefile and Kconfig
• add dts files
• change Makefile in dts folder

This problem seems to have solved itself, I cannot reproduce it.

I'll try to reproduce first. Unfortunately my disk was full just before midnight tonight (Murphy's law). Longer frames here are probably due to high CPU load in the rest of the pipeline. Better luck next night.

@veye_xumm Thanks, I forgot to update the script from Github

@veye_xumm Thanks for the quick fix! I've installed 2.39 and tested; the regular pattern of missed frames is now gone.

I've also tried with 2.39 in master mode, it gives a similar pattern. The regular pattern sometimes a somewhat longer read time (this pattern appears about every 48 frames) is very acceptable. Also, missing one frame in 2000 frames isn't a big problem.

Thanks again! Next problem in a next topic

@veye_xumm Changing to YUYV may be helpful for some programs that expect a grayscale image first. I noticed a new firmware version has an option for changing to YUYV. Is it already possible to enable this with an i2c command?

Another curiosity: I'm trying to record meteors at 720p@60fps, and somehow the system changed from 60fps to 30fps at exactly midnight. I didn't change anything during the capture since I was asleep. I also checked that the script on the raspberry kept running, also the raspberry did not reboot.
Could this be due to a nightly reboot of the camera? I did not specify it to reboot.

@veye_xumm Thanks for the quick reply and the workaround!

I tried setting the camera to master and redid the experiments. It seems that the cv2.CAP_V4L2 gives a slightly more constant framerate, so I'll skip gstreamer.

I'm diving into this a bit more. Thanks to Yevhenii I'm now using the gstreamer backend to opencv.

I've tested the time it takes to capture individual frames, with Now at 60fps, so a single frame should take 16.7ms. This works out for most frames, but there's a strange pattern of frames that take a lot longer:

The number of frames between the frame that stalls is 153, 146, 153, 145, 153, 146, 153, 146, ... (this goes on for at least 100 times, so it's a real pattern).

The opencv v4l2 backend gives a similar result:

I have not tried to make this plot with the D_mipicamera python library, but I suspect a very similar behavior.

This is probably also the reason the average goes below 50 in the above questions. Does this ring a bell?

Expanding a bit, I tried the gstreamer-command, and this may not be a python problem:

gst-launch-1.0 v4l2src device=/dev/video0 ! "video/x-raw,format=(string)UYVY, width=(int)1280, height=(int)720,framerate=(fraction)50/1" ! videoconvert ! fpsdisplaysink video-sink=fakesink -v
/GstPipeline:pipeline0/GstFPSDisplaySink:fpsdisplaysink0: last-message = rendered: 495, dropped: 0, current: 41.52, average: 48.30
/GstPipeline:pipeline0/GstFPSDisplaySink:fpsdisplaysink0/GstTextOverlay:fps-display-text-overlay: text = rendered: 520, dropped: 0, current: 49.69, average: 48.37
/GstPipeline:pipeline0/GstFPSDisplaySink:fpsdisplaysink0: last-message = rendered: 520, dropped: 0, current: 49.69, average: 48.37
/GstPipeline:pipeline0/GstFPSDisplaySink:fpsdisplaysink0/GstTextOverlay:fps-display-text-overlay: text = rendered: 546, dropped: 0, current: 49.99, average: 48.44
/GstPipeline:pipeline0/GstFPSDisplaySink:fpsdisplaysink0: last-message = rendered: 546, dropped: 0, current: 49.99, average: 48.44
/GstPipeline:pipeline0/GstFPSDisplaySink:fpsdisplaysink0/GstTextOverlay:fps-display-text-overlay: text = rendered: 572, dropped: 0, current: 50.33, average: 48.53
/GstPipeline:pipeline0/GstFPSDisplaySink:fpsdisplaysink0: last-message = rendered: 572, dropped: 0, current: 50.33, average: 48.53
/GstPipeline:pipeline0/GstFPSDisplaySink:fpsdisplaysink0/GstTextOverlay:fps-display-text-overlay: text = rendered: 597, dropped: 0, current: 49.92, average: 48.58
/GstPipeline:pipeline0/GstFPSDisplaySink:fpsdisplaysink0: last-message = rendered: 597, dropped: 0, current: 49.92, average: 48.58
/GstPipeline:pipeline0/GstFPSDisplaySink:fpsdisplaysink0/GstTextOverlay:fps-display-text-overlay: text = rendered: 618, dropped: 0, current: 41.27, average: 48.29
/GstPipeline:pipeline0/GstFPSDisplaySink:fpsdisplaysink0: last-message = rendered: 618, dropped: 0, current: 41.27, average: 48.29
/GstPipeline:pipeline0/GstFPSDisplaySink:fpsdisplaysink0/GstTextOverlay:fps-display-text-overlay: text = rendered: 643, dropped: 0, current: 49.78, average: 48.35
/GstPipeline:pipeline0/GstFPSDisplaySink:fpsdisplaysink0: last-message = rendered: 643, dropped: 0, current: 49.78, average: 48.35
/GstPipeline:pipeline0/GstFPSDisplaySink:fpsdisplaysink0/GstTextOverlay:fps-display-text-overlay: text = rendered: 669, dropped: 0, current: 50.22, average: 48.42

Is this a hardware problem? Or a driver problem?

@luchec (I'm tammojan.) I only tested the csimx307.ko , not the veye327. The CXIMX307 it seems to work for me. If there are problems with the drivers I'd be happy if you could find out!

I'm trying to get 720p@50fps into python with a IMX307 with the V4L2 driver installed. Somehow, I can't get above about 43fps, with the following code:

from time import time
import cv2

cap = cv2.VideoCapture(0, cv2.CAP_V4L2)

t0 = time()

for i in range(256):
    _, frame = cap.read()

t1 = time()

print("FPS:", 256/(t1-t0))
print("Frame shape:", frame.shape)

This outputs:

FPS: 44.038153429151514
Frame shape: (720, 1280, 3)

(To get the right width/height/fps in opencv, I hardcoded them into OpenCV as suggested here.)

I'm running on a Raspberry Pi 4 with 4GB RAM. Now my question: how can I get more than 44 fps into python? Should I throw opencv out and look at pure python implementations (1, 2)? Why is this so hard?

I created a pull request with the new drivers: https://github.com/veyeimaging/raspberrypi_v4l2/pull/6

I'm trying to do this (compiling now). I found the wiki a bit hard to follow. In step 8.6 (Add compilation options), it says 'the path is driver --> multimedia --> i2C', however for me it was 'Device Drivers --> Multimedia Support --> Media ancillary drivers --> Camera sensor devices --> '