Ok yeah. I was able to adapt the v4l2cuda example to save the raw bayer with the following changes:
static void
process_image (void * p)
{
/* printf ("CUDA format conversion on frame %p\n", p); */
/* gpuConvertYUYVtoRGB ((unsigned char *) p, cuda_out_buffer, width, height); */
/* Save image. */
if (count == 0) {
FILE *fp = fopen (file_name, "wb");
/* fprintf (fp, "P6\n%u %u\n255\n", width, height); */
fwrite (p, width*height*2, 1, fp); // Note the change from 3->2
fclose (fp);
}
}
This works when running:
./capture-cuda -c 1 -u -z -o ~/out.raw -s 3840x2160 -f SBGGR10 -F NONE
And results in a valid raw bayer file (which can now be easily converted to DNG with Python - I will share a separate post with details later today). Now I would just need to add in the exposure / framerate controls in a way that doesn’t run into the same issues as v4l2-ctl… I may wait on attempting that project until we figure out if we can get the full 4032x3040 output from the IM477 via v4l2. Arducam has some test drivers that have v4l2-ctl working at that resolution with a special 15fps mode, but I’d really love to see if we could get it working at it’s full 30fps, or even at 24fps. I still have a hard time understanding why Argus/ISP pipeline is able to handle 4032x3040 at 30fps, while v4l2 is not. The CSI MIPI bandwidth requirements are the same… Let me know if you have any thoughts on why that might be behaving differently.
So as far as this particular thread is concerned, it seems like the main culprit may be v4l2-ctl behaving incorrectly as far as how it sets the framerate control. I may try to reach out to the maintainers to see if they have any thoughts. I’ll mark this post as the solution for now, but do please let me know if you have any further thoughts about this framerate issue, or the 4032x3040 30fps v4l2 pipeline issue I mentioned above. Thanks!