waveform80 wrote:
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".

kelevraxx wrote: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!

waveform80 wrote:
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:

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?

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)

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.

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

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

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.

jbeale wrote: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 / 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.

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.

jbeale wrote: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.

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:

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.

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.

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)

Last edited by XAPBob on Wed May 14, 2014 12:02 pm, edited 1 time in total.

XAPBob wrote: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.