each corresponds to the settings of a camera on the CSI bus.
As cospan described, somehow nvcamera-daemon built bad caches for camera settings except for the first one.
The contents are very much different between the caches in binary comparison.
Interestingly, if you copy the nvcam_cache0.bin and use it to override the other cache files, you got a good result. The colors appear balanced. Apparently, this is not the approach supposedly to handle multiple cameras.
I checked the device tree, all the camera modules are defined in DTSI, and each has a unique badge name.
What is the requirement in DTSI or other settings in order to generate the cache properly?
Hi ShaneCCC, thanks for the direction.
Our team did the test and here are the result:
Saved a copy of the "good" nvcam_cache_0.bin
The configuration is for six cameras, keep it is.
Delete all cache*.bin file under /var/nvidia/nvcam/settings/
Run terminal command (randomly pick one of the cameras): gst-launch-1.0 nvcamerasrc sensor-id=5 ! 'video/x-raw(memory:NVMM), width=1920, height=1080, framerate=30/1, format=NV12' ! nvvidconv flip-method=2 ! nvegltransform ! nveglglessink -e
The execution re-creates all cache*.bin files automatically
Compare the files, all are same
Color is off (as if saturated)
Take the saved nvcam_cache_0.bin to replace all the caches.
Re-run the video, the color is good.
We couldn’t tell how the “good” nvcam_cache_0.bin was initially generated. It could be created and stayed since we started the test in configuration of a single camera, or it could be from the original default camera. That actually leads to a question regarding how is the cache file generated. We had to flash the device tree when change the camera set configuration. Here are two questions:
How is the cache file get generated?
Is it dependent on the sensor used?
Hi ShaneCCC, we did some extensive tests and analysis, here are what we found:
Rebuilt the JetPack 3.1 on TX2, practically wipe out everything. The cache file /var/nvidia/nvcam/settings/nvcam_cache_0.bin was generated by the very first GST command and the cache file stays.
Found that re-building the kernel with new camera modules won't move the cache file.
Found that flashing new DTB from the Host, followed by GST command won't move the cache file.
If the cache file was removed manually, GST command will re-generate the cache.
We also noticed that
Need to remove the cache each time when switching DTB for different cameras
The keyword in the badge definition, such as "P5V27C" for build-in sensor plays a critical role in camera operation
Now I need you guys help in DTS and DTSi badge setting.
(a) Which keyword should be used for IMX219’s badge? As there are A815P2 in ref (1), P5V27C in ref (2), etc; any guideline for the selection?
(b) If I use keyword A815P2 in the badge for IMX219, the camera would adjust the exposure slowly and take a few seconds to settle on a rather dark display. So the question is how the keyword relates to the underline nvcamera-daemon/ISP stacks, and if anything else should be matched in order to fit the ISP and nvcam operation?
(c) Are those keywords created by certain coding method?
(d) Is there a naming convention for the badge in DTSi?
@tmx3
The badge info for the reference IMX219 sensor is A815P2, however it’s may not fixed to your sensor because the lens may not the same. If it’s different lens you need go through tuning process for this sensor. You need scaling partner’s help for the tuning process if want it.
From TX2’s ISP/nvcam perspective, I’m not sure if I follow the idea of altering the badge keys to a code other than A815P2 when lens changes, say from standard 35mm to fisheye, etc… A requirement of using different key would lead to the existence of other parameters in the DTS settings in order to balance the result.
My tests also indicate that the badge setting is tightly coupled to the image processing and camera control.
As mentioned earlier, for example using IMX219 sensor, if I set the key to A815P2, the video takes about 5 seconds to gradually turn the picture brightness from over exposure to nightly dark. If I replace the key with an arbitrary string of characters , the exposure appears to be adjusted very quickly, but the color balance is slightly off. It appears as if a badge settings with a wrong keyword would simply disable the control.
@tmx3
The ISP configure for A815P2 IMX219 is totally different with your module. Our module is not fish eye lens. You should new a badge for your module and go through the tuning process to get great image quality.
Hi ShaneCCC, yes, I understand the point that different camera module needs a different configuration.
NVidia has published massive amount of data to promote the TX2 based eco-system. Sometime it’s hard to find the specific piece of information. Thanks you for the information about the importance of badge keyword in DTSi.
That leads to my next step of learning about the DTSi settings for TX2 applications. Let me list related questions for reference, not necessarily have to be resolved all the once.
How is the badge keyword, such as A815P2, related to the operation of TX2 camera ISP?
What's the guideline about the device tree coding for Jetson CSI-2 cameras, particularly to the section of tegra-camera-platform in DTSi ?
What's the best way to force the GStreamer pipeline to refresh the nvcam cache, other than manually remove the caches under /var/nvidia/nvcam/settings?
We tried badge A815P2 and encountered similar issues like exposure. Still, A815P2 seems the best for IMX219 so far. Would like to hear if any better badge code for the sensor.
Frankly, given the raw camera modules on hand with all kind of manufacturing issues and driver settings, the color tuning becomes a darkroom casting on camera makers in finding the resolution. It makes us rather difficult to determine whether the problems were caused by manufacturing defects, driver bugs, register initialization, or something had to be handled by the down stream development such as color tuning.
What I’d hope is that nvidia could open some sort of commands to the developers for a basic level of color tuning. Once the hardware had been confirmed functioning properly, we would be in a better position to acquire the funding and resources to work with the scaling partners for further enhancement.
We had to tweak the c file and header according to IMX219 spec, pretty much try-and-error. For example, we found that the setting of initialization for
/* Coarse Integration Time /
{0x015A, 0x04},
{0x015B, 0x22},
works better that the original
/ Coarse Time */
{0x015A, 0x0D}, {0x015B, 0x05},
We also added a mode for 3280x2464 @21 fps. It’s an on-going process.
