long exposure not working on B+

[gordon77]

Thanks

[pjwalsh77b]

Will the enhancements that allow exposure times > 1s be made available through the general software release process, or do I need to do something special to get them?

In other words, if I just do "sudo apt-get update; sudo apt-get upgrade" will I get the new code?

Those changes already have been released, so just do a "sudo rpi-update"

Did the update, got the long-exposure-enabled code, thanks much.

[Wolfskin75]

I still have the b and I am new here. I am hoping to work toward a solution to be able to do star trails without having to stack the photo's. I have been reading this string and I don't understand most of it. What is the problem with it not doing the star trail.

[jamesh]

For star trails you need very long exposures. The Pi camera can only do up to 6s exposures which are not long enough.

[gordon77]

For star trails you need very long exposures. The Pi camera can only do up to 6s exposures which are not long enough.

What about this ? http://www.raspberrypi.org/forums/viewt ... 6&start=63

[6by9]

What about this ? http://www.raspberrypi.org/forums/viewt ... 6&start=63

taking 300 images and staging them together

It is stacking the raw images as they are produced, and then creating a JPEG of that.

There is currently no way on the Pi to produce more than a 6second exposure for a single image. As posted elsewhere, we may get it up to 20s, but that will be the absolute maximum. To get any more you will have to stack them - there is no option.

[gordon77]

What about this ? http://www.raspberrypi.org/forums/viewt ... 6&start=63

taking 300 images and staging them together

It is stacking the raw images as they are produced, and then creating a JPEG of that.

There is currently no way on the Pi to produce more than a 6second exposure for a single image. As posted elsewhere, we may get it up to 20s, but that will be the absolute maximum. To get any more you will have to stack them - there is no option.

still star trails however produced

[jamesh]

What about this ? http://www.raspberrypi.org/forums/viewt ... 6&start=63

taking 300 images and staging them together

It is stacking the raw images as they are produced, and then creating a JPEG of that.

There is currently no way on the Pi to produce more than a 6second exposure for a single image. As posted elsewhere, we may get it up to 20s, but that will be the absolute maximum. To get any more you will have to stack them - there is no option.

still star trails however produced

The poster specifically asked to do it without stacking.

Not withstanding the technical issues of making it work, 20s exposures on sensors like this are going to be quite noisy, perhaps too noisy to be usable.

[gordon77]

OK, my mistake

[gonzothegreat]

Just getting back to this thread, thank you so much for the long exposure, really really appreciated.
Will be testing it over the next few nights

[raspindi]

Great work! I am now testing the long exposures, with a java api around it to connect the camera to a indi system.

i am using the "burst" mode to reduce the time to take many pictures in a row. My problem is the raw image, becomes noise after the first few images. The command i use to stream the images to my java program:

raspistill --awbgains 1,1 --nopreview --ISO 800 --timelapse 1000 --width 128 --height 128 --shutter 100000 --timeout 180000 --burst --raw --output - --awb off

