long exposure not working on B+

[gonzothegreat]

Greetings,

Up to today, I was able to take long exposure pictures (over 10sec without issues) with the camera (NoIR) on my first gen model B. I say up to today as I have now a B+ model.
Sadly, I gave away my B the other day and re-formatted my sd-card for the B+. This means, I have lost the raspistill command I was using for long exposure.

Here are some details about the B+

Code: Select all

root@rpisky:/var/www/media# uname -a
Linux rpisky 3.12.24+ #694 PREEMPT Tue Jul 15 17:34:35 BST 2014 armv6l GNU/Linux
root@rpisky:/var/www/media# 

Code: Select all

root@rpisky:/var/www/media# /opt/vc/bin/vcgencmd version
Jul 15 2014 17:53:13 
Copyright (c) 2012 Broadcom
version ad89e56fcfdce27003bb1c722534d117d4bebf06 (clean) (release)
root@rpisky:/var/www/media# 

Code: Select all

root@rpisky:/var/www/media# raspistill 
raspistill Camera App v1.3.8

So far I have tried many combinations of raspistill with xyz options but cannot pass the 1s exposure time.
While on the B first gen, same camera, I was able to do star trails.
The camera is being used as a all-sky camera for night shots.

Code: Select all

raspistill -w 640 -h 480 -q 100 -e jpg -ISO 800 -ex night -ss 5000000 -rot 270 -o 5s.jpg

Here's the picture output from the above command:

exif:

Code: Select all

Aperture Value: 3.07
Brightness Value: 0.65
Color Space: sRGB
Components Configuration: 1, 2, 3, 0
Date Time Digitized: 20 Jul 2014 01:13:39
Date Time Original: 20 Jul 2014 01:13:39
Exif Version: 2.2
Exposure Mode: Auto exposure
Exposure Program: Aperture priority
Exposure Time: 1/0
Flash: No Flash
FlashPix Version: 1.0
FNumber: 2.898
Focal Length: 3.598
ISO Speed Ratings: 800
Max Aperture Value: 3.07
Metering Mode: CenterWeightedAverage
Pixel X Dimension: 640
Pixel Y Dimension: 480
Shutter Speed Value: 0.504
White Balance: Auto white balance

In fact, for example settings like:
-awb off does give a picture with green tint
-mm matrix does set it to average (exif verified)





Am I missing something or is there a an issue on the B+ model?




thanks for your time guys

[gagle]

In fact, for example settings like:
-awb off does give a picture with green tint
-mm matrix does set it to average (exif verified)

-awb off does give a picture with green tint

This is correct. When awb is set to off it enables the manual setting of the red and blue gains. If you don't touch them (they have a value near 0 by default), you get a green video/image.

-mm matrix does set it to average (exif verified)

This is correct. The names of the metering modes (in openmax spec and raspi*) are a bit different from the exif names, but all of them behave as they should.

[gonzothegreat]

-awb off does give a picture with green tint

This is correct. When awb is set to off it enables the manual setting of the red and blue gains. If you don't touch them (they have a value near 0 by default), you get a green video/image.

Thank you, I guess I was trying to compare this with my normal camera. When AWB is set to off, it shows a different kind of tint. Now I know, thanks

-mm matrix does set it to average (exif verified)

This is correct. The names of the metering modes (in openmax spec and raspi*) are a bit different from the exif names, but all of them behave as they should.

ok, good to know, thanks again.




Any thoughts on why I can't pass the 1s exposure?
I swear I was able to do it last week on my first gen B, I did manage to do a 20 sec exposure. Picture was starting to show star trails, hence I did lower the exposure back to 15 sec which was ideal for me.

I'm using the camera at night to monitor the sky, ie: it is cloudy or not, can I see some stars?

[gordon77]

Code: Select all

raspistill -w 640 -h 480 -q 100 -e jpg -ISO 800 -ex night -ss 5000000 -rot 270 -o 5s.jpg

If you are using -ex night doesn't it then ignore the -ss command ? I thought you had to have -ex off to use -ss.

gordon77

[6by9]

There's never been support for exposures over 1second on the Pi Camera. I'm not sure what you were doing via raspistill before, but it won't have achieved more than 1sec as the sensor register setup won't allow more currently (we need to alter the PLL setup to get longer).

[gonzothegreat]

There's never been support for exposures over 1second on the Pi Camera. I'm not sure what you were doing via raspistill before, but it won't have achieved more than 1sec as the sensor register setup won't allow more currently (we need to alter the PLL setup to get longer).

That's what I've been reading out, I have no idea how I managed to do long exposures and I regret formatting my sd-card now.
Had the commands I was running on it and a few test pictures

oh well live and learn.

[gonzothegreat]

Code: Select all

raspistill -w 640 -h 480 -q 100 -e jpg -ISO 800 -ex night -ss 5000000 -rot 270 -o 5s.jpg

If you are using -ex night doesn't it then ignore the -ss command ? I thought you had to have -ex off to use -ss.

gordon77

I will test that this evening, clear night where I am.

[jamesh]

