long exposure not working on B+

[caracol_uk]

The results from last night using 6s exposures were better than I had anticipated so I don't think 30s would be necessary after all. 15-20s would probably be plenty for me, though the 6s I now have has unlocked so much potential for the camera/pi. Thanks again.

Simon

[gordon77]

Any examples ?

gordon77

[caracol_uk]

Here are a few examples. The photos taken inside were just to establish whether the increased exposure commands were working. The 6s exposure at ISO 800 was taken through an open window at about 2am this morning. The clouds are clearly visible, more so than was possible with the naked eye. Ultimately I'd like to use the camera to detect meteor trails, so an increase in gain(i.e. higher ISO) may prove more effective than an increase in exposure at this stage.

The camera I've used is the Pi Noir as I'm not at all concerned with white balance but require the slight extra sensitivity that the lack of the IR filter provides.

Simon

[gordon77]

Cheers.

[jamesh]

That's pretty good for 2am! Much better than I was expecting. NIce one 6x9!

[jbeale]

what is the dead time between exposures? That is, if you take many 6-second shots in a row, what fraction of the time is the camera not gathering light? I guess I can find out myself... I just do rpi-update and then compile the new raspistill?

[6by9]

what is the dead time between exposures? That is, if you take many 6-second shots in a row, what fraction of the time is the camera not gathering light? I guess I can find out myself... I just do rpi-update and then compile the new raspistill?

Fairly high at the moment I suspect. If you set the BURST_CAPTURE parameter before the first capture then it will stop the mode switching back to preview, but there is still the lurking issue of AGC steadily shifting to black then (may not be applicable as we're in almost a full manual mode). I think we're set up such that the sensor shouldn't be stopping between captures, so that means we're not having to drop a frame on every capture, a at 6 sec exposures that frame takes a while.

Yes,
- rpi-update
- git clone https://github.com/6by9/userland.git
- cd userland
- ./buildme
(I sometimes find it doesn't update the default raspistill executable so have to run build/bin/raspistill instead)

[gordon77]

I'm running raspbian dated 20/6/14, l did a Sudo apt-get update and upgrade and a rpi-update today and now note my guide program now only takes images at best every couple of seconds where as it was 600 to 700ms before, using raspistill, could anything have changed? I haven't had time to fully test yet.

Gordon77

[caracol_uk]

I notice that by using the -ex sports or -ex night modes it's possible to get the camera to take images at ISO 1600. However, attempting to use either of these modes in combination with -ss 6000000 results in the ISO being set to 80 for sports and 100 for night. Would it be difficult to allow the ISO to be manually set to 1600 in combination with long exposure times? I realise the result may not look particularly nice by most peoples standards, but this would be a great help to me. If it does turn out to be possible to push exposure lengths to 20s this should result in quite good low light performance.

Simon

[jbeale]

- rpi-update
- git clone https://github.com/6by9/userland.git
- cd userland
- ./buildme

The above commands did not give me the new raspistill. I checked and the new code in https://raw.githubusercontent.com/6by9/ ... spiStill.c has some lines that the regular .../6by9/userland.git does not, for example

Code: Select all

878a879,890
>    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);
>    }

compiling the new code does give me a raspistill that works, so I am trying that out now...

[jbeale]

The new raspistill really works for longer exposures! Very happy to see this new functionality. I am a bit confused about why, when I ask for a 5 second delay and then a 5 second exposure, the command actually takes almost 32 seconds. Actually, a 1 second exposure is also slow. I gather it waits 4 or 5 frame times for white balance or something, before taking the real exposure? Is there a way to avoid that?

Code: Select all

$ time raspistill -t 5000 -ISO 800 -ss 5000000 -o test5.jpg
real    0m31.884s
user    0m0.010s
sys     0m0.090s

$ time raspistill -t 5000 -ISO 800 -ss 999000 -o test6.jpg
real    0m9.015s
user    0m0.040s
sys     0m0.060s

"raspistill -t 2000 -ISO 800 -ss 6000000 -o 6sec.jpg" took 37.7 seconds to complete.

Anyway, as you can see below, nighttime at 5 or 6 seconds looks a lot different than 1 second! View of backyard at 11 pm through a window, with fisheye lens adaptor on RPi camera. The lights along the middle of the frame are little solar-charged 1-AAA NiCd cell LED garden lights.

1 second

test6-1sec.jpg (23.54 KiB) Viewed 6655 times

5 seconds

test5-5secExp.jpg (31.85 KiB) Viewed 6655 times

6 seconds

6sec.jpg (34.13 KiB) Viewed 6641 times

[ethanol100]

No way to get it faster, one frame will be taken for the preview, then the camera requests a mode switch, taking again about 1 frame, after the mode has changed the first frame is garbage, and we need to wait for at least the next one. so a minimum of 4 frames or 24s is needed to get one image(plus startup time and modeswitch time...).

-t 0 means run forever. It will never create an output.

[jbeale]

