Page 19 of 19

Re: Pure Python camera interface

Posted: Sun Jun 19, 2016 10:28 pm
by waveform80
Well, it's been a while! Picamera 1.11 is *finally* here, bringing a host of stuff that you can read about in the full changelog but the highlights are:
  • full compatibility with the V2 module (max resolution supported, etc.)
  • direct capture to buffer protocol objects (like numpy arrays)
  • live manipulation of the framerate
  • manual request of key-frames for H264 recording
Part of the reason this release has taken so long is that the guts of picamera have undergone a considerable change with this release. A new layer (mmalobj) is introduced which aims to simplify usage of MMAL for Python users (partly this makes my life easier, but hopefully it might make it easier for others to hack on picamera in the future). In addition, the default pipeline changes considerably for several use-cases.

This won't affect anybody doing basic stuff (capturing JPEGs, recording H264 video) but if you're doing anything like unencoded captures (YUV, RGB, etc.) or grabbing motion estimation data you will probably need to make sure you're running cutting edge firmware (sudo rpi-update) at least until certain firmware changes hit Raspbian stable...

Part of the reason this release has taken a long time is that behind the scenes I've been bugging the extremely long suffering 6by9 day and night with piles of requests for info about, or bug fixes to, the firmware. In the past, picamera has done certain truly horrid things to make things work smoothly on the surface. For example, if you requested an RGB capture from the still port, this wouldn't directly work: the still port would refuse to commit the RGB format. So instead picamera stuck the port in YUV format, attached a resizer with the same resolution as the camera (so it wasn't resizing), set *its* output to RGBA (not RGB ... because RGB didn't work on the resizer), performed the capture, then stripped off the redundant alpha bytes in Python. Ouch. Obviously this was horrid and slow. Well, no more! The still port in cutting edge firmwares will now commit an RGB format properly, and picamera will take advantage of that.

There's similar stories for unencoded captures on the video port. The upshot is that if you're doing stuff like unencoded captures or motion vector capture, you'll want cutting edge firmware (at least until it hits Raspbian stable, so if you're reading this a couple of months from now don't worry about it).

As always, PyPI packages are already up but Raspbian packages will take a few more days to hit the repos, so have some patience if you want to stick with the apt-get installation. I'm off to help out at picademy for the next couple of days, so I won't be able to answer questions until Wednesday. In the meantime, enjoy!

Dave.

Re: Pure Python camera interface

Posted: Mon Jun 20, 2016 2:35 pm
by jjsanderson
Woohoo! Congratulations on getting this out of the door, Dave. I'm looking forward to playing around with it and bringing my image processing code up-to-date for an installation piece I built for Maker Faire UK. It's been in mothballs for a couple of months, but is about to have another outing up here in Newcastle. It looks like you've already addressed a couple of the issues I was working around - great!

Re: Pure Python camera interface

Posted: Mon Jun 20, 2016 2:58 pm
by 6by9
Yes it looks like the Raspbian version of the firmware is from 23rd May 2016, so not quite recent enough to pick up all the extra magic that is required by 1.11.

It looks like Jun 2, 2016 (rpi-update 4468c4c) is the earliest version that includes the changes for video_splitter that are critical for PiCamera 1.11. I'll ask Pi Towers what their plans are for getting firmware bumped.
(When the firmware is bumped it will also include the fix for correcting BGR888 and RGB888 support from the camera. PiCamera 1.11 includes the support for that so it should be invisible to the user. It is likely to cause grief for older versions of PiCamera).

Re: Pure Python camera interface

Posted: Mon Jun 20, 2016 3:31 pm
by jbeale
Great stuff, as always! Thanks for making this great tool even better... looks like it's time to try playing around with some things.

Question: does the picamera.image_denoise attribute affect both still and video? I gather at the MMAL layer they are separate things, given I have seen mention of MMAL_PARAMETER_VIDEO_DENOISE viewtopic.php?f=43&t=145815&start=350#p996767

Re: Pure Python camera interface

Posted: Mon Jun 20, 2016 3:46 pm
by pindiza
Thanks for the hard work ... Cracking job! ... this interface makes the Pi really versatile for Computer Vision projects (and easy to use too!)

Re: Pure Python camera interface

Posted: Mon Jun 20, 2016 3:52 pm
by 6by9
jbeale wrote:Great stuff, as always! Thanks for making this great tool even better... looks like it's time to try playing around with some things.

Question: does the picamera.image_denoise attribute affect both still and video? I gather at the MMAL layer they are separate things, given I have seen mention of MMAL_PARAMETER_VIDEO_DENOISE viewtopic.php?f=43&t=145815&start=350#p996767
Er, http://picamera.readthedocs.io/en/relea ... eo_denoise

Or if you wanted to check the source, it's all there, and a quick search on the appropriate MMAL_PARAMETER_xxxx values would have given you your answer.