There's never been support for exposures over 1second on the Pi Camera. I'm not sure what you were doing via raspistill before, but it won't have achieved more than 1sec as the sensor register setup won't allow more currently (we need to alter the PLL setup to get longer).

That's what I've been reading out, I have no idea how I managed to do long exposures and I regret formatting my sd-card now.
Had the commands I was running on it and a few test pictures

oh well live and learn.

You could not have been getting 10s exposures. That's impossible with the current firmware (and all previous versions).

[gonzothegreat]

ok thanks for the clarification. Well, not sure what I've done but it's definitely an odd one.
I shall wait until you guys figure out the unlimited exposure as in bulb mode.

[jamesh]

ok thanks for the clarification. Well, not sure what I've done but it's definitely an odd one.
I shall wait until you guys figure out the unlimited exposure as in bulb mode.

I'm not yet sure it's possible to do unlimited exposure. The sensor may not be capable. My efforts to go more than 1s have been stymied so far.

[6by9]

I'm not yet sure it's possible to do unlimited exposure. The sensor may not be capable. My efforts to go more than 1s have been stymied so far.

Bulb mode is certainly impossible. The sensor has to be told the exposure time in advance of starting the sensor streaming.

The way the majority of these sensors function is that they read out data at a defined pixel rate, normally determined by the phase locked loop on the clock input.
They then readout the defined region at that pixel rate, however you can add extra dummy lines onto the end of the image (which are not actually sent) to make it take longer between frames. The register setting the number of extra dummy lines appears to be only 15bits in size. At full resolution a line takes 32.539us. Combine those two facts and you get a maximum frame time of 1.066s at 5MPix.

I recall having had a look at this a few months back. The datasheet implies the register is 16bit, which means 2s exposure/0.5fps should be possible - memory says that it didn't work, but I can't remember why.
Exceeding that will require new PLL settings to alter the pixel rate. The downside is that this will reduce the max framerate possible, and potentially increase any rolling shutter effects as the temporal difference between each line being exposed is increased.
Getting this all to sit nicely and make everyone happy is not easy, but this is on the list of jobs.

[jbeale]

The datasheet implies the register is 16bit, which means 2s exposure/0.5fps should be possible - memory says that it didn't work, but I can't remember why.
Exceeding that will require new PLL settings to alter the pixel rate. The downside is that this will reduce the max framerate possible, and potentially increase any rolling shutter effects as the temporal difference between each line being exposed is increased.

Glad to hear there's still some hope of longer frames eventually. If the PLL is programmable, surely it could be set differently just in the case of long exposures, staying the same as it is now otherwise? Or is the PLL something that can only be set once per bootup, for example? Even if that were true, >1s exposure would still be of interest to many, I think.

[6by9]

Glad to hear there's still some hope of longer frames eventually. If the PLL is programmable, surely it could be set differently just in the case of long exposures, staying the same as it is now otherwise? Or is the PLL something that can only be set once per bootup, for example? Even if that were true, >1s exposure would still be of interest to many, I think.

Yes, it is programmable, but often doesn't just affect the pixel clock rate. And the other bit is when to switch the PLL settings, as it can't be done on-the-fly. Probably best to set up a new mode in addition to the 5MPix@1-15fps that is 5MPix@0.1-1.5fps or something, so the user has to select an appropriate framerate in the port format.
Worth also saying that the accuracy of the exposure times will be affected by this sort of change too, as that is done as a number of lines as well.
So many jobs, so little time.

[6by9]

We need to go back to Omnivision to get their opinion.
By halving the pixel clock rate I've just managed to get a mode running at 0.49fps, but only a max exposure of 1410ms when 2s should be possible.
Trying to halve the value again results in corrupt frames from the sensor, so it really isn't happy. This is the downside of fiddling with PLL values, as even things like the I2C clock are driven from it. Some sensors have independent PLLs and/or dividers for pixel clock and control clock, but the OV5647 datasheet just doesn't have enough info for me to determine if that is possible or not. Back on the back burner.

[6by9]

Found we had some more information already. Using that I've got the framerate down to 0.2fps (one frame every 5secs). Night exposure mode doesn't want to go above a claimed exposure of 1.4s for some reason, and I don't fancy playing about in that code!
Using manual shutter speed selection with raspistill, it appears to allow selection up to 4.2s, and then something overflows and we end up with very short exposure times. That one should be possible to sort though.

I just now need to grab the imaging lab and the kit in there to confirm that the exposure time really is the time that the sensor is being programmed with....

[jbeale]

Found we had some more information already. Using that I've got the framerate down to 0.2fps (one frame every 5secs). Night exposure mode doesn't want to go above a claimed exposure of 1.4s for some reason, and I don't fancy playing about in that code!
Using manual shutter speed selection with raspistill, it appears to allow selection up to 4.2s, and then something overflows and we end up with very short exposure times. That one should be possible to sort though.

4 or 5 sec exposures, if that is the actual effective exposure time, would be a big advance over the 1s we have now. This is very encouraging news!

[6by9]

