Pure Python camera interface

[waveform80]

Try "rgba" instead. There is an MMAL setting for "argb" but for some reason it doesn't work with the resizer output which I use for raw captures (just as the "rgb" and "bgr" don't (directly) work - but I figured those were important enough to write an emulation for, which is why they're so slow as the processing's been done on the CPU).

Thanks Dave, I'll try that.

Quick question, seeing mention of firmware updates... will the later versions of the picamera library work with older firmwares as well as newer ones, or is it important to keep firmware on the cameras up-to-date? How is the camera firmware updated - through apt-get update (if so, what is the name of the module)?

picamera *should* work fine with older firmwares but I don't explicitly test them (the test suite already takes a good 30+ minutes to run!)

Generally speaking, firmware updates are only important if you care about new functionality or bug fixes introduced by them. To give a brief run down of stuff that firmware updates have fixed in the past: lockups with long exposure times, correct setting of exposure compensation, fixed white balance, full FoV in most resolutions (except 1080p), frame rates above 30fps, and so on. Unfortunately I don't think there's a simple list of which revision fixes what so a bit of guess-work may be involved.

Firmware updates are applied (and can be rolled back) with "sudo rpi-update" rather than "sudo apt-get".


Dave.

[kelevraxx]

Dave on picroscopy i need to use some specific microscope?
i try to use an old and regular one, but I'm having trouble focusing on the slide.
I can barely see the picture, I took the eyepiece to put the camera directly on the revolver is just right?
sorry for my english!!!

That's pretty much how I've done it at the moment, but the results are definitely sub-optimal. The mount of the camera is certainly the most tricky part. It's something I need to spend some time on perfecting for the microscopes at the university, but there doesn't seem to be a standard for mounts on microscopes (or perhaps there are several) so whatever I eventually come up with probably won't be that useful for other people.

You may find that you need to adjust/remove the lens of the Pi's camera, but this is a fiddly process which can break the camera so unless you're confident (or happy to break stuff) I wouldn't necessarily advise it.

I should also mention I haven't had any time to work on the mount for the past couple of months, and probably won't for the next couple while I try and find the time to brush up on my OpenGL/ES knowledge (which is needed for the planned overlay). I really should find some time to package it properly too ... so many things, so little time!

Anyway, good luck with your experiments!


Dave.

Thx dave, well i will try on and post my results when i done

[JTeagle]

picamera *should* work fine with older firmwares but I don't explicitly test them (the test suite already takes a good 30+ minutes to run!)

Generally speaking, firmware updates are only important if you care about new functionality or bug fixes introduced by them.

Firmware updates are applied (and can be rolled back) with "sudo rpi-update" rather than "sudo apt-get".

Thanks very much for the info, Dave.

Regards,
Jason

[bootsmann]

@waveform80

Have you changed something in the code, because "picamera.led = False" is no longer running since update to v1.3?

Are you attempting to set the led property on the module itself? If so, you need to set it on the camera instance, e.g.:

Code: Select all

import picamera

with picamera.PiCamera() as camera:
    camera.led = False
    camera.led = True

It's working fine for me at the moment (testing against a straight 1.3 installation and my development copy).


Dave.

Hi

My code:

Code: Select all

GPIO.setmode(GPIO.BCM)
#GPIO.setwarnings(False)
GPIO_PIR = 4
GPIO.setup(GPIO_PIR,GPIO.IN)

def take_picture():
    with picamera.PiCamera() as camera:
        camera.led = False
        camera.exposure_mode = 'night'
        camera.resolution = (1024, 768)
        camera.start_preview()
        # Camera warm-up time
        time.sleep(2)
        filename = os.path.join(path_to_picture, '%s.jpg' % time.strftime("%Y-%m-%d-%H:%M:%S"))
        camera.capture(filename)
        return filename

But once a picture is taken the LED lights up for a few seconds. What could be the reason?

[XAPBob]

Generally speaking, firmware updates are only important if you care about new functionality or bug fixes introduced by them. To give a brief run down of stuff that firmware updates have fixed in the past: lockups with long exposure times, correct setting of exposure compensation, fixed white balance, full FoV in most resolutions (except 1080p), frame rates above 30fps, and so on. Unfortunately I don't think there's a simple list of which revision fixes what so a bit of guess-work may be involved.

Firmware updates are applied (and can be rolled back) with "sudo rpi-update" rather than "sudo apt-get".

From here it says that the current firmware version is available from:

Code: Select all

/opt/vc/bin/vcgencmd version

Indeed the example on that page shows a nice short integer...

However when I run that command (sudo or otherwise) then I get:

Code: Select all

$ /opt/vc/bin/vcgencmd version
Apr 11 2014 19:33:27
Copyright (c) 2012 Broadcom
version ed3181364acfe9aaec83112f3d1b792c3f591e5a (clean) (release)

