I’m using an IMX219 sensor on a TX2.
I have updated kernel and device tree with a similar method than this web site:
The camera works well with gstreamer.
The camera doesn’t works with the argus library.
So for my software I’m using gstreamer programatic api.
It almost works well !
I have a major problem that’s remains:
I can’t change exposure-time.
On the preliminary version of our product we used JetPack 3.1 and the exposure-time could be changed.
With exactly the same software on a JetPack 3.3 version I can’t change the exposure-time.
Here is a little extract of my code:
g_object_set (m_source, "auto-exposure", (gint)1, NULL);
g_object_set (m_source, "exposure-time", (gfloat)0.005, NULL);
When I read the exposure-time using g_object_get function, the value is up to date.
If I set 0.005 or 0.5 on my other board on JetPack 3.1 I can see the difference easily.
On JetPack 3.3 there is no difference at all.
If I change other params with the same command like
g_object_set (m_source, "tnr-mode", 1, NULL);
g_object_set (m_source, "tnr-strength", (gfloat)0.5, NULL);
I can see the result in real time !
Any idea ?
hello nicolas.hilaire,
please refer to Topic 1033150, we had done the implementation to control gainRange, and exposureTimeRang with Argus plugin. please expect this will be include in the next public release. thanks
Thanks for your answer but I can’t use libargus with the imx219 driver, the cam isn’t seen by argus.
Have you an idea why it was working and now why it doesn’t work ?
hello nicolas.hilaire,
may I know what’s your commands to access camera with gstreamer,
could you please also share what’s the failure, thanks
1 Like
I try many commands in shell to make tests easier :
gst-launch-1.0 nvcamerasrc fpsRange="15 15" auto-exposure=1 wbmode=0 scene-mode=3 flicker=0 intent=3 wbManualMode=3 aeLock=true exposure-time=0.0001 ! nvoverlaysink
provides me same results as
gst-launch-1.0 nvcamerasrc fpsRange="15 15" auto-exposure=1 wbmode=0 scene-mode=3 flicker=0 intent=3 wbManualMode=3 aeLock=true exposure-time=0.0001 ! nvoverlaysink
Or light command lines :
gst-launch-1.0 nvcamerasrc fpsRange="2 15" auto-exposure=1 exposure-time=.001 ! nvoverlaysink
If I change exposure-time on JetPack 3.2 it’s working and on JetPack 3.3 it doesn’t.
For argus I have made test some month ago, I don’t remember the failure.
hello nicolas.hilaire,
thanks for sharing these testing results.
we will check this internally, will get back to you once we have conclusions.
thanks
hello nicolas.hilaire,
there’s issue that nvcamerasrc did not handle the exposure-time setting correctly,
could you please replace the /usr/lib/aarch64-linux-gnu/gstreamer-1.0/libgstnvcamera.so with the attachment, thanks
200472736_Dec04_libgstnvcamera.tar.gz (38.5 KB)
Thanks for your answer.
When I run it in command line with your attached file, I can change successfully the exposure-time parameter !
But the white balanced is deactivated.
I start the camera with different fixed exposures I can see a darker or a lighter image. But the white balance never try to make the picture lighter or brighter like it did in JetPack3.1.
Is the software you provide me, an up to date version ?
hello nicolas.hilaire,
yes, this is pre-build library is based-on JetPack-3.2 release.
may I know what’s your environment setups and how you determine the while balance, it would be helpful if you could attach the result images.
several experiments for testing:
- could you please confirm you were running in auto while balance mode.
- can you see the difference by setting to different while balance mode.
- is the manual wb configuration works when changing to manual white balance mode
Ok I will try to answer as much as I can to your questions :
Firstly to make my tries, I start the gstreamer command line, I see the picture and few seconds after I put a lamp in front of the camera to force it to reduce wb gain.
If the white balance is automatic, I must see variation of the whole picture luminosity.
1/ I’ve try with and without white balance mode
Here are the command lines I’ve tried
$ gst-launch-1.0 nvcamerasrc fpsRange="15 15" auto-exposure=1 exposure-time=.01 wbmode=0 ! nvoverlaysink
$ gst-launch-1.0 nvcamerasrc fpsRange="15 15" auto-exposure=1 exposure-time=.01 wbmode=1 ! nvoverlaysink
$ gst-launch-1.0 nvcamerasrc fpsRange="15 15" auto-exposure=1 exposure-time=.1 wbmode=1 ! nvoverlaysink
$ gst-launch-1.0 nvcamerasrc fpsRange="15 15" auto-exposure=1 exposure-time=.01 wbmode=3 ! nvoverlaysink
2/ No I don’t see any difference
3/ I’ve tried programmatically to change manual gains without any success too
g_object_set (m_source, "wbManualMode", (gint)3, NULL);
GArray * array = g_array_new (FALSE, FALSE, sizeof(gfloat));
gfloat gain = 16.0;
gfloat halfGain = gain / 2.0;
g_array_append_val(array, gain);
g_array_append_val(array, halfGain);
g_array_append_val(array, halfGain);
g_array_append_val(array, gain);
g_object_set (m_source, "wbGains", array, NULL);
g_array_free (array, FALSE);
Relevant facts :
-
When I use other wb gains like incendescent (3) or fluorescent (4) the global white balance change. The image is more yellow or more blue depending of the chosen wbmode.
-
With the original .so file previous command lines make the luminosity changes
Hope it helps.
hello nicolas.hilaire,
according to your comment#10, it seems there’s bug for AWB.
since this topic is filed for exposure-time issue originally.
I would suggest you open another new topic with all the details in comment #8 and #10, and share the linkage in the end of this thread. thanks!
I created antoher post for the white balance problem:
[url]https://devtalk.nvidia.com/default/topic/1044971/jetson-tx2/issue-on-white-balance-using-nvcamerasrc-and-gstreamer/[/url]
Have you any clue for me or an other temporary version with the two factors corrected ? Even blocked in auto exposure or blocked in manual with coefficients working ?
Thanks
hello nicolas.hilaire,
FYI, the fix in comment #7 already check-in our release code-line,
please expect this will be include in next public release (for example, l4t-r28.3)
thanks
1 Like
hello nicolas.hilaire,
AWB issue is under investigation internally.
will update the status at Topic 1044971 while we come out some conclusions.
thanks