Pure Python camera interface

[hoyh]

Hello, Thanks for this great library, unfortunately I got a strange error, when I try to make a photo with the camera.capture('./photo.jpg') the script hangs sometimes and gives me the error: Timed out waiting for capture end. The error is random and sometimes it just works. Do you have a solution ?

[Ketta]

Hi - are you by any chance running a recent firmware? (i.e. have you done "sudo rpi-update" recently?). The reason I ask if I've been experimenting with the new firmware for the new modes and one of the tests that's failing under it is to do with shutter speed. It seems that somewhere around revision 648 the firmware changed the implementation of shutter speed so that it's now clamped by the current framerate.

So, if you want to set shutter speed to something more than 33ms (which is the limit for 30fps) you first need to set framerate to some appropriately low value (e.g. 1fps or lower - currently lower framerates require the use of a (num, denom) tuple but the next release will permit fractions and floats to be specified too). I'm updating the docs in the next release to reflect the firmware change.


Dave.

Dave, I do have one question for you.

Do you see a point in the future where shutter speed and the specified framerate will again be independent of one another, and particularly so with the PiCamera library?

I am working on a project at the moment with an Infrared Pi Camera Module where I believe the pixel binning that results from the camera software's new modes will be a perfect solution. However, at the moment being able to manually adjust the shutter speed is an integral part of the project. I am concerned that this conflict between raspivid and your library will prohibit me from being able to use newer versions of either that program or the library. At least until I figure out a workaround or a better way of achieving these goals.

As always, thank you so much for the work you have done. PiCamera has helped me move along so far in my development, both of the project and my own programming ability, in the past few months.

Ketta

EDIT:
I also see that you are intending to add support for an OpenGL overlay? That sounds absolutely fantastic Dave. I think that would be perfect for my application. I have achieved this thus far with setting the LED to blink while recording, but an on-screen indicator would be ideal to include as well.

So many possibilities for this project. I hope that it is keeping you entertained when you find the right chances to work on it!

[waveform80]

Hello, Thanks for this great library, unfortunately I got a strange error, when I try to make a photo with the camera.capture('./photo.jpg') the script hangs sometimes and gives me the error: Timed out waiting for capture end. The error is random and sometimes it just works. Do you have a solution ?

Could you let me know what settings you're using? Resolution, framerate, etc. - also what version of firmware you're running might be useful (run "uname -a" at the command line and it's the number after #). I've seen this error in certain circumstances (when attempting raw RGB captures for example, where picamera spends a silly amount of time stripping alpha bytes out of the output), but I've not yet seen it with JPEGs.

Dave.

[waveform80]

Hi Ketta,

Dave, I do have one question for you.

Do you see a point in the future where shutter speed and the specified framerate will again be independent of one another, and particularly so with the PiCamera library?

I'm probably the wrong person to ask about this. Basically - it's not down to picamera - it's down to the camera firmware (picamera is mostly just a thin layer on top of libmmal, at least as far as shutter speed and framerate are concerned). JamesH is probably a better bet for an answer to this.

I am working on a project at the moment with an Infrared Pi Camera Module where I believe the pixel binning that results from the camera software's new modes will be a perfect solution. However, at the moment being able to manually adjust the shutter speed is an integral part of the project. I am concerned that this conflict between raspivid and your library will prohibit me from being able to use newer versions of either that program or the library. At least until I figure out a workaround or a better way of achieving these goals.

You can still adjust the shutter speed manually (and as far as I know within the same ranges as you could on older firmwares), it's just that you need to set framerate appropriately before doing so; older firmwares were rather inconsistent in this regard - you could set a half-second shutter speed but framerate would still report something like 30fps when the camera was clearly only doing 2fps. In other words, the clamping of shutter-speed doesn't remove any functionality - just makes the camera more consistent in what it reports (although admittedly it means a tiny amount more code for users of the camera).

It's also not a conflict between picamera and raspivid(/raspistill/raspiyuv) - both are implemented with libmmal so both should act identically in this regard (I'd be interested to know if they don't! I know of a few discrepancies between picamera and raspiyuv but those're due to the extra complexity in picamera to support things like capture+record)

