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)
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:
But instead, it looks like this (after pressing save on the argus_camera demo, disabling all effects)
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
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!
Could you check the raw file by tools 7yuv or imagej
See the raw file imported in 7yuv here. (second image is zoomed in at top left)
What the badge info in you camera device tree?
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)
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?
I cannot attach the raw file (forum only allows log files, jpegs, …). But here’s an upload
I did not apply any ISP override file.
Yes, the debayer algorithm is different from what I would expect (the edges).
Could you try the pixel_phase = “rggb” or “grbg”
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
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.
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)
Does v4l2-ctl --list-formats-ext changed when modify the pixel_phase?
nvidia@nvidia-desktop:~$ v4l2-ctl --list-formats-ext
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”;
This problem may need ISP tuning process.
Could you have contact with camera partner to get help.