Image tearing with arducam imx477

Robotics & Edge Computing Jetson & Embedded Systems Jetson Nano
,
1

Hello, when i read images with gstreamer from a imx477 camera connected to the mipi cam0 connector, i get a very visible tearing line trough the image, the gstreamer pipeline used is:

gst-launch-1.0 nvarguscamerasrc ! ‘video/x-raw(memory:NVMM), width=1920, height=1080, framerate=60/1’ ! nv3dsink

and here is an screenshot from the camera feed to show the issue:

image
image1852×1047 108 KB

The issue persists in different resolutions and frame-rates and my monitor is set to display at 60hz

Any ideas on where/what the issue could be? I already ran the jetson-io script multiple times to configure the pin layout for the connector, tried multiple cameras, multiple cables and multiple jetsons

I’m using a Jetson Orin Nano JetPack 6.2 with the tensortRT and gpu drivers installed trough sdk manager. the issue is the same for jetpack 6.1 as well

3

Boost the clocks to try.
If didn’t check the trace log to get more informaiton.

sudo jetson_clocks
sudo su
echo 1 > /sys/kernel/debug/bpmp/debug/clk/vi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/isp/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/nvcsi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/emc/mrq_rate_locked
cat /sys/kernel/debug/bpmp/debug/clk/vi/max_rate |tee /sys/kernel/debug/bpmp/debug/clk/vi/rate
cat /sys/kernel/debug/bpmp/debug/clk/isp/max_rate | tee  /sys/kernel/debug/bpmp/debug/clk/isp/rate
cat /sys/kernel/debug/bpmp/debug/clk/nvcsi/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/nvcsi/rate
cat /sys/kernel/debug/bpmp/debug/clk/emc/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/emc/rate
1 Like
5

I understood now what you meant, boosting the clocks for the camera did not work, the frame tearing is there, and it is there for video and photos with the IMX477 camera.

6

Could you get the raw image by nvargus_nvraw?

nvargus_nvraw --format jpg --skipframes 30 --file t.jpg
7

Hello @joras,

Can you try capturing with v4l2-ctl?

v4l2-ctl -d /dev/video0 --set-fmt-video=width=1920,height=1080 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=1 --stream-to=test.raw

The idea would be to remove nvargus from the equation and see if the issue persists.

best regards,
Andrew
Embedded Software Engineer at ProventusNova

8

The test.raw file is always saved as empty, i added the --verbose flag to read what was happening, and got this:
v4l2-ctl --verbose -d /dev/video0 --set-fmt-video=width=1920,height=1080 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=1 --stream-to=test.raw
VIDIOC_QUERYCAP: ok
VIDIOC_S_EXT_CTRLS: ok
VIDIOC_G_FMT: ok
VIDIOC_S_FMT: ok
Format Video Capture:
Width/Height : 4032/3040
Pixel Format : ‘RG10’ (10-bit Bayer RGRG/GBGB)
Field : None
Bytes per Line : 8064
Size Image : 24514560
Colorspace : sRGB
Transfer Function : Default (maps to sRGB)
YCbCr/HSV Encoding: Default (maps to ITU-R 601)
Quantization : Default (maps to Full Range)
Flags :
VIDIOC_REQBUFS returned 0 (Success)
VIDIOC_QUERYBUF returned 0 (Success)
VIDIOC_QUERYBUF returned 0 (Success)
VIDIOC_QUERYBUF returned 0 (Success)
VIDIOC_QUERYBUF returned 0 (Success)
VIDIOC_QBUF returned 0 (Success)
VIDIOC_QBUF returned 0 (Success)
VIDIOC_QBUF returned 0 (Success)
VIDIOC_QBUF returned 0 (Success)
VIDIOC_STREAMON returned 0 (Success)
cap dqbuf: 0 seq: 0 bytesused: 24514560 ts: 796.988572 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 1 seq: 1 bytesused: 24514560 ts: 797.025333 delta: 36.761 ms (error, ts-monotonic, ts-src-eof)

it seems the camera is outputting 4032 x 3040

9

t
t1920×1080 35.2 KB

the issue persists with the raw image

10

Hello @joras,

Thanks for sharing back the results, they are very helpful.

If the issue persists with raw capture, it means that is not related to nvargus capture subsystem or the ISP.

And, given that the imx477 driver is supported by default by NVIDIA boards and its already tried and tested, I would doubt could be driver related. Well, unless you are using a driver from somewhere else, but I don’t think that is the case, right?

Then, the next tests we would suggest trying are:

  1. Try changing CSI ports.

  2. Try changing MIPI cables.

  3. Try changing camera modules.

This would help us debug if this could be a HW issue.

best regards,
Andrew
Embedded Software Engineer at ProventusNova

11

I really appreciate the help Andrew!

I have tested with 2 different cameras, 4 different cables on 2 different jetsons, all of them with jetpack 6.1+, and the issue persists. I have talked with a hardware engineer to make sure i wast damaging the cables while handling or installing the cables/camera.

At this point I’m pretty sure the issue is not hardware, arducam has a driver that fixed the tearing issue but introduced a blue tint and made the image a lot blurrier (to the point where it is unusable for our purposes)

here is their command to install their driver (winch they called a slow driver):
cd ~
wget https://github.com/ArduCAM/MIPI_Camera/releases/download/v0.0.3/install_full.sh

chmod +x install_full.sh
./install_full.sh -m imx477_stereo

I’m currently investigating what their driver does to remove the tearing.

12

Hey @joras,

Sure, no problem, it’s our pleasure to help.

Roger that, so yeah essentially a HW issue is ruled out.

Given that arducam has a driver that fixes the tearing issue, my next guess would be something related with timing or padding. Based on our experience that is usually the cause of issues that show like the one you are experiencing.

I was trying to look for the source code of that arducam driver you mentioned, but unfortunately it seems like they only provide a Debian package. Do you happen to have its source code ?

If not, a couple tricks I would try to get more information about it would be:

  1. Check DTB configuration inside /opt/device-tree.
  2. Try checking register table values by getting register addresses from the IMX477 camera driver that you do have source code for, and reading the registers manually with i2cget while using the arducam driver.

I would also suggest contacting arducam to see if they can provide the source code.

Please keep us posted, and do not hesitate to reach out it you require further support, we would love to give you hand.

best regards,
Andrew
Embedded Software Engineer at ProventusNova

2 Likes
13

You can also try the build in IMX477 sensor driver to confirm.

Thanks

1 Like
15

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.