il_diavolo
Posts: 139
Joined: Mon Dec 02, 2013 7:56 pm

Picamera long exposure - really?

Sun Aug 31, 2014 8:25 pm

I have updated my "Starwatch" astronomy program to incorporate the long exposure script from Picamera Documentation, Release 1.7, section 1.4.8 Capturing in low light. "Starwatch" is a Python script using Pygame and Picamera which shoots and displays rapid consecutive still jpegs or h264 video using the RPi as a WiFi hotspot connected by PuTTy and Tightvnc to my laptop.
Although the additional long exposure script seemed to work I was not convinced from the resultant images that I was really getting 6 second exposures, although I haven't actually tried it yet on the stars!
I set up a simple test by simply running the script printed in section 1.4.8, exactly as printed, photographing my old clockwork darkroom clock with a second hand, all placed in a darkened room. The resultant photograph (attached here) shows the problem.
I would have expected the red second hand to be blurred across 6 seconds but as can be seen it is only very slightly blurred, perhaps less than a second. The embedded exif claims an exposure of 5.97 seconds but an ISO of 6 (which is obviously incorrect. Note that the attached file is a reduced size copy to fit the size limit imposed here).
Is this the result of the rolling shutter? Does it roll side to side or up and down? Either way I would have expected any distortion to show a curved image of the second hand.
The most likely explanation is that I'm missing something here, anyone got any ideas?
Attachments
dark_2.jpg
dark_2.jpg (41.65 KiB) Viewed 12029 times

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 24192
Joined: Sat Jul 30, 2011 7:41 pm

Re: Picamera long exposure - really?

Mon Sep 01, 2014 9:10 am

Remember the Raspi camera uses a rolling shutter. That means each line is extended to get long exposures, so the exposure get longer line by line. So at least half your exposure time is spent at the top half of the clock, where the second hand isn't...the bottom line will be exposed nearly 6 seconds later than the top line.

You need a mechanism that displays something moving over the entire frame.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I think it’s wrong that only one company makes the game Monopoly.” – Steven Wright

PiGraham
Posts: 3671
Joined: Fri Jun 07, 2013 12:37 pm
Location: Waterlooville

Re: Picamera long exposure - really?

Mon Sep 01, 2014 9:40 am

il_diavolo wrote:I would have expected the red second hand to be blurred across 6 seconds but as can be seen it is only very slightly blurred, perhaps less than a second. The embedded exif claims an exposure of 5.97 seconds but an ISO of 6 (which is obviously incorrect. Note that the attached file is a reduced size copy to fit the size limit imposed here).
Is this the result of the rolling shutter? Does it roll side to side or up and down? Either way I would have expected any distortion to show a curved image of the second hand.
The most likely explanation is that I'm missing something here, anyone got any ideas?
Assuming the second hand jumps in increments of 1 second at a time I would expect 6 second exposure to show parts of the second hand in 5 or 6 positions on a scan line (horizontal), and curved.

If the hand sweeps continuously it should be blurred over 6 seconds and curved in places.

Your image seems to show about 0.6 seconds of blur.

Curious.

User avatar
Burngate
Posts: 6100
Joined: Thu Sep 29, 2011 4:34 pm
Location: Berkshire UK Tralfamadore
Contact: Website

Re: Picamera long exposure - really?

Mon Sep 01, 2014 11:05 am

jamesh wrote:... each line is extended to get long exposures, so the exposure get longer line by line. ...
Shouldn't that be later, rather than longer?

I think I'm confused.
Each line has 2592 pixels (so about 2k5). I can't get my head round "extending each line" - putting more pixels into it? Surely not?

In another thread (What is the Rolling Shutter Speed? 16 Aug 2014 13:34 )
6by9 wrote:Think of the sensor readout as having a "start exposure" line pointer and and "readout" line pointer. The time to read out a line is dictated by the mode but is otherwise fixed. Setting the exposure time controls the number of rows apart that the two pointers are. If you want an exposure that is longer than (line time)x(frame height) then extra dummy lines are added to the end of the frame (and the framerate drops accordingly).
I don't have the line times for each mode to hand, but we do quote the maximum framerate for each mode and that corresponds to reading out the frame with no extra dummy lines on the end. You should be able to work backwards from that to get the line readout time.
"Exposure time of 6s" means to my small brain that each pixel accepts photons for 6s
So 6by9's "start exposure" pointer sets off at top-of-frame, and 6s later his "readout" pointer sets off from the same point.
Meanwhile the "start exposure" pointer is rattling down to the bottom at some rate, x lines/s, with the "readout" pointer following 6s behind.
By the time the "readout" pointer has reached the bottom, the "start exposure" pointer has gone 6x lines below the bottom - hence the dummy lines.