which looks alot like an md5sum, rather than a version number. I presume the date/time is when the firmware was compiled (or labelled in source control).

Given the lack of release notes do we just run on guessing that the "latest" is always the "greatest" until we hit a problem?

[jbeale]

I'd like to record a consecutive set of 1-minute-long video clips, with minimal delay in between the clips. The code below works, but there is about 1.5 seconds delay in between each 58.5 second long recording while the camera gets re-initialized. Is there a better way to do this?

Code: Select all

#!/usr/bin/python
from __future__ import print_function
from datetime import datetime, time
import picamera

utcnow = datetime.utcnow()
midnight_utc = datetime.combine(utcnow.date(), time(0))

while (1) :
  with picamera.PiCamera() as camera:
    camera.resolution = (1024, 768)
    camera.framerate = 10
    camera.exposure_mode = 'auto'

    delta = datetime.utcnow() - midnight_utc
    ts = delta.total_seconds()  # seconds since midnight (Python 2.7)
    waitTime = 60.0 - (ts % 60)
    dstr = "v" + datetime.now().strftime("%y%m%d_%H%M%S") + ".h264"
    print("duration: %s file: %s " % (waitTime, dstr))
    camera.start_recording(dstr, format='h264', bitrate=0, quantization=25) # use VBR mode
    camera.wait_recording(waitTime)
    camera.stop_recording()

Example text output from above program:

Code: Select all

duration: 58.472818 file: v140430_092901.h264
duration: 58.523719 file: v140430_093001.h264
duration: 58.474361 file: v140430_093101.h264
duration: 58.524729 file: v140430_093201.h264

[XAPBob]

Does capture continuous work on video?

If not you could record to a buffer then dump the buffer at minutely intervals?

[jbeale]

Oops, I should have noticed that there is already an example in the (excellent) PiCamera documentation for just this purpose:
http://picamera.readthedocs.org/en/rele ... iple-files

For example, this records a set of 10 files each 5 seconds long:

Code: Select all

import picamera

with picamera.PiCamera() as camera:
    camera.resolution = (640, 480)
    for filename in camera.record_sequence(
            '%d.h264' % i for i in range(1, 11)):
        camera.wait_recording(5)

UPDATE: this idea works if you use 25 fps, fixed bitrate recording. However it seems to produce an error if you attempt 5 fps in VBR mode
as in camera.record_sequence(fname_gen(), format='h264', bitrate=0, quantization=25)

Code: Select all

  File "./t2.py", line 26, in <module>
    format='h264', bitrate=0, quantization=25 ):
  File "/usr/lib/python2.7/dist-packages/picamera/camera.py", line 929, in record_sequence
    encoder.split(output)
  File "/usr/lib/python2.7/dist-packages/picamera/encoders.py", line 564, in split
    raise PiCameraRuntimeError('Timed out waiting for an SPS header')
picamera.exc.PiCameraRuntimeError: Timed out waiting for an SPS header

[jbeale]

Ok, my code records 5 files and then quits, when asking for video at 5 fps with a fixed bitrate. This looks to me like the split-file bug is back. Here's the code:

Code: Select all

#!/usr/bin/python
from __future__ import print_function
from datetime import datetime, time
from time import sleep
import picamera

def date_gen():
  while True:
    dstr = "v" + datetime.now().strftime("%y%m%d_%H%M%S") + ".h264"
    yield dstr

with picamera.PiCamera() as camera:
    camera.resolution = (1024, 768)
    camera.framerate = 5
    camera.exposure_mode = 'auto'
    for filename in camera.record_sequence(
            (date_gen()),
            format='h264', bitrate=1000000 ):
        utcnow = datetime.utcnow()
        midnight_utc = datetime.combine(utcnow.date(), time(0))
        delta = datetime.utcnow() - midnight_utc
        ts = delta.total_seconds()  # seconds since midnight (Python 2.7)
        waitTime = 60.0 - (ts % 60)
        print("Recording for %d to %s" % (waitTime,filename))
        camera.wait_recording(waitTime)

Here is the output:

Code: Select all

Recording for 32 to v140430_103627.h264
Recording for 56 to v140430_103700.h264
Recording for 57 to v140430_103800.h264
Recording for 58 to v140430_103900.h264
Recording for 59 to v140430_104000.h264
Traceback (most recent call last):
  File "./t2.py", line 26, in <module>
    format='h264', bitrate=1000000 ):
  File "/usr/lib/python2.7/dist-packages/picamera/camera.py", line 929, in record_sequence
    encoder.split(output)
  File "/usr/lib/python2.7/dist-packages/picamera/encoders.py", line 564, in split
    raise PiCameraRuntimeError('Timed out waiting for an SPS header')
picamera.exc.PiCameraRuntimeError: Timed out waiting for an SPS header

