Raspistill timelapse. Images get progressively darker

[quagga]

Hi
I had some initial success taking timelapse images using:
raspistill -n -t 7200000 -tl 5000 -vf -hf -o /home/pi/timelapse/%04d.jpg
and then stitching them together using mencoder.
however, (since updating to the latest firmware) now when i try it i get about 15 fully exposed images, but then they get darker frame by frame.
I thought maybe it was a power issue since I am running off batteries, but streaming using raspivid | netcat works fine.
I have tried using various exposure settings, but to no avail.
Any ideas?

[jamesh]

Sounds odd. Not had other reports like that. No changes in the SW should have had any sort of effect like that.

Joke alert. Was the sequence of a sunset?

[pi-man-uk]

I've seen this too. It only happened when I moved the cam outside on a sunny day.

[quagga]

It is currently sunny! ( and a long way from sunset )

[towolf]

I’ve mentioned this in another thread here http://www.raspberrypi.org/phpBB3/viewt ... 82#p359982

Includes example timelapse videos in both directions. Something got jinxed with the metering.

[bananen]

I added the -n switch on my timelapse commandline last night and today i experienced this aswell, removed -n and restarted my script and the problem seems to have gone away.

[towolf]

Makes sense, I always use -n (no screen attached)

[jamesh]

I added the -n switch on my timelapse commandline last night and today i experienced this as well, removed -n and restarted my script and the problem seems to have gone away.

That is utterly bizarre. I'll need to talk to some colleagues to see if they have any idea. I've some vague inklings concerning the use of the preview stream but they need confirmation.

[bananen]

I don't have anything connected on the hdmi or composite output ports which is why i figued i would add it.

[towolf]

I’ve turned the preview back on, but it is still doing stupid exposure things with raspistill --timelapse.

Started at night with "--exposure night" it fails to up and downregulate the ISO. So it’s stuck shooting 1/6000s at 800 during a sunny day. This is no issue with raspivid.

Code: Select all

Aperture Value                  : inf
F Number                        : 0
File Modification Date/Time     : 2013:05:29 10:18:23+02:00
                                  2013:06:02 10:29:23+02:00
Exposure Time   before          : 1/399
                        after     1/4405
ISO             before          : 100
                        after     800
Shutter Speed   before          : 1/399
                        after     1/4405
Brightness Value                : 3.3
                                  0.51

[towolf]

On a related note, James, if you will, can you give us a rough idea of what fixes we can expect next?

And what do you think about the idea of pushing your work to GitHub in a more fine-grained manner instead of making larger code drops?

[jamesh]

I’ve turned the preview back on, but it is still doing stupid exposure things with raspistill --timelapse.

Started at night with "--exposure night" it fails to up and downregulate the ISO. So it’s stuck shooting 1/6000s at 800 during a sunny day. This is no issue with raspivid.

Code: Select all

Aperture Value                  : inf
F Number                        : 0
File Modification Date/Time     : 2013:05:29 10:18:23+02:00
                                  2013:06:02 10:29:23+02:00
Exposure Time   before          : 1/399
                        after     1/4405
ISO             before          : 100
                        after     800
Shutter Speed   before          : 1/399
                        after     1/4405
Brightness Value                : 3.3
                                  0.51

Does using the default exposure mode work OK?

[jamesh]

On a related note, James, if you will, can you give us a rough idea of what fixes we can expect next?

And what do you think about the idea of pushing your work to GitHub in a more fine-grained manner instead of making larger code drops?

Any thing pushed to git hub needs to be checked, to ensure its works, and to ensure the code is readable. Once that's done it gets merged and at that point becomes available to all. Think that has happened once so far, for the GOP setting change, but we have some other stuff waiting in the wings - --exec and infinite runs I think.

At the moment I have had no chance to write code, check code, test code or merge code as we have had some customer issues to sort out which are much higher priority, and I have some other stuff to do at home. Dom may be able to help out when he has time - he's in control of the github stuff.

That's for the apps. For firmware changes, it's a bit more complex, and that requires the whole firmware blob to be re-issued. Some of the issue reported need firmware changes. After I've debugged and fixed them of course, and that's much more complex than the apps.

[recliq]

I can confirm this behaviour and that it's only happening with preview disabled.

[towolf]

On a related note, James, if you will, can you give us a rough idea of what fixes we can expect next?

And what do you think about the idea of pushing your work to GitHub in a more fine-grained manner instead of making larger code drops?

