Xavier incorrectly debayering 10bit RAW

Robotics & Edge Computing Jetson & Embedded Systems Jetson AGX Xavier
1

Hi,

I am trying to get the Xavier AGX to process incoming image data from an og02b10 sensor (1600x1300, sending 10-bit RAW data in an BGGR pattern)

rggblayout

I configured my device tree as such (in the mode node):

				active_w = "1600";
				active_h = "1300";
                dynamic_pixel_bit_depth = "10";
                csi_pixel_bit_depth = "10";
                mode_type = "bayer";
                pixel_t = "bayer_bggr10"; 
                pixel_phase = "bggr";

I can actually get an image feed with this though e.g. nvgstcapture or the arguscam demo, BUT, the image data is sublily wrong.

I send a testpattern that should show like this:

testpattern2
testpattern21600×1300 1.65 MB

But instead, it looks like this (after pressing save on the argus_camera demo, disabling all effects)

otherpattern
otherpattern1600×1300 1.91 MB

This obviously incorrect.

For reference, I also took a “raw” capture with the following command (bypassing the ISP):

v4l2-ctl --verbose -d /dev/video0 --set-fmt-video=width=1600,height=1300 --set-ctrl frame_rate=30 --set-ctrl testpattern_enable=2 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=1 --stream-to=test.raw

But I can’t upload it in this forum apparently. It looks like this

test.raw.hexdump
test.raw.hexdump728×831 12.7 KB

My question

Somehow the Xavier is converting 10bit input data to 16bit bytes, and then in the ISP pipeline this is debayered… but wrongly. What could be going wrong there? What is the recommended approach to further debug this?

Thanks in advance for your reply!

Kind regards,
Arnout

3

Could you check the raw file by tools 7yuv or imagej

4

See the raw file imported in 7yuv here. (second image is zoomed in at top left)

7yuv-cap1
7yuv-cap12104×1308 452 KB

7yuv-cap2
7yuv-cap21384×1176 5.3 KB

5

What the badge info in you camera device tree?

6

What is a device tree camera badge?

You can find the device tree running on the target in attachment. Let me know if this answers your question or not.
devtree-og02b10.txt.log (352.0 KB)

7

Could you attached the raw file here to check.
And did you apply any ISP parameter by camera_overrides.isp file?

Also could you confirm the problem is the well defined edges at each color boundary?

8

Hi,

I cannot attach the raw file (forum only allows log files, jpegs, …). But here’s an upload
https://drive.google.com/open?id=1jTDqkyEScgoDLPgwDzU5CWXuXYCciTUi

I did not apply any ISP override file.

Yes, the debayer algorithm is different from what I would expect (the edges).

9

Could you try the pixel_phase = “rggb” or “grbg”

10

But that does not make any sense? In squares themselves the colors are correct. If the pixel phase were wrong, that would be wrong too?

If you really want to, I can do test of course. Let me know

11

I use 7yuv to check with others color space I saw something weird. That’s why I want to check if change the pixel_phase have any different.

12

I tried all three

                //pixel_phase = "bggr";
				pixel_phase = "rggb";
				//pixel_phase = "grbg";

But only bggr seems to work? If I configure the others, nvargus_daemon goes into error, and I get no output in argus_camera or nvgstcapture-1.0 …

In attachment, the nvargusdeamon log for rggb… (when I dont get any picture through)
otherpixelphasearguserrors.log (28.7 KB)

13

Does v4l2-ctl --list-formats-ext changed when modify the pixel_phase?

14 
	nvidia@nvidia-desktop:~$ v4l2-ctl --list-formats-ext
	ioctl: VIDIOC_ENUM_FMT
			Index       : 0
			Type        : Video Capture
			Pixel Format: 'BG10'
			Name        : 10-bit Bayer BGBG/GRGR
					Size: Discrete 1600x1300
							Interval: Discrete 0.033s (30.000 fps)

This with with DTS pixel_phase = “rggb”;

15

This problem may need ISP tuning process.
Could you have contact with camera partner to get help.