As a workaround, it looks like fixed bitrate with fps=15 or higher will avoid the bug. VBR mode, or low fps will trigger it.

[XAPBob]

VBR you don't necessarily get the full frame data often enoigh..

[ethanol100]

Intra refresh period? In raspivid by default each 30th image is an I-frame, so for 5fps each 6 second one I-frame occours. You can have a 5 s segment without keyframe. you could decrease the intra refresh period? But have not used picam yet, just guessing.(intra_period=5 as option after format="h264"?)

[Talha]

What is the framerate when using Opencv with the camera interface. I currently have uv4l and I only get abour 5 fps at 320x240

[waveform80]

...
From here it says that the current firmware version is available from:

Code: Select all

/opt/vc/bin/vcgencmd version

Indeed the example on that page shows a nice short integer...

However when I run that command (sudo or otherwise) then I get:

Code: Select all

$ /opt/vc/bin/vcgencmd version
Apr 11 2014 19:33:27
Copyright (c) 2012 Broadcom
version ed3181364acfe9aaec83112f3d1b792c3f591e5a (clean) (release)

which looks alot like an md5sum, rather than a version number. I presume the date/time is when the firmware was compiled (or labelled in source control).

Given the lack of release notes do we just run on guessing that the "latest" is always the "greatest" until we hit a problem?

That's about the size of it (or at least, that's how I've always treated firmware releases). In defense of the system, I've only encountered one case where a firmware update *might* have broken something (and even that's an undecided case). I should also mention that before each picamera release I run the picamera test suite (which is fairly extensive) against the latest firmware on my model B, and naturally if things fail I don't release until it's fixed (or worked around). I'd like to test against multiple firmware versions, but that's quite difficult to automate - not to mention each full run of the test suite takes about 1.5 hours to complete and I've no particular desire to extend that ;)


Dave.

[waveform80]

Ok, my code records 5 files and then quits, when asking for video at 5 fps with a fixed bitrate. This looks to me like the split-file bug is back.
...

This one was my fault for (lazily) picking an arbitrary timeout for split_recording. Should be fixed in the latest version, speaking of which ...

[waveform80]

Here we are again! Picamera 1.4 is now out (on PyPI at least - give it a few days for it to hit the Raspbian repos). The major news in the new version is manual AWB gains (via the new awb_gains parameter), but there's plenty of bug fixes to go round as well - mostly to do with raw (YUV/RGB/etc.) captures. The changelog in the documentation has all the gory details for those interested.

Other than that, my thanks to everyone for the excellent bug reports! As always comments, suggestions, and bug reports are welcome.


Dave.

[jbeale]

Great news! However the changelog at your link seems to stop at version 1.3 from March 2014.
Should there be something at http://picamera.readthedocs.org/en/release-1.4 ? (now it's just a "there's nothing here" error page).

[waveform80]

Great news! However the changelog at your link seems to stop at version 1.3 from March 2014.
Should there be something at http://picamera.readthedocs.org/en/release-1.4 ? (now it's just a "there's nothing here" error page).

Yeah - I'm waiting for ReadTheDocs to notice that GitHub's got a new tag for 1.4 in it (for some reason RTD is really quick to notice new commits, but it takes *ages* for it to notice new tags - if it doesn't see it in the next few minutes I'll have to head to bed and check it in the morning, it being 2AM here and all!)


Dave.

[jbeale]

Dave / waveform80: Thanks again for your efforts! I now see the 1.4 docs are up, and I have upgraded my pycamera install and can confirm that the record_sequence() works OK for 2 fps recording which I think is the slowest rate that the firmware supports.

I have another question. Although we now have access to the on-chip 2x2 binning mode by selecting a suitable resolution, I find that the image quality suffers (due to the 2x2 bayer-filter pattern, where only like colors are combined on-chip, it is effectively a 4x4 bin for purposes of true resolved detail, so you end up with half of the real detail you might expect from the pixel count). This leads me to consider alternatives...

Is it possible to take a sequence of full-frame stills (2592 x 1944), downsize them 50% (1296 x 972), and feed that back into the H.264 encoder to get a video with low framerate but better resolution than what the directly-processed binned 1296x972 H.264 output gives us now? And if so, how could I set that up? I know full video rates are not possible, but something like 2 to 4 fps is adequate for my purposes.

EDIT: a quick test using camera.capture_continuous('{timestamp}.jpg', use_video_port=False, resize=(1296,972)) only gives me about 1.3 fps even going to the ramdisk, so I guess that's about the limit. If I do use_video_port=True I get about 4 fps but of course with the reduced image quality of the video port, and also the reduced field of view.

[jbeale]

Well, maybe something could be possible- the below code gives me 20 JPEGs showing the full sensor frame, captured at 14.47 fps. I guess this is a copy of the live preview; the jpeg resolution is the same as my monitor resolution of 1280x1024.

Code: Select all