One frame will be taken for the preview, then the camera requests a mode switch, taking again about 1 frame, after the mode has changed the first frame is garbage, and we need to wait for at least the next one. so a minimum of 4 frames or 24s is needed to get one image(plus startup time and modeswitch time...)

Ok, but the example of getting full-res stills at 15 fps http://www.raspberrypi.org/forums/viewt ... 91#p585569 suggests that for multiple exposures, after the startup delay, we ought to be able to get frames more often than 1 out of 4 ? That's actually more interesting to me, than whatever the startup delay is.

[6by9]

The above commands did not give me the new raspistill. I checked and the new code in https://raw.githubusercontent.com/6by9/ ... spiStill.c has some lines that the regular .../6by9/userland.git does not, for example

Sorry, pushed it to my branch for the PR and forgot to push to the main branch. The PR has been merged, so just picking up the latest raspberrypi/userland should get the changes.

One frame will be taken for the preview, then the camera requests a mode switch, taking again about 1 frame, after the mode has changed the first frame is garbage, and we need to wait for at least the next one. so a minimum of 4 frames or 24s is needed to get one image(plus startup time and modeswitch time...)

Ok, but the example of getting full-res stills at 15 fps http://www.raspberrypi.org/forums/viewt ... 91#p585569 suggests that for multiple exposures, after the startup delay, we ought to be able to get frames more often than 1 out of 4 ? That's actually more interesting to me, than whatever the startup delay is.

Raspistill is demo code only!
If we disable the preview port, or set MMAL_PARAMETER_BURST_CAPTURE before the first capture, then you will be able to save some of the delay between shots. HOWEVER, that then hits the issue of AGC slowly going dark - that's actually the issue I am intending on looking at today.
Raspistill also allocates memory based on max 1080P preview and 5MPix capture. The linked V4L2 demo is for achieving 5MPix@15fps and has extra parameters to rejig things within the V4L2 driver. If we can tweak Raspistill to allocate multiple 5Mpix input frames then the sensor doesn't have to stop at all between captures, and you don't have to stop at all.

I want to look at the AGC issue as my priority, so I will leave it as an exercise for the forum members to play with. In MMAL_PARAMETER_CAMERA_CONFIG_T there are a max_preview_[width|height] parameter. Those need to be increased to 2592 and 1944 to give enough memory to keep the sensor going. MMAL_PARAMETER_BURST_CAPTURE should be an easy enough one to deal with - just set it when starting a capture and you'll just have to quit the app and rerun to restart preview.

[ethanol100]

One question: Is the new long exposure mode only the 1-15fps full resolution still mode with modified clock?
Can we use this mode for the video port?
Then we could get ~10frame/s at 6s exposure(probably with mjpeg or with resizer component...). Which would be nice for frame stacking.

[6by9]

One question: Is the new long exposure mode only the 1-15fps full resolution still mode with modified clock?
Can we use this mode for the video port?

It is the full 5Mpix mode running slower via a couple of tricks. The only reason we need the other modes is due to pixel throughput limitations at various parts of the system (mainly the sensor, but also with the ISP hardware). So yes you can run it on the video port and the ISP will resize to whatever size is requested. The modified Raspistill already runs it on the preview port.

Then we could get ~10frame/s at 6s exposure(probably with mjpeg or with resizer component...). Which would be nice for frame stacking.

I think you misunderstand the way these sensors tend to work. The frame period has to be greater than exposure time, so 10frames/s would mean a max of 100ms exposure.

[ethanol100]

My mistake, I wanted to say about 10 frames/min...

Than I will try to use this mode for raspivid

[6by9]

My mistake, I wanted to say about 10 frames/min...

Than I will try to use this mode for raspivid