EDIT:
I also see that you are intending to add support for an OpenGL overlay? That sounds absolutely fantastic Dave. I think that would be perfect for my application. I have achieved this thus far with setting the LED to blink while recording, but an on-screen indicator would be ideal to include as well.

So many possibilities for this project. I hope that it is keeping you entertained when you find the right chances to work on it!

Certainly hoping to find some more time to work on this over summer - the last few weeks have been incredibly hectic and I haven't had time to do much on picamera (despite there being a couple of bugs that need squishing for the next release).

Anyway, good luck with your project!


Dave.

[Ketta]

Thank you for the clarification! I must have misinterpreted that other discussion.

Do you think it is possible to use picamera on the ArchLinux ARM distro? I'm finding that a faster loading time supplied by ArchLinux and systemd would also be a nice improvement for my application that runs upon startup. If this isn't possible then its no big deal, but it would be an excellent convenience.

Okay, I see that Raspibian can use Systemd as well (Just not quite as fast) so now I suppose I just need to figure out how to make my script launch at startup since rc.local isn't used with that manager..

Oh, also, am I able to use these new camera modes in PiCamera but with the partial field of vision as was previously used for video? I want to remain consistent between 1080p and other video modes, and I have replaced the lens on the module with something that is tuned perfectly with the video port view in mind..

[XAPBob]

Just trying to get continuous capture to run with the resize option. My code currently is pushing the images to a stream for manipulation by PIL (adding timestamp, doing basic motion detection)...


I can do single capture:

Code: Select all

>>> camera.capture(stream, format='jpeg', resize=(640, 480))

and that produces an image in memory which can then be written out.

However:

Code: Select all

>>> for i in camera.capture_continuous(stream, format='jpeg', resize=(640,480))
  File "<stdin>", line 1
    for i in camera.capture_continuous(stream, format='jpeg', resize=(640,480))
                                                                              ^
SyntaxError: invalid syntax
>>>

(The syntax error caret is pointing at the final bracket)

I suppose I could just do single captures in a loop...
But is there something obvious I'm missing against the library?

Code: Select all

Python 2.7.3

Code: Select all

Package: python-picamera
State: installed
Version: 1.3-1

[Aydan]

However:

Code: Select all

>>> for i in camera.capture_continuous(stream, format='jpeg', resize=(640,480))
  File "<stdin>", line 1
    for i in camera.capture_continuous(stream, format='jpeg', resize=(640,480))
                                                                              ^
SyntaxError: invalid syntax
>>>

Your line is missing a colon at the end.
Whenever you start a block in python, be it a while, for, if, def, class or whatever that needs indentation afterwards you have to have a colon on the end of the line.

Regards
Aydan

[XAPBob]

Aha - that might well be it - thanks...

Programming fine, Python new

Hmm - Nearly:

Code: Select all

# ./test2.py
Traceback (most recent call last):
  File "./test2.py", line 31, in <module>
    image = Image.open(stream)
  File "/usr/lib/python2.7/dist-packages/PIL/Image.py", line 1980, in open
    raise IOError("cannot identify image file")
IOError: cannot identify image file