Any thing pushed to git hub needs to be checked, to ensure its works, and to ensure the code is readable. Once that's done it gets merged and at that point becomes available to all. Think that has happened once so far, for the GOP setting change, but we have some other stuff waiting in the wings - --exec and infinite runs I think.

I’ve seen those things and the forks people were sending pull requests from. I thought you maybe had a fork with something cooking in it too, but just not public yet. You were mentioning that you had added a timeout-less mode and meanwhile two other guys had sent pull requests to fix that too.

At the moment I have had no chance to write code, check code, test code or merge code as we have had some customer issues to sort out which are much higher priority, and I have some other stuff to do at home. Dom may be able to help out when he has time - he's in control of the github stuff.

That's for the apps. For firmware changes, it's a bit more complex, and that requires the whole firmware blob to be re-issued. Some of the issue reported need firmware changes. After I've debugged and fixed them of course, and that's much more complex than the apps.

I was more after fixes for the bad issues that only people inside Broadcom can fix. Kind of waiting for the binned, almost full-sensor mode for video. Would that be an ETA measured in weeks or in days?

It’s great that we have mmal headers, but these go only so far and the explanations are pretty limited. I was looking through them to find what is going on with the exposure problems and where it’s setting something in the example apps it’s not really clear what that really does behind the scenes.

[towolf]

I’ve turned the preview back on, but it is still doing stupid exposure things with raspistill --timelapse.

Started at night with "--exposure night" it fails to up and downregulate the ISO. So it’s stuck shooting 1/6000s at 800 during a sunny day. This is no issue with raspivid.

Does using the default exposure mode work OK?

Just tested this. It’s stuck with whatever ISO it evaluated as proper at the time of first capture.

A timelapse started today at 15:00 got stuck at ISO 100. The last picture in that timelapse was taken at 22:00 and has ISO 100 but exposure time 1/4. This is interesting. Normally it won’t go below 1/30 in stills mode. It looks like a very good picture at ISO 100. Sometimes long exposure time what one wants.

Then I started another timelapse and that one started at 22:00 and is now stuck at ISO 640.

This whole exposure calculation thing is broken to some degree. I’ve spent a lot of time looking into it, making plots trying to derive what’s happening in the little black box, but I cannot fully make sense of it. Instead it gives you things like "beach" and "fireworks","wedding chapel" and "minigolf".

Example:


At least I think in video mode it uses more solid mtering andcalculations for long running stuff.

[jamesh]

On a related note, James, if you will, can you give us a rough idea of what fixes we can expect next?

And what do you think about the idea of pushing your work to GitHub in a more fine-grained manner instead of making larger code drops?

Any thing pushed to git hub needs to be checked, to ensure its works, and to ensure the code is readable. Once that's done it gets merged and at that point becomes available to all. Think that has happened once so far, for the GOP setting change, but we have some other stuff waiting in the wings - --exec and infinite runs I think.

I’ve seen those things and the forks people were sending pull requests from. I thought you maybe had a fork with something cooking in it too, but just not public yet. You were mentioning that you had added a timeout-less mode and meanwhile two other guys had sent pull requests to fix that too.

At the moment I have had no chance to write code, check code, test code or merge code as we have had some customer issues to sort out which are much higher priority, and I have some other stuff to do at home. Dom may be able to help out when he has time - he's in control of the github stuff.

That's for the apps. For firmware changes, it's a bit more complex, and that requires the whole firmware blob to be re-issued. Some of the issue reported need firmware changes. After I've debugged and fixed them of course, and that's much more complex than the apps.

I was more after fixes for the bad issues that only people inside Broadcom can fix. Kind of waiting for the binned, almost full-sensor mode for video. Would that be an ETA measured in weeks or in days?

It’s great that we have mmal headers, but these go only so far and the explanations are pretty limited. I was looking through them to find what is going on with the exposure problems and where it’s setting something in the example apps it’s not really clear what that really does behind the scenes.

I cannot see the new modes being sorted for some time - I've got the register sets but they don't work in my tests. Normally takes ages to figure out that sort of thing. So weeks. Just as an idea, when we did the Nokia 808 code, we spent over a year on it. That including lots of modes, exposure issues to sort out, zooming problems etc. With a team of 6 people.

[jamesh]

I’ve turned the preview back on, but it is still doing stupid exposure things with raspistill --timelapse.

Started at night with "--exposure night" it fails to up and downregulate the ISO. So it’s stuck shooting 1/6000s at 800 during a sunny day. This is no issue with raspivid.

Does using the default exposure mode work OK?

