Setting exposure-time in gstreamer pipeline

Autonomous Machines Jetson & Embedded Systems Jetson TX2
1

Can someone review my pipeline string that I’m using in python and opencv on the TX2 default camera?

Am I placing exposure-time in the correct location and correct syntax?

[code]def open_onboard_camera():
return cv2.VideoCapture(“nvcamerasrc auto-exposure=1 exposure-time=.01 ! video/x-raw(memory:NVMM), width=(int)640, height=(int)480, format=(string)I420, framerate=(fraction)30/1 ! nvvidconv ! video/x-raw, format=(string)BGRx ! videoconvert ! video/x-raw, format=(string)BGR ! appsink”)
/code]

Setting auto-exposure to 1 or 2 disables and enables auto-exposure. This appears to be working. However, when auto-exposure is set to 1 (off), exposure-time seems to have no effect on the video.

2

Your exposure-time value may just be too high. Do a simple experiment with gst-launch to find out the right setting, just adjust exposure-time until you get the desired result:

gst-launch-1.0 nvcamerasrc auto-exposure=1 exposure-time=.0005 ! nvoverlaysink

NOTE: libargus provides fine control over analog and digital gain settings on the sensor. nvcamerasrc does not expose these controls, so you may end up fighting with them. We got frustrated enough by this issue to replace nvcamerasrc with our own libargus implementation so that we had much more precise exposure control.

3

Thanks. I Tried the gst-launch-1.0 command with a bunch of different exposure-times. No effect at all. The problem seems to lie elsewhere.

4

If you are using a stock TX-2 and onboard camera and this does not work then something is broken. I just verified this on my dev kit:

This should be black video:

gst-launch-1.0 nvcamerasrc auto-exposure=1 exposure-time=.0001 ! nvoverlaysink

This should be visible video if the sensor is looking towards an appropriately lighted area:

gst-launch-1.0 nvcamerasrc auto-exposure=1 exposure-time=.33 ! nvoverlaysink

5

Thanks, I tried the commands as listed. No success. Somehow I’ve messed up my TX2 with too many jetsonhacks. Will try to procure another one and start from scratch.

6

just reflash using jetpack to get back to “factory fresh”

7

I did a reinstall with the latest jetpack. Same problem. Pretty weird. Can’t be a hardware problem as the camera works fine with auto-exposure on.

8

bizzare. can you cut/paste the exact command line you are using?

9

have you tried the argus_camera application? If not, it is a useful tool for checking the sensor. Check the “AE Lock” box and then experiment with the exposure settings (they are in ns, not fractional seconds). The most useful knobs to play with initially are analog and digital gain.

10

I cut and pasted the two commands you listed previously into a terminal.

As for argus_camera, I did a find command search for it, could not find? How is it installed? The multimedia api should have been installed with the latest jetpack. Will keep searching.

11

/usr/local/bin/argus_camera

source can be found under multimedia_api/argus with build instructions in the README, but should be pre-installed. If not, then a good indicator that you have an incomplete install.

12

I was able to get argus_camera working. Had to be compiled and installed which was easy. The exposure settings work.

But the gst-launch-1.0 commands still do not work. Looks like I’ll have to learn argus if I want exposure control of camera.

13

see argus/samples/userAutoExposure for an argus app that provides user control of exposure, or gstVideoEncode for a good example of creating a libargus source to feed a gstreamer pipeline.

If exposure control is important for your application you will end up wanting to go the libargus route anyway. The exposure control provided by nvcamerasrc has a few issues: no gain control (analog or digital) and certain lighting conditions (twilight outdoors) triggering rapid flashing.

Note that NVidia also provides an nvarguscamerasrc for gstreamer. the current version lacks exposure controls.