Thanks for some of that background. I did write an imx415 helper for libcamera and created a tuning file based on the uncalibrated.json. I make no claims to having done it properly. As a little more background, I am using the rpicam-still utility with the --raw and it creates a DNG file. I have since modified the rpicam-still program to dump the raw 16-bit data it is receiving from the CFE and it looks like there are still corrections being applied to the image.
As a little more background, I am actually using the IMX415 monochrome sensor. I have patched the driver to query the chip and if it is monochrome, the driver sets v4l2_mbus_framefmt.code to MEDIA_BUS_FMT_Y10_1X10 (as opposed to MEDIA_BUS_FMT_SGBRG10_1X10 for color). This has caused some issues using rpicam-still as there wasn't a method to write MONO_PISP_COMP1 formats to a DNG file. I then modified the rpicam-still utility to just dump the raw 16-bit unpacked data from std::vector<libcamera::Span<uint8_t>> mem to a file. Using a hex editor, I can then look at the hex dump of a frame with the sensor completely covered and make sense of some of the data. What I found however is that every other 16-bit word alternated a pattern. This to me suggests the CFE is still trying to apply some sort of Bayer filter.
I guess I should clarify that I don't need the exact bits as they come off the CSI bus, I just need the bits the sensor is sending in a format I can write to a file. If these libraries and front-ends re-arrange the bits, I don't care (provided I know how they are ordered). It is when they are applying filters and other 'corrections' that things are getting muddied.
So going back to 6by9's suggestion to route the video around the CFE... I am very new to all things camera, V4L2, etc and am still learning, so forgive a dumb question. Your post said to route pad0 of CSI2, but isn't that pad an input to the CSI2 block? Are you able to 'T' off on an input pad or did you mean to route the IMX pad 0 to /dev/video0? I'll see if I can find some information on the process others used for the bridging.
If there are other worthwhile approaches to take based on the new information I gave, I'm all ears. I'm a little overwhelmed with all this new stuff...
As a little more background, I am actually using the IMX415 monochrome sensor. I have patched the driver to query the chip and if it is monochrome, the driver sets v4l2_mbus_framefmt.code to MEDIA_BUS_FMT_Y10_1X10 (as opposed to MEDIA_BUS_FMT_SGBRG10_1X10 for color). This has caused some issues using rpicam-still as there wasn't a method to write MONO_PISP_COMP1 formats to a DNG file. I then modified the rpicam-still utility to just dump the raw 16-bit unpacked data from std::vector<libcamera::Span<uint8_t>> mem to a file. Using a hex editor, I can then look at the hex dump of a frame with the sensor completely covered and make sense of some of the data. What I found however is that every other 16-bit word alternated a pattern. This to me suggests the CFE is still trying to apply some sort of Bayer filter.
I guess I should clarify that I don't need the exact bits as they come off the CSI bus, I just need the bits the sensor is sending in a format I can write to a file. If these libraries and front-ends re-arrange the bits, I don't care (provided I know how they are ordered). It is when they are applying filters and other 'corrections' that things are getting muddied.
So going back to 6by9's suggestion to route the video around the CFE... I am very new to all things camera, V4L2, etc and am still learning, so forgive a dumb question. Your post said to route pad0 of CSI2, but isn't that pad an input to the CSI2 block? Are you able to 'T' off on an input pad or did you mean to route the IMX pad 0 to /dev/video0? I'll see if I can find some information on the process others used for the bridging.
If there are other worthwhile approaches to take based on the new information I gave, I'm all ears. I'm a little overwhelmed with all this new stuff...
Statistics: Posted by kunzy — Tue Aug 13, 2024 4:57 pm