(no long exposure in this command, just to check if thats the reason. The raw data seems "valid" because i can parse it, and the stream keeps synchron. just the data inside becomes noise.

Does anyone have a workaround? or a fix?

[raspindi]

somebody? ok i reproduced the problem on the command line:
when i do:

Code: Select all

raspistill  --awbgains 1,1 --nopreview --ISO 800 --timelapse 1000 --width 128 --height 128 --shutter 100000 --timeout 180000 --burst  --awb off   -o %03d_testnew.jpg

everything works as expected.

When i now include the raw option:

Code: Select all

raspistill  --awbgains 1,1 --nopreview --ISO 800 --timelapse 1000 --width 128 --height 128 --shutter 100000 --timeout 180000 --burst --raw  --awb off   -o %03d_testnew.jpg

Then the first image is ok but all folowing images are just black (the jpeg) and the raw is just noise.

Any ideas? the burst mode in combination with the raw mode would be great to use....

[6by9]

somebody? ok i reproduced the problem on the command line:
when i do:

Code: Select all

raspistill  --awbgains 1,1 --nopreview --ISO 800 --timelapse 1000 --width 128 --height 128 --shutter 100000 --timeout 180000 --burst  --awb off   -o %03d_testnew.jpg

everything works as expected.

When i now include the raw option:

Code: Select all

raspistill  --awbgains 1,1 --nopreview --ISO 800 --timelapse 1000 --width 128 --height 128 --shutter 100000 --timeout 180000 --burst --raw  --awb off   -o %03d_testnew.jpg

Then the first image is ok but all folowing images are just black (the jpeg) and the raw is just noise.

Any ideas? the burst mode in combination with the raw mode would be great to use....

Should have been fixed the other day with commit https://github.com/Hexxeh/rpi-firmware/ ... 9c9a05c2ed
However that will have dropped the burst speed as it requires the sensor to drop a frame every time it restarts (read every capture). A workaround for that is now possible (it'll be in a new post).

[Wolfskin75]

I guess its a question of camera having a better sensors?

[jamesh]

I guess its a question of camera having a better sensors?

What do you mean?

[raspindi]

great! big thanks for the fast bug fix just did a

Code: Select all

sudo rpi-update

and now the streaming of raw images works as expected.
big thanks, again!

as soon as i finish the raspberry-camera indi interface i will report it in this form.

[Wolfskin75]

I guess its a question of camera having a better sensors?

What do you mean?

If we get noise when making long exposures and the camera sensor it relatively high in mega pixels then shouldn't it then be a question of finding a senor than produces less noise in the exposure. Someone like Sony or Nikon make a better camera sensor for the Pi cam.

[raspindi]

that was not the problem here, the quality is much bether then expected. The noise was due to a bug in the burst mode.

[jamesh]

I guess its a question of camera having a better sensors?

What do you mean?

If we get noise when making long exposures and the camera sensor it relatively high in mega pixels then shouldn't it then be a question of finding a senor than produces less noise in the exposure. Someone like Sony or Nikon make a better camera sensor for the Pi cam.

The amount of time required to get a new sensor up and running with decent picture quality is huge. Any camera priced at the level that would actually sell will be of similar performance to the current OV5647. Sony sensors are OK, but more expensive. Never seen a camera module by Nikon.

[Burngate]

.. a question of finding a senor than produces less noise in the exposure. Someone like Sony or Nikon make a better camera sensor for the Pi cam.

Since Nikon, Sony, and Omnivision are all limited by the same physics, economics, and NDAs, "better" can only mean a trade-off between them

[fehlfarbe]

Hi,

is the burst mode already merged with the official raspistill?

Today I tried this after a fresh rpi-update:

Code: Select all

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

I'm getting the files

Code: Select all

001.jpg  027.jpg  040.jpg  052.jpg  065.jpg  077.jpg  090.jpg  103.jpg  115.jpg  128.jpg  140.jpg

Which means every image (except the first one) takes ~12s (6s exposure + 6s waiting). I expected 6s for image and 0s waiting in burst mode lik ein post http://www.raspberrypi.org/forums/viewt ... 32#p588432

[6by9]

Hi,

is the burst mode already merged with the official raspistill?

Today I tried this after a fresh rpi-update:

Code: Select all

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

I'm getting the files

Code: Select all

001.jpg  027.jpg  040.jpg  052.jpg  065.jpg  077.jpg  090.jpg  103.jpg  115.jpg  128.jpg  140.jpg

Which means every image (except the first one) takes ~12s (6s exposure + 6s waiting). I expected 6s for image and 0s waiting in burst mode lik ein post http://www.raspberrypi.org/forums/viewt ... 32#p588432

Side effect of http://www.raspberrypi.org/forums/viewt ... 75#p600725
With burst mode we weren't dropping the corrupt frame the sensor produces on restart, and that meant that about half the frames came through incorrect, and also the raw images are dodgy (http://www.raspberrypi.org/forums/viewt ... 49#p605221). Now we do, it halves the capture rate but makes all the frames valid.

Normally raspistill only allocates enough memory for one 5MPix input image (multiple lower res ones for viewfinder), so it has to stop after each frame. If we set up the buffering to allow the sensor to continue streaming, then you should get frames at 6 sec intervals.
-fp will probably do that for you, although it messes up the display so probably better to add --nopreview too. If the new option to force the sensor mode into raspitill (http://www.raspberrypi.org/forums/viewt ... 43&t=85714) gets merged into raspistill at some point, then forcing it to the slow 5MPix mode will also rejig the buffer calcs and should allow it to run with any viewfinder res.

[fehlfarbe]

Hi 6by9,

thank you very much for you answer and all the work
So I have to wait until the 'sensor mode' option gets merged? Because I tried with '-fp' option but nothing changed

[ethanol100]

You can try to capture full resolution images. Without setting h and w, I get one frame every 6 sec with the "-fp" switch together with the burst mode switch. I would guess that with reduced resolution the allocated buffer are all scaled down and then there is again not enough input buffer space to store the required frames.

[fehlfarbe]

Hm doesn't work for me

I tried:

Code: Select all

pi@meteorberry ~ $ raspistill -fp --nopreview -bm -v -set -ISO 100 -awb off -awbg 1.1,1 -t 0 -ss 6000000 -o t_%03d.jpg

raspistill Camera App v1.3.8

Width 2592, Height 1944, quality 85, filename t_%03d.jpg
Time delay 0, Raw no
Thumbnail enabled Yes, width 64, height 48, quality 35
Link to latest frame enabled  no
Full resolution preview Yes
Capture method : Run forever

Preview No, Full screen Yes
Preview window 0,0,1024,768
Opacity 255
Sharpness 0, Contrast 0, Brightness 50
Saturation 0, ISO 100, Video Stabilisation No, Exposure compensation 0
Exposure Mode 'auto', AWB Mode 'off', Image Effect 'none'
Metering Mode 'average', Colour Effect Enabled No with U = 128, V = 128
Rotation 0, hflip No, vflip No
ROI x 0.000000, y 0.000000, w 1.000000 h 1.000000
Camera component done
Encoder component done
Starting component connection stage
Connecting camera preview port to video render.
Connecting camera stills port to encoder input port
Opening output file t_001.jpg
Enabling encoder output port
Starting capture 1
mmal: Exposure now 5969487, analog gain 256/256, digital gain 256/256
mmal: AWB R=281/256, B=256/256
mmal: Exposure now 5969487, analog gain 256/256, digital gain 256/256
mmal: AWB R=281/256, B=256/256
Finished capture 1
Opening output file t_002.jpg
Enabling encoder output port
Starting capture 2
Finished capture 2
Opening output file t_003.jpg
Enabling encoder output port
Starting capture 3
Finished capture 3
...

and I get these images

Code: Select all

-rw-r--r-- 1 pi pi 80585 2014-09-11 13:58:43.850083454 +0200 t_001.jpg
-rw-r--r-- 1 pi pi 80585 2014-09-11 13:58:56.170970217 +0200 t_002.jpg
-rw-r--r-- 1 pi pi 80585 2014-09-11 13:59:08.721873768 +0200 t_003.jpg
-rw-r--r-- 1 pi pi 80585 2014-09-11 13:59:21.262776824 +0200 t_004.jpg
...