4 or 5 sec exposures, if that is the actual effective exposure time, would be a big advance over the 1s we have now. This is very encouraging news!

You can be a happy man then!
We have exposure measurement equipment which is an array of LEDs that it lights in sequence for a defined time - video at https://github.com/6by9/RPiTest/blob/ma ... calib.h264 if you're interested. That is set to 500ms per column (it is also actually a staggered time running down each column, but that's less important for now).

https://github.com/6by9/RPiTest/blob/ma ... ec_exp.jpg is then a capture from Raspistill. All 100 lights illuminated, so overall exposure is around 5sec I've not accurately calibrated it as I've just scaled numbers from the other modes. If I'm bored tomorrow I might see if I can get some more accurate calibration numbers at the shorter range.

There is one thing left to try and resolve (may double the exposure time again, or may just not work), but otherwise I have probably exhausted the information that we currently have now. It might be worth going back to Omnivision for any other ideas, but we may well be at the limit. Do remember this is a £20 sensor designed for mobile phones, not a £500+ DSLR!

NB This is still rolling shutter, and with this config we're now taking 182us per line, so the difference between top and bottom lines is 353ms. Be very sure your subject is stationary!

[gordon77]

Excellent work

[jbeale]

That is great to see! I am looking forward to trying out this new mode. With a 5 second total exposure time, I guess the subject should be pretty still anyway, regardless of the skew effect I guess you mean the rolling shutter will have that amount of skew regardless of the exposure setting, when you are in this new mode. Anyway it seems fine for what the mode would likely be used for; timelapse with a fixed camera and still subject.

[astrofrank]

5sec integration time - it's a huge step forward. The rolling shutter isn't a feature, but many methods can live with the rolling shutter artefacts.
Thank you so much for extending the integration time into the many second range.

[6by9]

I thought the magic was working, but it seems 6 seconds is the maximum I can get.

The datasheet claims two of the registers (VTS and exposure) are 16 useful bits, but setting the top bit appears to just saturate the values and ends up doing nothing further. Seeing as it doesn't reduce the framerate it implies that it is VTS that is the issue. I'll email Omnivision to see if they've got any ideas.

I'll get the changes that I have got pushed for release, but there are a couple of caveats.

• The AGC algorithm doesn't seem to want to go above 1.4s exposure, so I think these will have to be manual shutter speed selections only.
• AWB is also entertaining to watch - it takes a moderate number of frames to adapt, so expect the quite a few images to be oddly coloured at startup, or use manual AWB.

There are a couple of changes that have to be made to the calling app to select this mode over the normal 1-15fps 5MPix mode, so there will be a userland update at some point too. Currently I've done it that a shutter speed exceeding 1sec makes the other changes - there seems to be no point in making selection any more complicated than that.

[6by9]

Firmware changes to get up to 6sec exposures went with commit cfd9a20 on Wednesday evening.
I've just pushed the Raspistill changes to https://github.com/6by9/userland/tree/PR-20140725 and done a pull request. This changes the requested frame rate range when the exposure requested is >1s.

Omnivsion have been great and provided a register set that in theory goes out to 20secs. Currently I get lots of errors from our receiver peripheral when I use it, so whilst Raspistill has a conditional in for >6sec, don't expect it to get there at the moment.
No complaints on image quality please! This is really pushing the sensor quite a long way outside the expected use cases, and it's not a DSLR costing hundreds of pounds!

[caracol_uk]

I've been following this thread (and other similar threads) with great interest as I'd like to set up a Raspberry Pi and a Pi Noir camera as a sky camera. I'm hoping that I can set the exposure length long enough to pick up meteor trails. Ideally that would probably need exposures of up to about 30s, though I'm very keen to see what I can do with the 6s you've managed to get.

I've downloaded the RaspiStill.c file you posted in userland and I've compiled this on my Raspberry Pi and all went well. However, the tests I've carried out don't seem to show any increase in exposure if I go above about 1.5s. You mention that we'll need to set the exposure time manually, so perhaps the command I'm using is not correct. This is the command I'm using for a 2s exposure:

raspistill -n -ss 2000000 -o /home/pi/2_0s.jpg

I'd be grateful if you could confirm whether this should work. It's possible that the compile process I followed is not correct. I used the process detailled here:

http://www.darkoperator.com/blog/2013/5 ... n-the.html

If this is incorrect any pointers would be much appreciated. I'm very grateful for all the hard work you have put making longer exposures available. It's fantastic.

Thanks
Simon

[caracol_uk]

I've worked out why it was not working for me. I upgraded the firmware after I had recompiled and installed the updated raspistill binary. The firwmare upgrade overwrote raspistill. It's working fine now that I've replaced raspistill once again.

So far I've obtained the best results by specifying an shutter speed of 6s with the ISO set to 800.

Simon

[6by9]

So far I've obtained the best results by specifying an shutter speed of 6s with the ISO set to 800.

6s and ISO800 is the highest you can go with the sensor at the moment, so that will be your lot for now.
30s is unlikely to happen, but I still have some hopes for 20s.