Re: Pure Python camera interface
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 ?
Re: Pure Python camera interface
Dave, I do have one question for you.waveform80 wrote:
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.
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
- Posts: 359
- Joined: Mon Sep 23, 2013 1:28 pm
- Location: Manchester, UK
- Contact: Website Twitter
Re: Pure Python camera interface
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.hoyh wrote: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 ?
Dave.
Author of / contributor to a few pi related things (picamera, Sense HAT emulator, gpio-zero, piwheels, etc.), and currently a software engineer at Canonical responsible for Ubuntu Server and Core on the Raspberry Pi.
- waveform80
- Posts: 359
- Joined: Mon Sep 23, 2013 1:28 pm
- Location: Manchester, UK
- Contact: Website Twitter
Re: Pure Python camera interface
Hi Ketta,
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)
Anyway, good luck with your project!
Dave.
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.Ketta wrote: 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?
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).Ketta wrote: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.
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)
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).Ketta wrote: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!
Anyway, good luck with your project!
Dave.
Author of / contributor to a few pi related things (picamera, Sense HAT emulator, gpio-zero, piwheels, etc.), and currently a software engineer at Canonical responsible for Ubuntu Server and Core on the Raspberry Pi.
Re: Pure Python camera interface
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..
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..
Re: Pure Python camera interface
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:
and that produces an image in memory which can then be written out.
However:
(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?
I can do single capture:
Code: Select all
>>> camera.capture(stream, format='jpeg', resize=(640, 480))
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
>>>
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
Re: Pure Python camera interface
Your line is missing a colon at the end.XAPBob wrote: 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 >>>
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
Re: Pure Python camera interface
Aha - that might well be it - thanks...
Programming fine, Python new
Hmm - Nearly:
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...
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
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
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)
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
apt-get install & "No Module named picamera"
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.
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
- Posts: 359
- Joined: Mon Sep 23, 2013 1:28 pm
- Location: Manchester, UK
- Contact: Website Twitter
Re: Pure Python camera interface
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:XAPBob wrote:...
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...
I should note that the continuous capture was working when I was capturing to file...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)
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()
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.XAPBob wrote: 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
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.XAPBob wrote: Also that the preview is jumping - presumably to a different camera mode, approx once each loop
Dave.
Author of / contributor to a few pi related things (picamera, Sense HAT emulator, gpio-zero, piwheels, etc.), and currently a software engineer at Canonical responsible for Ubuntu Server and Core on the Raspberry Pi.
- waveform80
- Posts: 359
- Joined: Mon Sep 23, 2013 1:28 pm
- Location: Manchester, UK
- Contact: Website Twitter
Re: apt-get install & "No Module named picamera"
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".JTeagle wrote: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.
Dave.
Author of / contributor to a few pi related things (picamera, Sense HAT emulator, gpio-zero, piwheels, etc.), and currently a software engineer at Canonical responsible for Ubuntu Server and Core on the Raspberry Pi.
Re: apt-get install & "No Module named picamera"
I can confirm with python -V that I'm running 2.7.3, and I did install python-picamera rather than python3-picamera.waveform80 wrote: 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".
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
- Posts: 359
- Joined: Mon Sep 23, 2013 1:28 pm
- Location: Manchester, UK
- Contact: Website Twitter
Re: Pure Python camera interface
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!Ketta wrote: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.
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.Ketta wrote: 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..
Dave.
Author of / contributor to a few pi related things (picamera, Sense HAT emulator, gpio-zero, piwheels, etc.), and currently a software engineer at Canonical responsible for Ubuntu Server and Core on the Raspberry Pi.
- waveform80
- Posts: 359
- Joined: Mon Sep 23, 2013 1:28 pm
- Location: Manchester, UK
- Contact: Website Twitter
Re: apt-get install & "No Module named picamera"
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).JTeagle wrote:I can confirm with python -V that I'm running 2.7.3, and I did install python-picamera rather than python3-picamera.waveform80 wrote: 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".
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?
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.
Author of / contributor to a few pi related things (picamera, Sense HAT emulator, gpio-zero, piwheels, etc.), and currently a software engineer at Canonical responsible for Ubuntu Server and Core on the Raspberry Pi.
Re: apt-get install & "No Module named picamera"
*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.waveform80 wrote: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.
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
Re: Pure Python camera interface
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?waveform80 wrote:
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:
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).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()
That's alot of exif data!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.XAPBob wrote: 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
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.
[/QUOTE]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.XAPBob wrote: Also that the preview is jumping - presumably to a different camera mode, approx once each loop
Dave.
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

Re: Pure Python camera interface
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.
Re: Pure Python camera interface
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?XAPBob wrote: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...waveform80 wrote: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.XAPBob wrote: Also that the preview is jumping - presumably to a different camera mode, approx once each loop
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...
Last edited by XAPBob on Wed Apr 16, 2014 3:38 pm, edited 1 time in total.
Re: Pure Python camera interface
@waveform80
Have you changed something in the code, because "picamera.led = False" is no longer running since update to v1.3?
Have you changed something in the code, because "picamera.led = False" is no longer running since update to v1.3?
Re: Pure Python camera interface
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!!!
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
- Posts: 359
- Joined: Mon Sep 23, 2013 1:28 pm
- Location: Manchester, UK
- Contact: Website Twitter
Re: Pure Python camera interface
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.:bootsmann wrote:@waveform80
Have you changed something in the code, because "picamera.led = False" is no longer running since update to v1.3?
Code: Select all
import picamera
with picamera.PiCamera() as camera:
camera.led = False
camera.led = True
Dave.
Author of / contributor to a few pi related things (picamera, Sense HAT emulator, gpio-zero, piwheels, etc.), and currently a software engineer at Canonical responsible for Ubuntu Server and Core on the Raspberry Pi.
- waveform80
- Posts: 359
- Joined: Mon Sep 23, 2013 1:28 pm
- Location: Manchester, UK
- Contact: Website Twitter
Re: Pure Python camera interface
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.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!!!
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.
Author of / contributor to a few pi related things (picamera, Sense HAT emulator, gpio-zero, piwheels, etc.), and currently a software engineer at Canonical responsible for Ubuntu Server and Core on the Raspberry Pi.
- waveform80
- Posts: 359
- Joined: Mon Sep 23, 2013 1:28 pm
- Location: Manchester, UK
- Contact: Website Twitter
Re: Pure Python camera interface
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.XAPBob wrote: ...
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...
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.
Author of / contributor to a few pi related things (picamera, Sense HAT emulator, gpio-zero, piwheels, etc.), and currently a software engineer at Canonical responsible for Ubuntu Server and Core on the Raspberry Pi.
- waveform80
- Posts: 359
- Joined: Mon Sep 23, 2013 1:28 pm
- Location: Manchester, UK
- Contact: Website Twitter
Re: Pure Python camera interface
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).JTeagle wrote: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.
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.
Author of / contributor to a few pi related things (picamera, Sense HAT emulator, gpio-zero, piwheels, etc.), and currently a software engineer at Canonical responsible for Ubuntu Server and Core on the Raspberry Pi.
Re: Pure Python camera interface
Thanks Dave, I'll try that.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).
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)?