Just tested this. It’s stuck with whatever ISO it evaluated as proper at the time of first capture.

A timelapse started today at 15:00 got stuck at ISO 100. The last picture in that timelapse was taken at 22:00 and has ISO 100 but exposure time 1/4. This is interesting. Normally it won’t go below 1/30 in stills mode. It looks like a very good picture at ISO 100. Sometimes long exposure time what one wants.

Then I started another timelapse and that one started at 22:00 and is now stuck at ISO 640.

This whole exposure calculation thing is broken to some degree. I’ve spent a lot of time looking into it, making plots trying to derive what’s happening in the little black box, but I cannot fully make sense of it. Instead it gives you things like "beach" and "fireworks","wedding chapel" and "minigolf".

Example:


At least I think in video mode it uses more solid mtering andcalculations for long running stuff.

That sounds like a bug in the driver. It shouldn't be locking the ISO between captures. But it's good information to help track down the problem.

[towolf]

Thanks. So I will temper my expectations then and maybe turn my attention to something else for some weeks.

One more thing, it would be really cool to have some definitions for what those exposure modes are doing. Hope that isn’t trade secret stuff. For example normal mode goes down to 1/30 (sounds kind of like a "maintain 30 fps" kind of deal, but why for stills?) night goes down to 1/4. What do the others do? Then metering. Which pixels does spot metering take into account, and what are the metering pixels in matrix and the weights?

I’d love to be able to override those limits, e.g., to allow much longer exposure time with tighter ISO limits but not fixed to one single level.

[jamesh]

Thanks. So I will temper my expectations then and maybe turn my attention to something else for some weeks.

One more thing, it would be really cool to have some definitions for what those exposure modes are doing. Hope that isn’t trade secret stuff. For example normal mode goes down to 1/30 (sounds kind of like a "maintain 30 fps" kind of deal, but why for stills?) night goes down to 1/4. What do the others do? Then metering. Which pixels does spot metering take into account, and what are the metering pixels in matrix and the weights?

I’d love to be able to override those limits, e.g., to allow much longer exposure time with tighter ISO limits but not fixed to one single level.

Note that the preview you get when waiting for a capture is unrelated to the actually capture done. The preview will attempt to run as fast as possible so will adjust accordingly. But the capture will not necessarily use the same settings.

I'm sure everything that everyone wants is mostly possible, but it all requires lots of work and hence lots of time. As does retrieving the information you are looking for from the tuning file (which is trade secret stuff - not my call though)

[sharix]

So this basically means we can(will be able to) lock a specific ISO value? exciting

[jamesh]

So this basically means we can(will be able to) lock a specific ISO value? exciting

Eventually. Well, it worked on the 808, so I'm sure it will work here. Did I say 'eventually' yet?

[jbeale]

For example normal mode goes down to 1/30 (sounds kind of like a "maintain 30 fps" kind of deal, but why for stills?) night goes down to 1/4.

The rule of thumb in handheld SLR photography was don't use a shutter speed slower than the inverse of the focal length of your lens. And the full-frame SLR equivalent lens on the R-Pi camera is 35 mm, so limiting exposure time to 1/30 sec might be based on the assumption it's a handheld mobile phone; therefore don't make the picture too blurry from hand motion, unless specifically requested ("night" mode).

Or, it's just a leftover from the video mode and not separately adjusted for stills.

[Questionario]

Same thing is happening to me, in sunlight the image gets darker and even gets more and more grain. it almost looks like it is shot in the middle of the night after a few frames.

with single shots the light is OK but the image seems to be a bit darker if I set a timelapse value (one shot only, so timeout same value) to 400 or above, at 250 it looks brighter.

I am also wondering why with tons of light I get so much grain with an HD camera, if I do a full sensor shot and look at the picture at 100% it looks as if the image has just been enlarged as there are not many details but a lot of grain, almost as if the ISO is chosen too high all the time.

not sure if this is all related...

[towolf]

For example normal mode goes down to 1/30 (sounds kind of like a "maintain 30 fps" kind of deal, but why for stills?) night goes down to 1/4.

The rule of thumb in handheld SLR photography was don't use a shutter speed slower than the inverse of the focal length of your lens. And the full-frame SLR equivalent lens on the R-Pi camera is 35 mm, so limiting exposure time to 1/30 sec might be based on the assumption it's a handheld mobile phone; therefore don't make the picture too blurry from hand motion, unless specifically requested ("night" mode).

Right, or that. 1/30 is already quite slow for hand holding. But in our case barely anybody is hand holding it and shooting from the hip, I presume.