New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some actions requiere very long time #180

snoygues opened this Issue Nov 10, 2014 · 6 comments


None yet
2 participants

snoygues commented Nov 10, 2014

I sue last picamera 1.8 on raspberry with last 09/09/2014 firmware from Adafruit (use of Pitft screen).
Some actions requiere very long time as :

  • Camera = picamera.PiCamera() : 1.3s
  • Camera.resolution = (256, 192) : 1s
  • Camera.framerate = 1 : 1s

whereas some others are quite short :

  • Camera.ISO = 100 : 0.02s
  • Camera.exposure_mode = 'off' : 0.02s

Is it normal ? is there a solution to reduce delay ?


This comment has been minimized.

snoygues commented Nov 11, 2014

I did additional test with two official last Rpi firmware :

  • old : Linux raspberrypi 3.12.22+ #691 PREEMPT Wed Jun 18 18:29:58 BST 2014 armv6l
  • last : Linux raspberrypi 3.12.28+ #709 PREEMPT Mon Sep 8 15:28:00 BST 2014 armv6l

I run following python code : import picamera
import time
import numpy as np
from fractions import Fraction

t0 = time.time()
Camera = picamera.PiCamera()
print("Camera = picamera.PiCamera() : ", "%0.3f" % (time.time()-t0))

t0 = time.time()
Camera.resolution = (256, 192)
print("Camera.resolution = (256, 192) : ", "%0.3f" % (time.time()-t0))

t0 = time.time()
Camera.framerate = 1
print("Camera.framerate = 1 : ", "%0.3f" % (time.time()-t0))

t0 = time.time()
Camera.ISO = 100
print("Camera.ISO = 100 : ", "%0.3f" % (time.time()-t0))

t0 = time.time()
stream = open('', 'w+b')
print("stream = open('', 'w+b') : ", "%0.3f" % (time.time()-t0))

t0 = time.time()
Camera.capture(stream, 'yuv')
print("Camera.capture(stream, 'yuv') : ", "%0.3f" % (time.time()-t0))

t0 = time.time()
print(" : ", "%0.3f" % (time.time()-t0))

t0 = time.time()
Y = np.fromfile(stream, dtype=np.uint8, count=256_192).reshape((192, 256))
print("Y = np.fromfile(stream, dtype=np.uint8, count=256_192)... : ", "%0.3f" % (time.time()-t0))

Results are :

  • old :

Camera = picamera.PiCamera() : 0.546
Camera.resolution = (256, 192) : 0.337
Camera.framerate = 1 : 0.342
Camera.ISO = 100 : 0.001
stream = open('', 'w+b') : 0.003
Camera.capture(stream, 'yuv') : 2.717 : 0.002
Y = np.fromfile(stream, dtype=np.uint8, count=256*192)... : 0.002

  • last :

Camera = picamera.PiCamera() : 1.217
Camera.resolution = (256, 192) : 1.090
Camera.framerate = 1 : 1.023
Camera.ISO = 100 : 0.001
stream = open('', 'w+b') : 0.001
Camera.capture(stream, 'yuv') : 4.351 : 0.000
Y = np.fromfile(stream, dtype=np.uint8, count=256*192)... : 0.001

Some operations are now very long (x3) are take more than 1s.


This comment has been minimized.


waveform80 commented Nov 14, 2014

Unfortunately you are correct that later firmwares take far longer to initialise than earlier ones; sometime around when stereoscopic support got added to the firmware (for the compute module), I noticed runtimes on the picamera test suite jumped from about an hour and a half to over four hours! I figured out it was down to the initialisation time increasing substantially but there's very little I can do about that.

This is also the reason resolution and framerate changes take longer as both these require reinitializing the camera.

I could add constructor arguments to allow users to specify the initial resolution and framerate (which would save people having to reconfigure then after init in the case that people wanted a relatively fast init). I'll make that an enhancement for 1.9

@waveform80 waveform80 self-assigned this Nov 14, 2014

@waveform80 waveform80 added this to the 1.9 milestone Nov 14, 2014


This comment has been minimized.


waveform80 commented Nov 14, 2014

I'm afraid as far as fixing the initialisation time is concerned, that's something you'll need to report upstream (the raspberrypi/userland project is the usual place for such things). It may be that the longer time is necessary to support stereoscopic capability, but I can't say for certain. If you do decide to report it upstream, it would probably be extremely useful to track down exactly which release resulted in the slower init time (somewhere just before 709 by the looks of it)


This comment has been minimized.

snoygues commented Nov 14, 2014

Actually, long time for "resolution or "frame_rate" function are not a problem for my projet as I do not have to change them so often.
On the opposite, "Capture" process time is very important for my project as I use this function each time I request a picture. But maybe there is another way/solution.
Here is my need :

  • take pictures, with very long exposure time (from 1s to 10s),
  • do some numerical calculation on the picture. For those calcultation, I need RAW data (not jpg).
  • take pictures with the shorter lost time between each ones,
  • stop loop via user interface in order to change parameters,

I currently used a timer and the "Capture" fonction. Is there a more effiicent way to do that ?

@snoygues snoygues closed this Nov 14, 2014


This comment has been minimized.

snoygues commented Nov 16, 2014

It seems that using "Rapid capture and streaming" as describe in your online help (chapter 5.4) could be a solution for me.
I'm a bit afraid with ausing "server" & "client", as I'm not use to, but first tests shows that it's should be ok.
I just have one problem right now:
it works as lons as I use "camera.capture_continuous(stream, 'jpeg', use_video_port=True):
but, if I replace "jpeg" by "yuv", that does not work anymore.
Solution is problably quite simple, but I have no idea. Could you help me?


This comment has been minimized.


waveform80 commented Nov 16, 2014

How does it fail when you change 'jpeg' to 'yuv'? You will need to change the server end to deal with the fact that the format's changed (as yuv is unencoded things like PIL won't automatically be able to interpret the data any more; you'll need to tell them exactly what size/format the image data is in).

waveform80 added a commit that referenced this issue Nov 28, 2014

Fix #180
Add `__init__` parameters for initial resolution and framerate.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment