timelapse.py shoots black, dark images. Capture() broken?
Closed this issue · 22 comments
Hi @sdenton4,
I am trying to set up your script, yet I can't get it to work. Starting timelapse.py -n 3 -i 60 results in all black, very small images (20kb).
Funny enough, I made some changes that result in at least the first image taken being fine. From then on though they are all black again.
Finding initial SS….
WB: (Fraction(117, 64), Fraction(393, 256))
Exp: 7703 FR: 10.000000 Capture Time: 0.880000
ss, x, br: 15176 0.02 77.67
Exp: 15170 FR: 15.000000 Capture Time: 0.710000
ss, x, br: 15547 0.02 126.74
Set up timelapser with:
maxtime : -1
maxshots: 3
interval: 60
Brightns: 128
Size : 1286 x 972
Exp: 15530 FR: 15.000000 Capture Time: 0.620000
SS: 15486 X: 0.02 BR: 130.49 Shots: 1 T: 1.6
Exp: 15530 FR: 15.000000 Capture Time: 0.490000
SS: 18563 X: 0.02 BR: 0.0 Shots: 2 T: 1.2
Exp: 15473 FR: 15.000000 Capture Time: 0.540000
SS: 22255 X: 0.02 BR: 0.0 Shots: 3 T: 1.3
I am fairly new to programming so I can't really tell what causes this…
Hello!
I was just using the script again myself recently, and everything seemed
OK. Not sure why you're getting black images. Fwiw, an all black image
will always be extremely small as there's very little data to compress.
What model pi are you using?
Also, what changes did you make specifically? Not quite sure how to get a
diff without a bit if effort on my part...
On Aug 23, 2016 09:02, "messismore" notifications@github.com wrote:
Hi @sdenton4 https://github.com/sdenton4,
I am trying to set up your script, yet I can't get it to work. Starting timelapse.py
-n 3 -i 60 results in all black, very small images (20kb).Funny enough, I made some changes
https://github.com/messismore/pipic/blob/master/timelapse.py that
result in at least the first image taken being fine. From then on though
they are all black again.Finding initial SS….
WB: (Fraction(117, 64), Fraction(393, 256))
Exp: 7703 FR: 10.000000 Capture Time: 0.880000
ss, x, br: 15176 0.02 77.67
Exp: 15170 FR: 15.000000 Capture Time: 0.710000
ss, x, br: 15547 0.02 126.74
Set up timelapser with:
maxtime : -1
maxshots: 3
interval: 60
Brightns: 128
Size : 1286 x 972
Exp: 15530 FR: 15.000000 Capture Time: 0.620000
SS: 15486 X: 0.02 BR: 130.49 Shots: 1 T: 1.6
Exp: 15530 FR: 15.000000 Capture Time: 0.490000
SS: 18563 X: 0.02 BR: 0.0 Shots: 2 T: 1.2
Exp: 15473 FR: 15.000000 Capture Time: 0.540000
SS: 22255 X: 0.02 BR: 0.0 Shots: 3 T: 1.3I am fairly new to programming so I can't really tell what causes this…
[image: photopi_160823_12 33 23]
https://cloud.githubusercontent.com/assets/5689189/17899440/a3399806-695b-11e6-938c-79bae833a175.jpg—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#15, or mute the thread
https://github.com/notifications/unsubscribe-auth/AD09vaM6hD4CrFriZJUCaJ95ByUJsWadks5qixmCgaJpZM4JrGQU
.
Hi!
Thanks for your reply. I am using a Zero, will try to figure out how to make a diff…
Edit: It seems like commenting out self.dynamic_adjust() in shoot() prevents the pictures from turning out dark.
Edit 2: More specifically, it appears that these lines are the culprits, in def dynamic_adjust()
FR=Fraction(9*1000000,10*self.currentss)
if FR>15: FR=15
if FR<0.1: FR=Fraction(1,10)
self.camera.framerate=FR
Interesting; I haven't tried anything with the zero, and not sure if there
are any substantive differences in how the camera module works with it.
Maybe worth looking in the PiCamera library's discussion pages to see if
there's anything relevant to the Zero that should be known.
Looks like enabling the 'blame' layer highlights the changes. The two main
differences are putting in a maximum framerate of 15 in the dynamic adjust
routine )and changing some file locations). Not sure why this would have
an effect (even a limited one).
Best,
-tom denton
http://inventingsituations.net
On Tue, Aug 23, 2016 at 10:07 AM, messismore notifications@github.com
wrote:
Hi!
I am using a Zero, will try figure out how to make a diff…
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#15 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AD09vc4j6yK6DwOYN6_0iwOiUYz7Nqq9ks5qiyjqgaJpZM4JrGQU
.
Hi,
I don't know if the discussion is still open.
I found something similar. Are you using the new 8Mb camera?
Using this camera I get 1 good shoot after 10-20 black ones and so on.
Using the previous 5Mb camera everything was ok.
Alessandro
I'm actually getting the same thing as described by excalibur470. I'm also using the 8mp camera. I get two or three good pictures then it goes all black. This is the py output: http://prntscr.com/dh4q35
Like I said the first two images were good and then just black images.
Edit: It does have something to do with the piece of code mentioned by messismore. I'll updated post if I figure anything out.
Following the messismore suggestion I found that two camera models have different framerates for the same resolution, please refer to the following link https://picamera.readthedocs.io/en/release-1.12/fov.html for settings.
So it is necessary modify the dynamic_adjust() function applying the right framerare range
Makes sense. I don't fully understand what I need to edit though under the dynamic_adjust() (still learning) function. On the V2 cam using the resolution 1640x922 what would I edit the dynamic_adjust() function to? Can you also provide 1280x720 example to as the framerate starts at 40?
edit: I tried changes these to lines to upper and lower framerate but the second image goes dark on the second shot. I just think I'm not following the calculation properly if more needs to be edited.
if FR>90: FR=90
if FR<0.1: FR=Fraction(1,10)
Thanks
Frame rate must be in the interval between the two values.
So I suggest you to print the computed FR, for determinino the value then, if it is outside the range you have to correct it.
...
print 'New FR:\t', FR, ' SS:\t', self.currentss
if FR>90: FR=90
if FR<40: FR=40
self.camera.framerate=FR
...
This is a quick and dirty solution because the I did't really undestand the statement:
...
FR=Fraction(9*1000000,10*self.currentss)
...
or better, I would be grateful to sdenton4 if he could explain us the logic used for calcolating shutter speed an frame rate in dynamic_adjust() function.
@messismore I just saw your fork of this but I wanted to use my sdcard for storage. I edited timelapse.py but it's not creating the HDR image. bc it's fails to open.
I'm I missing another reference somewhere?
Hello! I made some local changes to the script about a year ago; I'll double check against what's checked in here. Might be a couple days before I find some time, though. It's possible that some of the underlying picamera api's have changed since I wrote this a few years ago. I remember that getting the Fraction's right for the api was a bit of a pain, though.
If you use iPython notebooks, it should be possible to get a notebook running and play with the picamera directly to try to figure out what sort of constraints it has, and what a reasonable call looks like...
@sdenton4 Yeah, I came across your video on (I believe) your blog and really liked the smoothness. I'll checkout iPython but if you didn't mind helping with some guidance with the new 8mp camera that would be awesome.
-Wes
I'm going to try to document what I'm seeing so it might be a bit easier to give a little guidance. I played with a lot of setting but I'm not really sure. The only change I've made to your code was change res to 1280x720.
This is the output I get for the first 5 shots
After the 2nd shot brightness (and picture) go to zero/black
Obviously night shots, but same thing during the day too.
Ok, took a bit of a look.
Shutter speed is measured in microseconds (millionths of a second). So this line:
FR=Fraction(9*1000000,10*self.currentss)
we can read as : FR = (9/10) * (1/SS)
So we set the framerate of the camera to be a little bit faster than the duration of a shot. This may need to be changed to
FR=Fraction(1000000, self.currentss)
based on my reading of
http://picamera.readthedocs.io/en/release-1.12/recipes1.html#capturing-in-low-light
Additionally, the bounds on the framerates should probably be broken out as variables, instead of just sitting as raw numbers in the code... The V2 camera has different constraints. See:
http://picamera.readthedocs.io/en/release-1.12/fov.html
Think I need to get sign-off from work before I can make further submissions to this repository; I'm happy to look at pull requests, in the meantime. (I'm also unlikely to buy a V2 camera anytime soon, as I have like six V1 cameras kicking around...)
nolesnyc: The FR in the readout is the framerate; for some reason it's dropped to zero in your black photos, which would explain why they're black.... I'm guessing that a boundary for the v2 camera is being violated.
@sdenton4, thank you for the explanation. I have one more question.
Looking at your code I noticed that the brightness parameter accepts values between 0-256 (default 128) but reading at the picamera documentation acceptable values are 0-100 (default 50).
Is there a reason for this setting?
With V1 camera using brightness=128 produces good shots, with V2 the results are too light.
-Alessandro
The brightness is observed, and is never handed to the camera. The pixel values of a greyscale picture are between 0 and 256; the camera averages over the metersite and then adjusts shutterspeed if the brightness is too far from the targetBrightness. I'm not sure why the V2 pictures would be too bright.
Ok, figured out how to do commits with the blessings of my employer, and pushed a couple changes to how config and state are handled. This should at least make it a bit easier to specify more sensible defaults for the V2 camera, especially the max_fr. (And easier for me to write some tests...)
I also changed the framerate calculation to FR=Fraction(1000000, self.currentss), with no obvious ill effects.
Thanks @sdenton4 ! I'll check it out
Quick questions. How can output the filename as img_0001.jpg, img_0002.jpg...
Edit 2: It seems to be taking good pictures now (low light) I'm going to run it tomorrow during daylight.
Hey, sorry I missed your reply somehow.
The filename is set in this line:
filename = ('/home/pi/pictures/%s_%s.jpg' % (self.hostname, dtime))
You can change it to this to get the kind of filename you want:
filename = ('/home/pi/pictures/image_%05d.jpg' % (self.state.shots_taken))
How are things working out otherwise? You should be able to add max_fr and min_fr options in the config at line 432 (at "# Add more configuration options here, if desired.") to give options appropriate for your camera.
I actually did figure that part out, I should have updated my reply. It's running a little bright on bright days. I've been playing around with metering mode as the target brightness does seem to be correcting it enough.
It's rainy here today but I'll post some comparison pictures soon. I'm actually planning on using this indoors for my project though so it's not actually that big of a deal to me but would like to find the solution for my own benefit.
Playing around a bit this morning, looks like it's best to stick to metersite='a', unless you're quite sure you only care about the center of the picture. There's also a lower bound of 0.01 enforced on the float for shutter speed, which should be removed. In outdoor shots, this sets a minimum shutter speed which is actually too high, which can lead to too-bright images... I'll throw together a patch when I have a chance.
Just wanted to leave a thanks, this is working exactly how I was hoping it would now. Thanks
Cool, thanks for checking back! I'll mark this one fixed.