For reference (although it's not yet commented, and has a few variables from previous drafts)
There are two loops defined - there are a couple of obvious lines to comment out/uncomment to switch between them.
The capture version works, the capture continuous version doesn't...

Code: Select all

#!/usr/bin/python

import os, io, shutil
import time, datetime
import picamera
import Image, ImageDraw, ImageFont

tmpdir="/tmp/ramfs/camera/"
latest=tmpdir + "latest.jpg"
previous=tmpdir + "previous.jpg"
font24 = ImageFont.truetype("/usr/share/fonts/truetype/freefont/FreeSans.ttf", 24)
font72 = ImageFont.truetype("/usr/share/fonts/truetype/freefont/FreeSans.ttf", 72)

if not os.path.exists(tmpdir):
        os.mkdir(tmpdir,0777)

# Create the in-memory stream
stream = io.BytesIO()

with picamera.PiCamera() as camera:
    camera.led = False # Turn off the LED
    camera.preview_fullscreen = True
    camera.rotation = 180
    camera.start_preview()
    time.sleep(2) # Let the camera settle
# Either:
    while True:
        camera.capture(stream, format='jpeg', resize=(640,480))
# Or:
#    while camera.capture_continuous(stream, format='jpeg', resize=(640,480)):
#Then:
        stream.seek(0)         # "Rewind" the stream to the beginning so we can read its contents
        image = Image.open(stream)
        draw = ImageDraw.Draw(image)
        timestamp = datetime.datetime.now().strftime("%d %B %Y %H:%M:%S UTC")
        draw.text((10,10), timestamp, (255,0,0), font=font24)
        image.save(latest)
        #print timestamp
        stream.seek(0)

I should note that the continuous capture was working when I was capturing to file...

As an aside I did note that the jpeg saved by PIL was ~1/8th the size of that from the camera.capture and yet I can't spot the difference on my screen

Also that the preview is jumping - presumably to a different camera mode, approx once each loop

[JTeagle]

As per the documentation for Raspbian, I used the apt-get route to install the Python 2.7 version of picamera.

Unfortunately I'm getting

No module named picamera

when I try to import it. The installation instructions don't appear to mention any final step required... any idea what I might be missing?

Thanks.

[waveform80]

...
For reference (although it's not yet commented, and has a few variables from previous drafts)
There are two loops defined - there are a couple of obvious lines to comment out/uncomment to switch between them.
The capture version works, the capture continuous version doesn't...

Code: Select all

#!/usr/bin/python

import os, io, shutil
import time, datetime
import picamera
import Image, ImageDraw, ImageFont

tmpdir="/tmp/ramfs/camera/"
latest=tmpdir + "latest.jpg"
previous=tmpdir + "previous.jpg"
font24 = ImageFont.truetype("/usr/share/fonts/truetype/freefont/FreeSans.ttf", 24)
font72 = ImageFont.truetype("/usr/share/fonts/truetype/freefont/FreeSans.ttf", 72)

if not os.path.exists(tmpdir):
        os.mkdir(tmpdir,0777)

# Create the in-memory stream
stream = io.BytesIO()

with picamera.PiCamera() as camera:
    camera.led = False # Turn off the LED
    camera.preview_fullscreen = True
    camera.rotation = 180
    camera.start_preview()
    time.sleep(2) # Let the camera settle
# Either:
    while True:
        camera.capture(stream, format='jpeg', resize=(640,480))
# Or:
#    while camera.capture_continuous(stream, format='jpeg', resize=(640,480)):
#Then:
        stream.seek(0)         # "Rewind" the stream to the beginning so we can read its contents
        image = Image.open(stream)
        draw = ImageDraw.Draw(image)
        timestamp = datetime.datetime.now().strftime("%d %B %Y %H:%M:%S UTC")
        draw.text((10,10), timestamp, (255,0,0), font=font24)
        image.save(latest)
        #print timestamp
        stream.seek(0)

I should note that the continuous capture was working when I was capturing to file...

The capture_continuous method returns an iterator which you need to use a "for" loop to iterate over (I can't remember off the top of my head what an iterator does with a "while" loop - but it won't be correct :). So instead of "while camera.capture_continuous..." you want something like:

Code: Select all

    for stream in camera.capture_continuous(stream, format='jpeg', resize=(640, 480)):
        stream.seek(0)         # "Rewind" the stream to the beginning so we can read its contents
        image = Image.open(stream)
        draw = ImageDraw.Draw(image)
        timestamp = datetime.datetime.now().strftime("%d %B %Y %H:%M:%S UTC")
        draw.text((10,10), timestamp, (255,0,0), font=font24)
        image.save(latest)
        #print timestamp
        stream.seek(0)
        # truncate the stream (in case the next image is shorter)
        stream.truncate()

Note that I've added a truncate at the end as well. Otherwise, if the next image is shorter then the stream will contain the image plus some left over bytes from the prior image (which may confuse a JPEG reader).

As an aside I did note that the jpeg saved by PIL was ~1/8th the size of that from the camera.capture and yet I can't spot the difference on my screen

The default quality settings used by PIL may be different (it's difficult to tell the difference at the top end), and you'll probably find PIL's stripped all the Exif stuff that the camera adds in there (including a thumbnail by default) which can be quite large.

Also that the preview is jumping - presumably to a different camera mode, approx once each loop

That'll be the mode switch because you're using a "normal" still capture (using a video-port based capture doesn't cause this). On older firmwares the preview would jump between a small field of view to full field of view when capturing. On the newer firmwares (which offer full field of view in the preview in most modes), if your resolution has a wide-screen ratio (16:9) you'll find it jumps between the center of the field of view and the top of the field of view when capturing (at least, that's what I've noticed in testing). I don't think I noticed a jump when using a 4:3 aspect ratio but I can't recall off the top of my head.


Dave.

[waveform80]

As per the documentation for Raspbian, I used the apt-get route to install the Python 2.7 version of picamera.

Unfortunately I'm getting

No module named picamera

when I try to import it. The installation instructions don't appear to mention any final step required... any idea what I might be missing?

Thanks.

Any chance you've installed the python 2 package and you're using python 3 (or vice versa)? If you've done "sudo apt-get install python-picamera" that only installs the python 2 version of the package. The python 3 version is installed with "sudo apt-get install python3-picamera".


Dave.

[JTeagle]

Any chance you've installed the python 2 package and you're using python 3 (or vice versa)? If you've done "sudo apt-get install python-picamera" that only installs the python 2 version of the package. The python 3 version is installed with "sudo apt-get install python3-picamera".

I can confirm with python -V that I'm running 2.7.3, and I did install python-picamera rather than python3-picamera.

Something I read later (elsewhere) suggest I'm missing a step - it is my understanding that apt-get install installs *executables*, libraries and other binaries... I'm not sure whether python modules suitable for import are considered source [script] or binaries? If they are source, then perhaps I need to run something that was installed to get those modules? I'm very new to Linux so I'm grasping here. The installation section did, however, imply that the install was sufficient.

I've seen mention of easy_install (I've got setuptools installed now, I think), but it isn't clear if I still need to run that?

[waveform80]

Thank you for the clarification! I must have misinterpreted that other discussion.

Do you think it is possible to use picamera on the ArchLinux ARM distro? I'm finding that a faster loading time supplied by ArchLinux and systemd would also be a nice improvement for my application that runs upon startup. If this isn't possible then its no big deal, but it would be an excellent convenience.

It should be possible (just follow the pip install instructions instead of the apt-get based ones) but I can't say I've tested it (and I don't recall anyone else mentioning using it on Arch). I'd be interested to hear either way though!

Okay, I see that Raspibian can use Systemd as well (Just not quite as fast) so now I suppose I just need to figure out how to make my script launch at startup since rc.local isn't used with that manager..

Oh, also, am I able to use these new camera modes in PiCamera but with the partial field of vision as was previously used for video? I want to remain consistent between 1080p and other video modes, and I have replaced the lens on the module with something that is tuned perfectly with the video port view in mind..

Hmm ... I think the 1080p mode uses a partial FoV in the new modes so you shouldn't have an issue at that resolution. In lower resolutions (which now use full FoV) you can probably use the "crop" attribute to restrict the FoV to the required area.


Dave.

[waveform80]

Any chance you've installed the python 2 package and you're using python 3 (or vice versa)? If you've done "sudo apt-get install python-picamera" that only installs the python 2 version of the package. The python 3 version is installed with "sudo apt-get install python3-picamera".

I can confirm with python -V that I'm running 2.7.3, and I did install python-picamera rather than python3-picamera.

Something I read later (elsewhere) suggest I'm missing a step - it is my understanding that apt-get install installs *executables*, libraries and other binaries... I'm not sure whether python modules suitable for import are considered source [script] or binaries? If they are source, then perhaps I need to run something that was installed to get those modules? I'm very new to Linux so I'm grasping here. The installation section did, however, imply that the install was sufficient.

I've seen mention of easy_install (I've got setuptools installed now, I think), but it isn't clear if I still need to run that?

apt-get is a package manager - basically it's capable of installing anything (binaries, libraries, scripts, documentation, you name it). The line "sudo apt-get install python-picamera" should indeed be sufficient to install the library for Python 2 (all the pip/easy_install sections are primarily for non-Raspbian users or developers who want to use virtualenvs).

When you run "sudo apt-get install python-picamera" what do you see (can you paste it in here? If you SSH into your Pi it should be simple to copy'n'paste it). If the package is indeed installed it should simply refuse to install it again.

Dave.

[JTeagle]

When you run "sudo apt-get install python-picamera" what do you see (can you paste it in here? If you SSH into your Pi it should be simple to copy'n'paste it). If the package is indeed installed it should simply refuse to install it again.

*sigh* My fault. I had installed it, but then because I did not see something I expected and I had previously started with the tar.gz files and unzipped them to a directory, I went and removed the package and deleted the directory so that I could start afresh... and promptly forgot to install the package again.

It works fine now - sorry for the hiccup.

It's a brilliant piece of work, btw. It allows me to concentrate on high-level stuff without worrying about how to access the hardware. I'm very grateful for it!

Jason

[XAPBob]

The capture_continuous method returns an iterator which you need to use a "for" loop to iterate over (I can't remember off the top of my head what an iterator does with a "while" loop - but it won't be correct . So instead of "while camera.capture_continuous..." you want something like:

Code: Select all

    for stream in camera.capture_continuous(stream, format='jpeg', resize=(640, 480)):
        stream.seek(0)         # "Rewind" the stream to the beginning so we can read its contents
        image = Image.open(stream)
        draw = ImageDraw.Draw(image)
        timestamp = datetime.datetime.now().strftime("%d %B %Y %H:%M:%S UTC")
        draw.text((10,10), timestamp, (255,0,0), font=font24)
        image.save(latest)
        #print timestamp
        stream.seek(0)
        # truncate the stream (in case the next image is shorter)
        stream.truncate()

Note that I've added a truncate at the end as well. Otherwise, if the next image is shorter then the stream will contain the image plus some left over bytes from the prior image (which may confuse a JPEG reader).

Truncate is a new one on me, makes sense - thank you. And of course the loop needs to be different. Is there a reason to prefer one over the other?

As an aside I did note that the jpeg saved by PIL was ~1/8th the size of that from the camera.capture and yet I can't spot the difference on my screen

The default quality settings used by PIL may be different (it's difficult to tell the difference at the top end), and you'll probably find PIL's stripped all the Exif stuff that the camera adds in there (including a thumbnail by default) which can be quite large.

That's alot of exif data!
I was assuming that the quality was different, but such a small gain (invisible) for such a huge amount of data. For security (which is the main purpose of this camera) I'm popping the time on the picture (in a relatively unimportant location) - so EXIF data isn't too problematic.

Also that the preview is jumping - presumably to a different camera mode, approx once each loop

That'll be the mode switch because you're using a "normal" still capture (using a video-port based capture doesn't cause this). On older firmwares the preview would jump between a small field of view to full field of view when capturing. On the newer firmwares (which offer full field of view in the preview in most modes), if your resolution has a wide-screen ratio (16:9) you'll find it jumps between the center of the field of view and the top of the field of view when capturing (at least, that's what I've noticed in testing). I don't think I noticed a jump when using a 4:3 aspect ratio but I can't recall off the top of my head.


Dave.

[/QUOTE]
Ah, so I need to grab with the video port enabled. And should therefore expect grainer but ?faster? capture... The 10m HDMI to the office is quite hard to watch at the moment...


Many thanks - this is a really nice abstraction of hardware, and the ability to run everything in memory is useful - I'm dumping to a file in a ramdisk when needed, and will get 'interesting' things sent to either dropbox or a GMail account (free, fat, remote storage )

[JTeagle]

I read somewhere (documentation site is down at the moment) that capturing in argb format was faster as that was more of a native format - but when I tried that in the call to capture() it didn't like it. In fact, although "rgb" works, when I look at the code where the complaint came from, it doesn't even mention that - only "jpeg", "gif", "bmp" and "png". Is there a way to get argb and should I use this? I don't see a need for whopping frame rates so if the gain is of no significance then not a problem.

[XAPBob]

Also that the preview is jumping - presumably to a different camera mode, approx once each loop

That'll be the mode switch because you're using a "normal" still capture (using a video-port based capture doesn't cause this). On older firmwares the preview would jump between a small field of view to full field of view when capturing. On the newer firmwares (which offer full field of view in the preview in most modes), if your resolution has a wide-screen ratio (16:9) you'll find it jumps between the center of the field of view and the top of the field of view when capturing (at least, that's what I've noticed in testing). I don't think I noticed a jump when using a 4:3 aspect ratio but I can't recall off the top of my head.

Ah, so I need to grab with the video port enabled. And should therefore expect grainer but ?faster? capture... The 10m HDMI to the office is quite hard to watch at the moment...

Hmm - the Video port FoV is significantly narrower. Can I force the preview to be Full FoV, even if only at a handful of fps?

I could avoid it all by using something like fbi to display the image - although the complete GPU approach is preferable...

Edit:
Just reread this and noticed the firmware question - now updated, but don't have the monitor in front of me any more

Edit2:
At a set resolution of (640,480) the preview no longer jumps (much), and it is full FoV. I have my image rotated 180, but the image jumps down and to the right by about 10-15 pixels (guesstimated) as I look at it, it also goes lighter and with better focus for each shot, so not great for leaving up on a monitor.
I could reset the resolution for high quality images when motion is detected I suppose...

[bootsmann]

@waveform80

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

[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!!!

[waveform80]

@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.

[waveform80]

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.

[waveform80]

...
Edit2:
At a set resolution of (640,480) the preview no longer jumps (much), and it is full FoV. I have my image rotated 180, but the image jumps down and to the right by about 10-15 pixels (guesstimated) as I look at it, it also goes lighter and with better focus for each shot, so not great for leaving up on a monitor.
I could reset the resolution for high quality images when motion is detected I suppose...

I've noticed still-port captures tend to look a bit brighter than the preview - it might be something to do with the still port using several frames for its images (something video-port captures don't do), but I'm no expert on the firmware so that's just a wild guess.

On the image jumping, you might want to try vflip/hflip instead of rotate (if you're not already) but there's not much else I can suggest - that's just the way the new firmware operates, I'm afraid.

I haven't got a monitor hooked up to my Pi at the moment, but I should probably find out if raspistill jumps in the same way for captures - I know it uses different settings for the preview as of the latest versions (picamera maintains the same res for preview and capture, raspistill/vid uses a fixed res for preview, and varies the capture res - since 1.3.7 I think). If it does jump in the same way, it might be worth taking this up with JamesH (who writes raspistill/vid and also maintains much of the camera firmware).


Dave.

[waveform80]

I read somewhere (documentation site is down at the moment) that capturing in argb format was faster as that was more of a native format - but when I tried that in the call to capture() it didn't like it. In fact, although "rgb" works, when I look at the code where the complaint came from, it doesn't even mention that - only "jpeg", "gif", "bmp" and "png". Is there a way to get argb and should I use this? I don't see a need for whopping frame rates so if the gain is of no significance then not a problem.

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).

I'll be revisiting this in the next release (when I find a spare day or two) as there's some issues with raw captures which appeared with the latest firmware update (picamera's pipeline is too complex compared to raspiyuv's, so it fails with certain combinations of resolution and format).


Dave.

[JTeagle]

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)?