So I am running on Jetpack 4.6.1, with L4T upgraded to 32.7.3, and I am running a single Raspberry Pi HQ IMX477.
When I run
nvargus_nvraw --lps
or
v4l2-ctl -d /dev/video0 --list-formats-ext
I am only seeing resolution modes up to 3840x2160, when I believe I should be able to capture the full resolution of the camera at ~4032x3040. I can run
Which seemingly produces an image with 4032x3040 pixels according to the properties window, but unsure if that is accurate and its really just a 3840x2160 image.
Is 3840x2160 the maximum supported by the native jetpack/kernel driver for this camera? Do I need a third party driver or am I doing something wrong here?,
I downloaded the source code (from the provided link above) and I can see the maximum resolution that is supported is 3840x2160.
In general you could extend the IMX477 device driver provided in the L4T sources. It requires some kernel development to extend the modes table to support your resolution and also diving into the sensor datasheet to be able to figure out the required register configuration, but it is possible. There is extensive documentation provided by NVIDIA about camera driver development in the Sensor Programming Guide
Also as a final note, RidgeRun has wide experience in the development of kernel drivers, we can develop (or port) the new drivers for you. You can visit our main websiteor please email to support@ridgerun.com for technical questions and contactus@ridgerun.com for other queries.
Also I did notice that the v4l2-ctl utility is now hanging indefinitely when trying to take an image, but it does still recognize the sensor and the new capture mode
I am not aware of your hardware setup but it could be possible that this Arducam driver you installed is intended to work with their MIPI camera modules. That could explain why the device driver is not working as intended for you.
I am able to produce the full resolution jpeg images using gstreamer and the nvraw utility, so I think those are operating ok. It seems there is some incompatibility with v4l2
I see, can you please shared the v4l2-ctl command that you are using? What do you mean that you are having trouble to parse the RAW file capture with nvraw? Have you tried using --format “raw”?
The issue I am having with the raw file is that I am unable to open it in any photo software to read it visually. Also, I would like to read the pixel by pixel data from the image, so what I mean is parsing out values for each pixel. Since when I load it into matlab it produces a 1-D array, Im not sure how to rearrange that data to figure out which values belong to which pixels.
As for the command:
Here is what I am running to see the available modes:
I was checking in detail the driver that you are currently using. By browsing and inspecting the installation procedure that you pointed out in this repo: Automatic installation script. I was able to find several things:
That script is outdated. It installs a older version of this device driver.
Having installed an older version of the driver means there is a mismatch between the JetPack release that you are using and the support of the device driver. This is in general not recommended.
My recommendation is to rebuild the IMX477 module for the JetPack version you are using (4.6.1). That requires to build the official BSP sources that can be downloaded here: Jetson Linux R32.7.1 Release Page | NVIDIA Developer. About your specific question of the imx477_mode_tbls.h file. That link provided previously will download a tarball called “public_sources.tbz2” that you can unpack. Once unpacked you can find the Linux kernel sources at: public_sources/Linux_for_Tegra/source/public/kernel_src.tbz2 and if you unpack that one kernel_src.tbz2 package you will find the file that you are looking for at: kernel_src/kernel/nvidia/drivers/media/i2c/imx477_mode_tbls.h
Just as an additional note. That IMX477 device driver was developed by RidgeRun in collaboration with NVIDIA, that is why it is shipped as part of the official Jetson Linux sources. The Arducam repo that you used actually uses an outdated set of patches of that same driver. That is why I recommend sticking with the official sources from NVIDIA instead.