@stiwana
https://wiki.veye.cc/index.php/Mv_series_camera_appnotes_4_jetson

For specific information, please refer to the link above. We provide a veye_viewer client for customers to initially get started and verify usage.

We haven't done extensive debugging on GStreamer yet. As for OpenCV, there are examples provided in the article above. Regarding the latency issue: although the camera itself has negligible delay, each image entering the Jetson system will experience some latency due to the V4L2 buffer, format conversion, and preview processes—all of which involve memory buffering queues.

The most fundamental solution is to develop your own program tailored to your product's specific needs, allowing flexible management of buffers. Additionally, note that the V4L2 buffer containing the camera images after they enter the Jetson system includes timestamps. It is recommended that you use these timestamps.

Regarding the supply of this product, we will maintain long-term availability unless the chip is discontinued. We will keep a regular inventory sufficient to meet retail demand. For bulk orders of several hundred units or more, the production cycle is typically within one month.

@barbanevosa
The issue occurs because the camera sensor outputs a resolution of 3088 × 2064, but the receiving side (V4L2 buffers) aligns each line to a stride of 3136 bytes for memory alignment. When OpenCV is used directly with cv2.CAP_V4L2, it applies the width setting (3088) both to the sensor and to the buffer interpretation. Since the actual buffer has padding (3136 vs. 3088), OpenCV misinterprets the data layout, which results in visible image artifacts (stripes).

We recommend using a GStreamer pipeline to handle the stride and alignment internally, so that OpenCV receives a clean image with the correct resolution.

@stiwana Sorry, we do have this in mind, but no actual plans or projected time of completion at this time.

使用脚本可以，感谢

@veye_xumm Thank you, graet news

@veye_xumm
Perfect. Now is working as expected. Thanks!

@victor Sorry for the late reply.
After communicating with the sensor manufacturer, I found that the built-in temperature sensor in the SC130GS is extremely inaccurate and cannot be used properly.

@zang 相机是支持这个分辨率配置的。你的整个操作报什么错误吗？
可以用mv_mipi_i2c.sh脚本读取一下相机实际roi确认是否已经配置到camera里面。
另外300不利于对齐，你可以试试304

@alex_ai said in IMX462M pixelformat on RPi5:

I need wait for clear sky to test and provide feedback

Finally tested, for gain value 20 it is looks pretty same with color sensor with ISP, but background no so black as for color sensor.
For me this issue resolved, attached examples to compare (10 seconds stacks)

IMX462 mono
IMX462M_small.jpg

IMX462 color with ISP
IMX462C_small.jpg

@nb 您好，我遇到了类似的问题，请问一下您的解决方案就是将4.6的opencv更换成4.2的opencv吗？

@dan
Please try this image.

export I2C_BUS=7 export WIDTH=1280 export HEIGHT=1024 export FPS=108 media-ctl -d /dev/media0 --set-v4l2 '"m00_b_mvcam '"$I2C_BUS"'-003b":0[fmt:Y8_1X8/'"$WIDTH"'x'"$HEIGHT"'@1/'"$FPS"']' v4l2-ctl -d /dev/video0 --set-fmt-video=width=$WIDTH,height=$HEIGHT,pixelformat=GREY --stream-mmap --stream-count=-1 --stream-to=/dev/null

93427bda-d9b6-4263-be24-30aac77b3df5-image.png

@xym 可能是pipeline效率的原因，buffer不够用导致丢帧了。

@veye_xumm Thanks, this should be enough I think

@nb
https://wiki.veye.cc/index.php/Mv_mipi_camera_manual/zh#Sony.27s_Global_shutter.EF.BC.88.E5.85.A8.E5.B1.80.E6.9B.9D.E5.85.89.EF.BC.89
2.4.3

@veye_xumm 好的 感谢

@张志伟 不好意思，我们现在相机本身没有图像矫正功能，也没有使用板块的ISP模块的方案。

@nb 不客气。

@veye_xumm 好的，感谢