From elsewhere it seems there's a maximum of 64k (or 32k?) dummy lines, so 6x<60k (or <30k?) and x<10k (or 5k?) lines/s - meaning 25M (12.5M?) pixels/s, but also (since there are 2k lines) >5s (>10s?) for the full frame to be read out after the 6s exposure ends at top-of-frame.

If the above is right, the second hand should have 6s of blur, whereever it is when the "start exposure" passes it, because it'll be 6s further on when the "readout" pointer passes where it was.

skypi
Posts: 111
Joined: Sat Aug 09, 2014 11:48 pm

Re: Picamera long exposure - really?

Mon Sep 01, 2014 11:16 am

I was also experimenting with 6s exposure and noticed the iso value at 6 in the exif data, and thought that's weird, I set it to 800 as shown in the picamera example. When I set the brightness parameter to 24 I noticed that exif ISO data now showed 1250 (and a brighter picture)

I think something has improved as I am now picking up tiny dots of stars, even under quite bad street light pollution.

maybe the firmware behaviour is changing faster than picamera can keep up with it?

EDIT: yeah, anyway, its good, can even see cloud motion which is partially what I'm after! (presently using an IR camera which may have better low light properties)

EDIT2: (I deleted part of edit 1) Sorry!!! not brightness, exposure_compensation was the parameter I was varying.... brightness I set to 50, takes about 16 seconds per shot

also get an awb value for your camera at normal operation in low light and set to that.

basically seems odd in operation, exposure_compensation=0 seems brightest, varying in any direction makes it dimmer?????? 0 gives ISO=1250 in exif data and brightest picture, by a long way....
Last edited by skypi on Mon Sep 01, 2014 10:59 pm, edited 2 times in total.

PiGraham
Posts: 3671
Joined: Fri Jun 07, 2013 12:37 pm
Location: Waterlooville

Re: Picamera long exposure - really?

Mon Sep 01, 2014 11:27 am

Burngate wrote:...
"Exposure time of 6s" means to my small brain that each pixel accepts photons for 6s
That must be the case, or it isn't 6s exposure.
Of course, just because 6s can be set doesn't mean that 6s is achieved.
Last edited by PiGraham on Mon Sep 01, 2014 1:02 pm, edited 1 time in total.

il_diavolo
Posts: 139
Joined: Mon Dec 02, 2013 7:56 pm

Re: Picamera long exposure - really?

Mon Sep 01, 2014 12:57 pm