10 frames/min would be totally possible At any time if you set the MMAL_PARAMETER_FPS_RANGE parameter to less than 1fps with the port format fps to 0, then the sensor will use this mode.
If we can use the BURST_CAPTURE parameter with Raspistill then you may get slightly better image quality, but I probably need to suss out the AGC issue first (it may be irrelevant as we're in almost total manual mode)

[ethanol100]

The new mode works in raspivid and I get 10 frames/min, but the image quality is not really comparable. The big digital gain creates a lot of noise. The "settings switch" is a very good addition, so we can now follow the AGC algorithm

./build/bin/raspivid -w 1280 -h 960 -v -set -fps 0 -ISO 800 -awb off -awbg 1,1 -ss 6000000 -t 180000 -o 6s.h264:

Code: Select all

#frame a-gain d-gain
1 1 2.5
2 1 3.25
3 4 1
4 4 2
5 1.75 5.7109375
6 1.75 4.85546875
7 2.1875 3.52734375
8 2.1875 3.76171875
9 2.3125 3.5546875
10 2.3125 3.77734375
11 2.375 3.671875

raspistill -set -v -ISO 800 -awb off -awbg 1,1 -ss 6000000 -t 60000 -o 6sec.jpg:

Code: Select all

#frame a-gain  d-gain
1 1 2.5 <= begin preview
2 1 3.25
3 2.375 1.51171875
4 2.375 2.7421875
5 2.375 3.375
6 2.375 3.6875 <=end preview
7 8 1 <= still image

for raspistill we see a similar evolution of the gains when in preview mode, but the magic of 8x analog gain and 1x digital gain is really amazing! The picture looks really great.

Now its time to try the BURST_CAPTURE parameter with Raspistill.

[jbeale]

ethanol100, which version of raspistill do you have? Using your command line,

Code: Select all

raspistill -set -v -ISO 800 -awb off -awbg 1,1 -ss 6000000 -t 60000 -o 6sec.jpg

I do not get the gain settings for seven frames as you showed, just (I assume) the initial frame, and the last one.

[ethanol100]

It is the one from https://github.com/raspberrypi/userland, only difference are the applied changes to RaspiVid.c following the changes to RaspiStill.c from 6by9. I think the number of frames depends on the scene we are looking at. I have a more or less complete dark room with a defuse light source and the AGC seems to try to adjust the settings, if you have some more light, then the AGC is more successful and can adjust the values only in one frame. The output is for each frame where some values of gains have been changed, so it seems to be happy with the first and does not try to change in the other frames.

[jbeale]

I think the number of frames depends on the scene we are looking at. I have a more or less complete dark room with a defuse light source and the AGC seems to try to adjust the settings, if you have some more light, then the AGC is more successful and can adjust the values only in one frame. The output is for each frame where some values of gains have been changed, so it seems to be happy with the first and does not try to change in the other frames.

I see, yes that happens here as well. I put the camera in a dark enclosure and it took several iterations:

Code: Select all

$  raspistill -set -v -br 60 -ISO 800 -awb off -awbg 1,1 -ss 6000000 -t 60000 -o 6secA.jpg
[...] Connecting camera stills port to encoder input port [...]
mmal: Exposure now 5969487, analog gain 256/256, digital gain 640/256
mmal: Exposure now 5969487, analog gain 256/256, digital gain 832/256
mmal: Exposure now 5969487, analog gain 608/256, digital gain 387/256
mmal: Exposure now 5969487, analog gain 608/256, digital gain 705/256
mmal: Exposure now 5969487, analog gain 608/256, digital gain 864/256
mmal: Exposure now 5969487, analog gain 608/256, digital gain 944/256
mmal: Exposure now 5969487, analog gain 2048/256, digital gain 256/256    <--(actual exposure)

With the boosted "--brightness" parameter I can see it looks pretty clean. Some hot pixels, and a hotspot on the right edge of the sensor (readout electronics?) but still, not bad for what it is.

...and maybe this is a bit off topic but judging by the current forum signature lines from 6by9 and jamesh, it looks like 100% of the R-Pi camera support team is about to be unemployed. That seems a worrying development not only for them, but for the community as well.

[6by9]

The AGC issue probably isn't an issue for you.
I've just been investigating it as it was believed to be a longstanding issue. With QV4L2 (the v4l2-utils test app), I've been streaming JPEGs now for several hours now without the images going black. I suspect that the change I made back in March to stop AWB twitching between captures also stopped AGC recomputing and ending up rounding down and the image going black. So you should be able to use the BURST_CAPTURE parameter and not have issues of the images going dark.

(I will be looking at trying to unlock AGC between stills captures unless the app says not to, but that's another thing).

[6by9]

...and maybe this is a bit off topic but judging by the current forum signature lines from 6by9 and jamesh, it looks like 100% of the R-Pi camera support team is about to be unemployed. That seems a worrying development not only for them, but for the community as well.

On the plus side, being "at risk" does mean that I only have Pi stuff and my CV to do at the moment, so I get a chance to sort out all the feature requests and bug reports that have been kicking around for a while

Mr McGregor and the board have made the edict that the Cellular Baseband division is to be wound down, and that includes almost all of the Cambridge office where the 2835 was developed. There is supposed to be ongoing support for Pi provided by Broadcom, but I have not applied for the role and AFAIK jamesh hasn't either. Pi support has been a side project for both of us alongside other developments.

From my side, I will still offer support where I can (even though I don't actually have my own Pi Camera!), but I won't have access to the firmware source unless something special is agreed by people above my pay-grade. It will also be totally on my own time, which is relatively limited due to one small girl.

I could say other things, but won't.

[ethanol100]

Using burst capture yield good frame rates:
normal mode:

Code: Select all

raspistill -tl 1000 -v -set -ISO 100 -awb off -awbg 1,1 -t 180000 -ss 6000000 -o %03d.jpg

=> 1,26,51,76,101,126,151,176,201 -> each 25s

burst mode:

Code: Select all

raspistill -bm -tl 1000 -v -set -ISO 100 -awb off -awbg 1,1 -t 180000 -ss 6000000 -o %03d.jpg

=> 1,26,32,38,44,50,56,62,68,74,80,86,92,98,104,110,116,122,128,134,140,146,152,158,164,170,176,182 -> first 25s then 6s each

I have put my changes here(put together in a hurry, probably not the best place in the code to activate the burst mode...):
https://github.com/ethanol100/userland/tree/burstMode