views:

993

answers:

3

The docs hint at the ability of takePicture to run multiple times in a single modal view. Particularly "This supports taking more than one picture without leaving the interface, but requires that you hide the default image picker controls."

I'd like to take 25 pictures in roughly 4 seconds, however from what I've read, there are issues with doing that in a tight loop. I'd be sleeping for ~ .16 seconds between photos and I suspect that won't be a sufficient amount of time between photos: http://stackoverflow.com/questions/1647321/iphone-taking-a-picture-programmatically

I'd use UIGetScreenImage(), but from the discussion here, it looks like that will prevent the app from getting into the store: http://stackoverflow.com/questions/1531815/takepicture-vs-uigetscreenimage

If anyone has any suggestions it would be greatly appreciated.

A: 

if you call takePicture, expect to wait around two seconds before a picture is returned to you via didFinishPickingMediaWithInfo. I'm am pretty sure that if you call takePicture again before your first picture is returned, it won't work, and you'll see a message in the debug output saying something like "takePicture called when already taking a picture", but you can easily try that experiment for yourself.

In any case, I'd be very surprised if you managed to get six pictures/second to work.

There's currently no way to programmatically start video capture, but depending on what you're trying to accomplish you could perhaps have the user capture a video and then use a library like FFmpeg to extract the frames you want from the resulting video clip.

David Maymudes
Here's an app that's doing something close to what you want: 8 pictures over three seconds. Not sure how they do it! http://www.senstic.com/iphone/burst/burst.aspx
David Maymudes
thx for the info on the expected times. yeah its basically a workaround to support users that don't have 3GS phones, so video isn't really an option, thx for the ffmpeg suggestions tho.
Stephen Handley
oh sorry didn't see your comment till now.. that looks really interesting, wonder if they're using UIGetScreenImage..
Stephen Handley
further comment: I was wrong above: it doesn't really take 2 seconds for didFinishPickingMediaWithInfo; you get that call back in around half a second, and can take another picture then. the problem is that it takes about 2 seconds to actually do anything with the returned picture, like make a smaller copy of it, and there's only enough memory for a few full-size images at a time, so you can't keep going for long keeping the full-size images in memory. UIGetScreenImage takes small screen-sized pictures, so it wouldn't have that memory problem. (if it's ever allowed through review.)
David Maymudes
A: 

http://www.redlaser.com/SDK.aspx

"UPDATE: 11/18/2009 Apple is now allowing applications that use the Realtime SDK through the review process. If you are using the Photo-Burst SDK, switch to the Realtime SDK."

...Suggests that you can now use UIGetScreenImage, or some similar low level call to snap pictures faster than the takePicture method.

Kenny Winker
they've taken that message down, so maybe they're not so sure about approval... http://support.redlaser.com/discussion/102/Realtime-SDK-Now-Allowed
David Maymudes
bummer. i'll try messing around with UIGetScreenImage anyway. do you know what apple's justification for not allowing that is?
Stephen Handley
+1  A: 

UIGetScreenImage(); is now allowed and should suit your needs for more rapid-fire photos.

Edit: dredful below is correct. Apple has opened access to an official real-time video data stream.

davidcann
It seems that Apple has reversed it's position on UIGetScreenImage(). It is no longer allowed. http://www.tuaw.com/2010/07/21/devsugar-rip-uigetscreenimage/
dredful