5

When using raspistill in -ex auto mode, I noticed that the timeout (-t) parameter defines the maximum exposure time; for instance, when setting it to 1000, it rarely sets an exposure time of 1 second, but instead automatically finds the best exposure time under that value.

However, when trying sports mode with a shorter timeout value (-t 50), to my surprise most* pictures had a fixed exposure time of approximately 50 milliseconds, and were overexposed. It's as if timeout became synonym to shutterspeed, instead of simply a maximum value.

(*A few pictures were mostly green with a very short exposure time, due to sun glare, but most were exactly 50 milliseconds.)

My ultimate goal was to obtain non-blurred pictures while the camera is moving, choosing sports to enable higher ISO instead of longer exposure time.

Unfortunately, I cannot easily reproduce outdoors lighting + shaking conditions to test with several combinations of parameters, so I'd like to understand the logic behind it before trying again. The documentation is not very extensive w.r.t. difference between sports and antishake, for instance.

Is it expected that timeout only works as expected under the auto exposure mode? Is there another way to obtain a somewhat automatic exposure time, but minimizing blurring by increasing maximum ISO if needed?

Edit: I've finally been able to do some new tests, and here's what seems to be happening, though I don't understand why.

raspistill -? says the following for the -t parameter:

-t, --timeout   : Time (in ms) before takes picture 
                  and shuts down (if not specified, set to 5s)

So, in theory -t should have nothing to do with exposure time, however in practice this is not what happens. Note: all the measurements below were done with sports mode (-ex sports).

First and foremost, if I want the raspicam to immediately take a picture, I should be able to set -t 0, right?

Well, unfortunately this blocks the command as if I were trying to make a video with infinite length, or something equivalent.

If you specify -t 0 for raspistill, you can wait for a very long time and the command will not stop, and doing Ctrl+C to exit it will kill the process without producing any output file.

Secondly, setting -t 50, for instance, should result in waiting for 50 milliseconds, then capturing data for an indeterminate amount of time (depending on exposure settings, available light, etc.).

However, in practice this works almost as setting the exposure time to be approximately equal to the output of -t.

I tried it with -t 50, and the exposure time is 1/202 seconds for every picture, resulting in overexposed images.

I then tried it with -t 1, and the exposure time went to 1/820 seconds, but the pictures were still overexposed.

Finally, I specified no -t and got the expected "wait 5 seconds" before the picture was taken, and then it was correctly exposed at 1/5587 seconds.

My main question is: using the sports mode (-ex sports), how can I quickly take correctly-exposed pictures without having to wait 5 seconds between them?

It seems that should be possible, but even after several tests I cannot do that! It could be a bug in option parsing for raspistill, or I misunderstood the options, but I tried several combinations that seemed to make sense, but I still cannot get it to immediately take a picture with correct exposure time.

3

I still don't get it, but here's what I empirically observed for raspistill, by leaving the camera fixed pointing at an outdoors scene in a sunny day, and taking series of pictures with different arguments for -t. I always used -ex sports during these tests.

  • -t 0 is simply buggy and leaves the camera exposing indefinitely (the LED remains on, but no output file is written); while it makes sense for video, I fail to see its use in raspistill, since unlike raspivid, the timeout is supposed to be the time before the picture is taken, which should be zero in this case, but instead is infinite.

  • Timeout values between 1 and 500 result in bad, mostly overexposed pictures which follow some weird correlation between exposure time and the timeout argument. While not linear (e.g., for values of -t progressively larger than 50, I get shorter and shorter exposure times), this relation is exemplified by the fact that the same scene is overexposed with a fixed exposure time, according to the argument given to -t. E.g., for -t 300 I got 1/484 s, for -t 150 I got 1/268 s, and for both -t 80 and -t 50 I got 1/202 s. All of them overexposed.

  • For values progressively larger than 500, the camera seems to correctly adjust the exposure. Just in case, I'll try using -t 1000.

Unfortunately, while the camera does manage to take about 1 picture per second using the shortest values of -t (including the time used to sync the image file to my SD card), with -t 1000 I cannot get more than 1 picture/2 seconds, and I'm afraid that most of that time the camera is simply waiting for... something.

In conclusion, to get less blurry pictures, it seems that -ex sports does not help much, but cranking up the ISO value seems a better solution. Therefore, I'm now using -ISO 400 -t 1000 to get about 0.5 pictures/second, with better exposure.

After performing a field test, most photos now seem correctly exposed, although there is an alarming number of photos with 1/5587 s of exposure time which seem a bit overexposed. I wonder if that is the maximum limit for -t 1000, or some other magical constant, like minimum exposure time for the camera.

I still have the occasional "green shot", where the image is mostly green and white, due to lens flare (and possibly the fact that I use a RaspiNoIR instead of a "standard" Raspicam), but these I already had before trying the sports setting.

  • -t 0 is useful for time lapse (-tl), e.g. you want to take image every 1 sec for 1 hour total; but yeah it seems buggy with raspiyuv at least or maybe for raspistill too if you output to -, it quits after 45-60 minutes for me; however i remember doing time lapse over night to files successfully – tomasb Feb 7 at 16:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.