Re: Pure Python camera interface

Posted: Mon Jun 20, 2016 4:39 pm
by jbeale
Thanks again 6by9 ! Indeed it was a silly question- I had searched the docs, but stopped on the first hit which was "image" rather than "video".

Re: Pure Python camera interface

Posted: Sun Jul 03, 2016 11:13 pm
by waveform80
Well, here's 1.12. A bit quicker than I'd expected but there was a rather important issue (297) that needed a quick release to fix. As you can probably guess there's nothing else really notable in this release (other than some other bug fixes and some rather esoteric functionality in the Color class which I managed to find a little time to finish).

TL;DR: if you're doing unencoded capture in Python 3, you'll want to upgrade to 1.12. If not, don't worry about it unless you're upgrading stuff anyway!


Dave.

Re: Pure Python camera interface

Posted: Mon Aug 01, 2016 2:27 pm
by cww
Thanks
we'll give it a try. I don't get a lot of time to work with this, but, we'll see.

Re: Pure Python camera interface

Posted: Sat Feb 25, 2017 8:43 pm
by waveform80
Picamera 1.13 is now released! As usual, it'll be a few days until it hits the Raspbian repos but it's on PyPI now, and the docs should be updated in a mo.

The major news this time around is a serious re-working of the lower level mmalobj API. I'm guessing most people haven't touched this so a quick intro is in order: mmalobj is the layer between picamera and MMAL. MMAL is the C API that raspistill, raspivid, and picamera are ultimately built on, and mmalobj is a relatively thin layer that sits on top of this and tries to make it a little simpler to use (by taking away some of the decisions you generally have to make when using MMAL like when to release buffers, when to allocate buffer pools, how to allocate them, how big they should be, etc). The main picamera API (PiCamera, PiEncoder, etc.) sits on top of mmalobj.

The most important enhancement mmalobj gets in 1.13 is "pure python components". These are components that, to the mmalobj user, look and feel like "proper" MMAL components (like the camera, video encoder, etc.) but which have a Python implementation (under the covers, they're nothing like MMAL components and incur a pretty heavy performance penalty due to all the memory copying required, but it's the best I can do for now). Anyway, if you're using this lower level API this means you can build your own components and shove them in the MMAL pipeline, e.g. to draw something on top of video frames before they reach the encoder / renderer. Some simple demos are included in the docs (read the mmalobj chapter for a full tour).

There's also lots of bugs fixed in the main API: PiCameraCircularIO.copy_to had a nasty one that meant the "seconds" filter sometimes didn't work correctly, PiCamera.capture_continuous had a bug causing duplicate frames, and 10 second captures should no longer timeout on the V2 module (the default CAPTURE_TIMEOUT has been bumped to 60 seconds to accommodate this). When an updated firmware lands there should also be support for partially transparent overlays.

A lot of work has also gone into the docs in this version: the PDF and E-pub downloads from RTD should now be significantly more useful (in hard-copy or e-readers), the Advanced Recipes chapter has undergone significant revisions (new recipes, and much better versions of existing recipes), and the Camera Hardware chapter almost doubles in size with a detailed description of the low level operation of the camera module. I'd strongly encourage anyone who's read these chapters before to take a look at the new ones.

Anyway, as always: enjoy and do feel free to let me know of any bugs, requests, wishes, etc.!


Dave.

Re: Pure Python camera interface

Posted: Sun Feb 26, 2017 4:49 pm
by jmmec
waveform80 wrote:Picamera 1.13 is now released! ... and the Camera Hardware chapter almost doubles in size with a detailed description of the low level operation of the camera module. I'd strongly encourage anyone who's read these chapters before to take a look at the new ones.
Thank you so much! Really appreciate Picamera, especially all the effort you've put into it.

Re: simple motion-detector using picamera

Posted: Thu Aug 30, 2018 9:47 pm
by Son1c
del

Re: Pure Python camera interface

Posted: Sat Sep 01, 2018 1:04 pm
by easybob95
Hello,

i am new with raspberry and picamera. I decided to make my own capture software using Python language and it works quite well.

My purpose : to make a sky survey using raspberry pi 3 b+ and picamera V2.

You can see my program (V1) here :

https://www.facebook.com/10001024080826 ... 980401722/

Everything works just fine for short exposure time.

My 2 major problems are :

- the ISO system : it is not suitable for my purpose. I need to be able to set analog gain as i want and i need the gain setup to be stable (no change)
- long exposure time (more than 3s) is really strange. I need about 20s to get a 4 or 6 second exposure picture. It is very unstable and it's a very big problem for me.

My wishes :
- a function to set camera gain (disable ISO system)
- a better management of long exposures (several seconds).

Do you think you can bring positive answers to my demands ?

Best regards.

Alain