When I connected the color space yuyvcamera, I found that the yuv image received by orin was uyvy

Robotics & Edge Computing Jetson Systems Jetson AGX Orin
1

Hardware: AGX Jetson Orin (64G & 32G)
Software: Jetpack5&Jetpack6
Connection method: sensor + serializer + deserializer + Orin

dtsi config
mode_type = “yuv”;
pixel_phase = “uyvy”;

I tried the following combinations
（I made sure the color space provided by my vendor was correct, as I can verify this using other soc chips.）
case1
sensor（yuyv）+ max9295 + max96712 + Orin（dtsi:yuyv）—> yuv文件(uyvy)
case2
sensor（uyvy）+ max9295 + max96712 + Orin（dtsi:yuyv）—> yuv文件(yuyv)
case3
sensor（uyvy）+ max96717f + max96712 + Orin（dtsi:yuyv）—> yuv文件(uyvy)
case4
sensor（uyvy）+ max96717f + max96712 + Orin（dtsi:uyvy）—> yuv文件(yuyv)

Summary: I found that Orin could not get a YUV file with the expected color space, and the result was always the opposite of what was expected.

Same problem as me
https://forums.developer.nvidia.com/t/gmsl-sensor-display-color-is-not-correct-format-yuyv-and-uyvy/218897

Although I got the method to get the correct color space from other posts, that method solved the problem by modifying the deserializer color mapping. This is not a method to solve the root cause.
The specific process is exactly the same as what I described in the post above.
Nvidia team, do you have any better solution?

I am looking forward to your reply

4

Hi,

Jetson only display ‘uyvy’ as the right color on screen, if sensor output yuyv(dtsi pixel_phase=yuyv), you should convert color space through CPU, command like:

gst-launch-1.0 v4l2src device=/dev/video0 ! rawvideoparse format=4 width=1920 height=1080 ! videoconvert ! xvimagesink

5

First of all, thank you for your reply. I know this display method.

I want to know why yuyv is flipped to uyvy. As for adjusting the color space, both the CPU and GPU methods can do it.

Currently, whether I use the following command or the v4l2 standard method to access camera data, the yuv data obtained is the opposite of the actual access format.

v4l2-ctl --set-fmt-video=width=3840,height=2162,pixelformat=YUYV --set-ctrl bypass_mode=0 --stream-mmap --stream-count=1 -d /dev/video0 --stream-to=output.yuv

6

Could you dump to file to confirm the format by utility like 7yuv.

Thanks

7

I used the software(7yuv) you mentioned to confirm it. Of course, I also confirmed it with other yuv2rgb tools.

8

Could you attach the file here for reference.

Thanks

9

this is yuv file and 7yuv
yuv+png.zip (3.4 MB)

11

Could you print the format in vi5_fops.c to confirm.

desc->ch_cfg.pixfmt.format = format;
12

printf log:

1
11163×298 84.7 KB

2
2981×449 138 KB

3
31082×754 97.1 KB

13

The configuration looks like without problem.
Do you dump the file by v4l2-ctl?

14

The yuv file is obtained by the following command

v4l2-ctl --set-fmt-video=width=3840,height=2162,pixelformat=YUYV --set-ctrl bypass_mode=0 --stream-mmap --stream-count=1 -d /dev/video0 --stream-to=output.yuv

So is this what you mean?

15

Yes, using vl42-ctl to dump is fine.
Could you bypass the serdes to check if any different.

Thanks

16

I use the same configuration and I don’t have this problem on Qualcomm chips. Can you check this in your company?

17

thank you，I know you means.