#!/usr/bin/python
from __future__ import print_function
import time, picamera

frames = 20;
with picamera.PiCamera() as camera:
    camera.start_preview()
    time.sleep(2)
    start = time.time()
    camera.capture_sequence(('image%03d.jpg' % i for i in range(frames)), use_video_port=True)
    print('Captured %d images at %.2ffps' % (frames, (frames / (time.time() - start))))
    camera.stop_preview()

[waveform80]

Well, maybe something could be possible- the below code gives me 20 JPEGs showing the full sensor frame, captured at 14.47 fps. I guess this is a copy of the live preview; the jpeg resolution is the same as my monitor resolution of 1280x1024.

Code: Select all

#!/usr/bin/python
from __future__ import print_function
import time, picamera

frames = 20;
with picamera.PiCamera() as camera:
    camera.start_preview()
    time.sleep(2)
    start = time.time()
    camera.capture_sequence(('image%03d.jpg' % i for i in range(frames)), use_video_port=True)
    print('Captured %d images at %.2ffps' % (frames, (frames / (time.time() - start))))
    camera.stop_preview()

Yup - PiCamera defaults to configuring the resolution of the camera as the resolution of the current display (just trying to keep things reasonably simple for the use-case of playing at the command line).

On your question earlier of resizing the output before passing it to the H.264 encoder, that's more or less what the "resize" parameter will do for start_recording (http://picamera.readthedocs.org/en/rele ... r-the-hood has the gory details of what goes on at the MMAL level). So, you could try something like this:

Code: Select all

with picamera.PiCamera() as camera:
    camera.resolution = camera.MAX_RESOLUTION
    camera.framerate = 4
    camera.start_recording('foo.h264', resize=(1296, 972))
    camera.wait_recording(30)
    camera.stop_recording()

I haven't tested this directly against a straight 1296x972 output so I can't say it'll provide better quality, but it's worth a shot?


Dave.

[jbeale]

Code: Select all

with picamera.PiCamera() as camera:
    camera.resolution = camera.MAX_RESOLUTION
    camera.framerate = 4
    camera.start_recording('foo.h264', resize=(1296, 972))
    camera.wait_recording(30)
    camera.stop_recording()

I haven't tested this directly against a straight 1296x972 output so I can't say it'll provide better quality, but it's worth a shot?

Thanks, that was exactly what I was looking for! I compared your example quoted above, with simply setting the 1296 x 972 resolution directly (using the on chip 2x2 bin instead of GPU resizing). When doing it with the GPU resize, the image quality was clearly superior, as expected.

[XAPBob]

Currently using:

Code: Select all

camera.capture_continuous(stream, format='jpeg')

If I don't enable the preview before I start then will the camera still have do all the mode switch between frames?
Will it capture faster? Will it have to rework the AWB each frame independently?

It looks about the same consistency in terms of AWB, but the framerate hasn't noticeably changed.

[waveform80]

Currently using:

Code: Select all

camera.capture_continuous(stream, format='jpeg')

If I don't enable the preview before I start then will the camera still have do all the mode switch between frames? Will it capture faster? Will it have to rework the AWB each frame independently?

Short answers: Yes, No, Depends on the AWB settings.

Long answer: Even if you don't start a preview, a preview is still actually running but directed to a null sink . This is necessary because the camera's auto-exposure algorithm doesn't run otherwise and captures get gradually darker and darker until they're completely black. See issue #22 for an example. When you call start_preview what actually happens is that the active preview is switched from the null-sink to the preview renderer. When you call stop_preview, it's switched back again. So all the mode changes and everything you see going on when the preview is visible still go on without having called start_preview - they're just not visible.

On the AWB question, if the AWB mode is off and you're using manual AWB gains (with the awb_gains property introduced in 1.4) then no, but otherwise I'd assume AWB is recalculated for each capture.


Dave.

[XAPBob]

OK - that makes sense - even if it is a little irritating.
The mode switch is quite irritating on a directly connected monitor, and the drop in viewing angle available from the video port, as well as the reduction in quality isn't ideal.

Edit:
Actually - I just changed my script to add the video mode and the output quality and angle don't seem to have changed at all...
I'm not at home, so can't see the attached monitor though.

I've not fiddled with the AWB at the moment, it seems to "do the right thing" by default (in my application)

[waveform80]

OK - that makes sense - even if it is a little irritating.
The mode switch is quite irritating on a directly connected monitor, and the drop in viewing angle available from the video port, as well as the reduction in quality isn't ideal.


Actually - I just changed my script to add the video mode and the output quality and angle don't seem to have changed much...
I'm not at home, so can't see the attached monitor though.

Well, there was a firmware update fairly recently (last month? maybe just before that?) that substantially increased the number of resolutions that now get full FoV. The camera hardware chapter in the docs has a section on the new modes.


Dave.