I confirm that the second hand moves in discrete 1 sec ticks.
By the way, I am running Rasbian from a new image downloaded last week and Rpi-updated 2 days ago.
I'll try altering the brightness value to see if that makes any difference. In the meantime I'd be grateful if someone could advise me what the Raspstill string of commands should be so that I can check if I get the same result as I do using the Picamera Python script. (Yes, I know I should be able to work it out myself but I'm quite likely to get it wrong!)

ethanol100
Posts: 587
Joined: Wed Oct 02, 2013 12:28 pm

Re: Picamera long exposure - really?

Mon Sep 01, 2014 1:18 pm

I get 6s exposure with

Code: Select all

raspistill -ss 6000000 -awb off -awbg 1,1 -ISO 100 -t 60000 -o 6s.jpg
and I can see 6 different positions of the sweep hand. You can try a different ISO value, i.e. ISO 800 ,if ISO 100 gives a too dark image.

il_diavolo
Posts: 139
Joined: Mon Dec 02, 2013 7:56 pm

Re: Picamera long exposure - really?

Mon Sep 01, 2014 7:45 pm

Thanks ethanol100

I used your raspistill command string and can confirm that I got the picture I had originally expected, the second hand blurred over a 6 second arc.

I also find that using ISO 800 in both the Picamera script and in raspistill results in very different exposures, I needed to drop the raspistill ISO to 200 to get a similar exposure to the Picamera script, at 800 the raspistill was very over exposed (the room is not in total darkness) whereas the Picamera image was about right.

This would seem to indicate that there is a problem with the Picamera script, it does not produce the correct photograph. Has anyone any ideas as to how this can be rectified?

skypi
Posts: 111
Joined: Sat Aug 09, 2014 11:48 pm

Re: Picamera long exposure - really?

Mon Sep 01, 2014 11:03 pm

maybe it's that what the rpi foundation says what it should do is not what is does, but they know that in the raspistill command and firmware is modified according to how that works rather than how they publish it should work... bit like microsoft hidden api????? much like the entire establishment in fact!

fruit-uk
Posts: 609
Joined: Wed Aug 06, 2014 4:19 pm
Location: Suffolk, UK

Re: Picamera long exposure - really?

Tue Sep 02, 2014 5:44 am

skypi wrote:maybe it's that what the rpi foundation says what it should do is not what is does, but they know that in the raspistill command and firmware is modified according to how that works rather than how they publish it should work... bit like microsoft hidden api????? much like the entire establishment in fact!
Maybe you should read the camera development related posts from the last few weeks. A lot of work has been done - sadly just before some the Broadcom engineers who posted here, and provided a great deal of help, were made redundant.

AFAIK raspistill and raspivid were only ever intended as demo applications.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7578
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Picamera long exposure - really?

Tue Sep 02, 2014 6:11 am

fruit-uk wrote:AFAIK raspistill and raspivid were only ever intended as demo applications.
Correct. They are only demo apps, and also the only set of apps supported by the Foundation (along with the V4L2 driver).
Picamera is a 3rd party development, so whilst the Foundation/(now ex)Broadcom engineers have advised, there is no direct control over it.

My guess would be that the script (which I haven't looked at) ran with the wrong framerate parameters - if you say you want a minimum of 1fps, then the maximum exposure is 1second. To get 6s exposure, then you have to ask for <1/6fps. We can't bend time, and the sensor only exposes one frame at a time.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 24192
Joined: Sat Jul 30, 2011 7:41 pm

Re: Picamera long exposure - really?

Tue Sep 02, 2014 7:34 am

skypi wrote:maybe it's that what the rpi foundation says what it should do is not what is does, but they know that in the raspistill command and firmware is modified according to how that works rather than how they publish it should work... bit like microsoft hidden api????? much like the entire establishment in fact!
Absolutely not. Barring bugs, Rsapistill and vid should work as advertised. No hidden API's etc. Basically, they were both written to take advantage of what features are already available in the firmware, not to some arbitrary specification.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I think it’s wrong that only one company makes the game Monopoly.” – Steven Wright

il_diavolo
Posts: 139
Joined: Mon Dec 02, 2013 7:56 pm

Re: Picamera long exposure - really?

Tue Sep 02, 2014 10:02 am

It is not my intention to stir up conspiracy theories, only to see if I can get the software to work. The script from the Picamera documentation is:

Code: Select all

import picamera
from time import sleep
from fractions import Fraction

with picamera.PiCamera() as camera:
    camera.resolution = (1280,720)
    camera.framerate = Fraction(1,6)
    camera.shutter_speed = 6000000
    camera.exposure_mode = 'off'
    camera.iso = 800
    sleep(10)
    camera.capture('dark.jpg')
(Stripped of comments.) As can be seen the framerate is set at 1/6. The AWB is given 10 seconds to adjust by the sleep command whereas in ethanol100's raspistill command line the AWB is fixed?
Also, where is the framerate set in the the raspistill string?

Code: Select all

raspistill -ss 6000000 -awb off -awbg 1,1 -ISO 200 -t 60000 -o 6s.jpg
Interesting but, I hope, not controversial!

PiGraham
Posts: 3671
Joined: Fri Jun 07, 2013 12:37 pm
Location: Waterlooville

Re: Picamera long exposure - really?

Tue Sep 02, 2014 10:15 am

Picamera docs:Camera modes

Slowest listed frame rate is 1/s. Does Picamera actually support slow frame rates? 1/s would be consistent with the example clock image showing one tick.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7578
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Picamera long exposure - really?

Tue Sep 02, 2014 11:31 am

il_diavolo wrote:Also, where is the framerate set in the the raspistill string?

Code: Select all

raspistill -ss 6000000 -awb off -awbg 1,1 -ISO 200 -t 60000 -o 6s.jpg
Interesting but, I hope, not controversial!
https://github.com/raspberrypi/userland ... ill.c#L911

Code: Select all

 if(state->camera_parameters.shutter_speed > 6000000)
{
MMAL_PARAMETER_FPS_RANGE_T fps_range = {{MMAL_PARAMETER_FPS_RANGE, sizeof(fps_range)},
{ 50, 1000 }, {166, 1000}};
mmal_port_parameter_set(preview_port, &fps_range.hdr);
}
else if(state->camera_parameters.shutter_speed > 1000000)
{
MMAL_PARAMETER_FPS_RANGE_T fps_range = {{MMAL_PARAMETER_FPS_RANGE, sizeof(fps_range)},
{ 166, 1000 }, {999, 1000}};
mmal_port_parameter_set(preview_port, &fps_range.hdr);
}
There were register settings that in theory allowed 20s exposures, but we never got those working. The code to select it got added in the hope that it would work, hence the two ranges.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

il_diavolo
Posts: 139
Joined: Mon Dec 02, 2013 7:56 pm

Re: Picamera long exposure - really?

Tue Sep 02, 2014 12:45 pm

Many thanks, 6by9, my understanding is growing. I'll carry on experimenting. Best of luck with the job hunting.

il_diavolo
Posts: 139
Joined: Mon Dec 02, 2013 7:56 pm

Re: Picamera long exposure - really?

Wed Sep 03, 2014 9:40 pm

I am seeking some more help please. As the Picamera routine for a 6 second exposure is not working properly I have tried to call the raspistill command line in my main Python script using subprocess in this function:

Code: Select all

def longshot():
    i = camera.iso
    s = camera.shutter_speed
    g = camera.awb_gains
    a = camera.awb_mode    
    subprocess.call('raspistill', '-ss 6000000', '-awb off', '-awbg 1,1', '-ISO 200', '-t 60000', '-o /home/pi/Starwatch/dark.jpg')
    camera.iso = i
    camera.shutter_speed = s
    camera.awb_gains = g
    camera.awb_mode = a
However I get the following error:
File "usr/lib/python2.7/subprocess.py", line 629, in __init__
raise TypeError("bufsize must be an integer")
Type Error: bufsize must be an integer

I'm guessing that it doesn't like the numeric values contained in string quotes but I when I try to leave the numerals outside of the quotes I get a syntax error. How should I write the command string?

DirkS
Posts: 10018
Joined: Tue Jun 19, 2012 9:46 pm
Location: Essex, UK

Re: Picamera long exposure - really?

Wed Sep 03, 2014 11:32 pm

I think http://stackoverflow.com/questions/1189 ... ocess-call gives the solution
You have to put the command line arguments in square brackets

Gr.
Dirk.

User avatar
waveform80
Posts: 315
Joined: Mon Sep 23, 2013 1:28 pm
Location: Manchester, UK

Re: Picamera long exposure - really?

Thu Sep 04, 2014 2:30 pm

PiGraham wrote:Picamera docs:Camera modes

Slowest listed frame rate is 1/s. Does Picamera actually support slow frame rates? 1/s would be consistent with the example clock image showing one tick.
This issue should be corrected now (ethanol100 very kindly tested the new implementation) and with a bit of luck I'll be doing a release tomorrow evening.

Dave.

skypi
Posts: 111
Joined: Sat Aug 09, 2014 11:48 pm

Re: Picamera long exposure - really?

Thu Sep 04, 2014 7:34 pm

jamesh wrote:
skypi wrote:maybe it's that what the rpi foundation says what it should do is not what is does, but they know that in the raspistill command and firmware is modified according to how that works rather than how they publish it should work... bit like microsoft hidden api????? much like the entire establishment in fact!
Absolutely not. Barring bugs, Rsapistill and vid should work as advertised. No hidden API's etc. Basically, they were both written to take advantage of what features are already available in the firmware, not to some arbitrary specification.
my meaning was more that raspistill was probably the app used to test recent cam firmware changes, because the picamera 1.7 example for long exposure does not work, yet if you leave exposure_mode as auto and do a loop of taking individual stills first one says it is ISO 1250 and subsequent ones drop to ISO 800 (in the exif data) but picamera says ISO 800 is max, and actually I'd like to get the first (ISO1250) bright exposure every time.

I appreciate it's a work in progress, perhaps picamera needs to specify a firmware revision that a picamera version works with, I see rpi-update already does allow specifying a firmware revision to install.

anyway I was pleased to see that long exposures are possible, thanks. (even though not quite working as expected yet from picamera)

User avatar
waveform80
Posts: 315
Joined: Mon Sep 23, 2013 1:28 pm
Location: Manchester, UK

Re: Picamera long exposure - really?

Fri Sep 05, 2014 12:40 am

skypi wrote:
jamesh wrote:
skypi wrote:maybe it's that what the rpi foundation says what it should do is not what is does, but they know that in the raspistill command and firmware is modified according to how that works rather than how they publish it should work... bit like microsoft hidden api????? much like the entire establishment in fact!
Absolutely not. Barring bugs, Rsapistill and vid should work as advertised. No hidden API's etc. Basically, they were both written to take advantage of what features are already available in the firmware, not to some arbitrary specification.
my meaning was more that raspistill was probably the app used to test recent cam firmware changes, because the picamera 1.7 example for long exposure does not work, yet if you leave exposure_mode as auto and do a loop of taking individual stills first one says it is ISO 1250 and subsequent ones drop to ISO 800 (in the exif data) but picamera says ISO 800 is max, and actually I'd like to get the first (ISO1250) bright exposure every time.

I appreciate it's a work in progress, perhaps picamera needs to specify a firmware revision that a picamera version works with, I see rpi-update already does allow specifying a firmware revision to install.

anyway I was pleased to see that long exposures are possible, thanks. (even though not quite working as expected yet from picamera)
I'd love to specify a firmware revision in picamera's deb packaging (obviously I can't in the PyPI package as pip is entirely independent of any platform's package management). Unfortunately, in Raspbian the firmware isn't managed via apt, but by the auxiliary rpi-update script (as you've noted). If it were managed via apt (as it is in Debian/Ubuntu/etc.) I could specify a simple dependency in the picamera deb package's metadata and apt would enforce that upon upgrade (which would've saved all the hassle with the mmal_queue_timedwait stuff in 1.7).

Although one can specify a commit with rpi-update, it would be exceedingly unwise for me to force an installation of the firmware during picamera's deb package postinst script. For starters, that would involve an apt package messing around with files that it doesn't claim to own, but more importantly when future firmwares are released it would potentially involve the package downgrading people's firmwares. Then there's the whole question of custom firmwares (these are more common than some people realize: for example, anyone with a PiTFT display is most likely running a custom firmware).

Basically, it's not something I'd contemplate doing. For now, the best solution is for me to actively encourage people to keep their firmware up to date (in order to take advantage of the latest functionality), while trying to maintain backwards compatibility in picamera.

On the subject of ISO, I'll bump the limit to 1600 in 1.8; it was only set to 800 as I'd read somewhere on the forum that that was the maximum setting available. If higher's available, great! The MMAL layer doesn't seem to enforce any limit (you can tell it to set 10000 if you want and it won't complain, but it also won't actually give you that). The picamera library's limit is purely there because I figure that if a developer's script sets a silly ISO they'd probably rather have their script bomb with an exception than silently proceed and produce an unexpected result ("brittle code" and all that).

Dave.

skypi
Posts: 111
Joined: Sat Aug 09, 2014 11:48 pm

Re: Picamera long exposure - really?

Sun Sep 07, 2014 10:07 pm

Just updated to 1.8 in an upgrade, and leaving all params on auto except set framerate and shutter speed and ISO (not sure if thats even necessary) and gives a very nice night exposure at 6s. But the exif data does not reflect any params if you switch any mode off. I guess exposure_compensation is moot as it's fixed aperture, (brightness the same?) so vary shutter speed really all you've got. It also now sets a reasonable white balance by default.

I'd say in the docs, just recommend the commit # for rpi-update.

anyway, cool thanks!

skypi
Posts: 111
Joined: Sat Aug 09, 2014 11:48 pm

Re: Picamera long exposure - really?

Mon Sep 08, 2014 3:00 pm

Checking last nights photos, perhaps not Andromeda, probably Hyades... but pi camera using picamera library now taking quite good long exposure pictures.

User avatar
waveform80
Posts: 315
Joined: Mon Sep 23, 2013 1:28 pm
Location: Manchester, UK

Re: Picamera long exposure - really?

Mon Sep 08, 2014 8:21 pm

skypi wrote:Just updated to 1.8 in an upgrade, and leaving all params on auto except set framerate and shutter speed and ISO (not sure if thats even necessary) and gives a very nice night exposure at 6s. But the exif data does not reflect any params if you switch any mode off.
Not quite sure I understand what you mean by "switch any mode off"? Do you have a code example that could reproduce the lack of Exif data?
skypi wrote:I guess exposure_compensation is moot as it's fixed aperture, (brightness the same?) so vary shutter speed really all you've got. It also now sets a reasonable white balance by default.
exposure comp seems to have some effect (at least when I last looked at it in picroscopy) but I assumed it's just fiddling with gains under the hood (I haven't checked this though - might be interesting to query analog_gain and digital_gain while fiddling with exposure_compensation) or doing some post-processing to emulate the effect.
skypi wrote:I'd say in the docs, just recommend the commit # for rpi-update.
I added in a note in the install section for 1.8 which recommends just updating to the latest firmware with rpi-update - I figure that's probably enough for now (no need to confuse newcomers with commit hashes just yet :)


Dave.

Return to “Camera board”