<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>bunnyhero dev &#187; UIImagePickerController</title>
	<atom:link href="http://www.bunnyhero.org/tag/uiimagepickercontroller/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.bunnyhero.org</link>
	<description>Notes on iPhone, Flash and Web development</description>
	<lastBuildDate>Tue, 31 Aug 2010 20:51:25 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
		<item>
		<title>Thoughts on iOS 4 camera APIs: privacy issues, new UI possibilities?</title>
		<link>http://www.bunnyhero.org/2010/08/17/thoughts-on-ios4-camera/</link>
		<comments>http://www.bunnyhero.org/2010/08/17/thoughts-on-ios4-camera/#comments</comments>
		<pubDate>Tue, 17 Aug 2010 20:58:51 +0000</pubDate>
		<dc:creator>bunnyhero</dc:creator>
				<category><![CDATA[Security]]></category>
		<category><![CDATA[iPhone]]></category>
		<category><![CDATA[avfoundation]]></category>
		<category><![CDATA[privacy]]></category>
		<category><![CDATA[UI]]></category>
		<category><![CDATA[UIImagePickerController]]></category>

		<guid isPermaLink="false">http://www.bunnyhero.org/?p=402</guid>
		<description><![CDATA[While playing with the new AVFoundation APIs, it occurred to me that in iOS 4, apps can now easily access the camera with no feedback to the user. Before, apps had to use UIImagePickerController, which shows the iris-opening animation before recording starts, even if you hide the preview image using cameraViewTransform. With AVFoundation&#8217;s AVCaptureSession, there is no indication to the user at all that the camera is in use unless the app provides its own. There is no permission alert, nor any LED indicator like a webcam. An app could secretly be recording your face with the iPhone 4&#8242;s front-facing camera and sending it to who knows where. I wonder if Apple&#8217;s app review team checks for this in some way? On the other hand, the new APIs make it much easier to integrate non-photo-taking uses of the camera into an app. I could imagine using the iPhone 4&#8242;s front camera for non-touch gesture controls or facial expression recognition. Makes me wish I knew something about real time image processing!]]></description>
			<content:encoded><![CDATA[<p>While playing with the new AVFoundation APIs, it occurred to me that in iOS 4, apps can now easily access the camera with no feedback to the user. Before, apps had to use  <code>UIImagePickerController</code>, which shows the iris-opening animation before recording starts, even if you hide the preview image using <code>cameraViewTransform</code>. With AVFoundation&#8217;s <code>AVCaptureSession</code>, there is no indication to the user at all that the camera is in use unless the app provides its own. There is no permission alert, nor any LED indicator like a webcam. An app could secretly be recording your face with the iPhone 4&#8242;s front-facing camera and sending it  to who knows where. I wonder if Apple&#8217;s app review team checks for this in some way?</p>
<p>On the other hand, the new APIs make it much easier to integrate non-photo-taking uses of the camera into an app. I could imagine using the iPhone 4&#8242;s front camera for non-touch gesture controls or facial expression recognition. Makes me wish I knew something about real time image processing!</p>
]]></content:encoded>
			<wfw:commentRss>http://www.bunnyhero.org/2010/08/17/thoughts-on-ios4-camera/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>UIImagePickerController cropRect seems to be useless?</title>
		<link>http://www.bunnyhero.org/2009/06/06/uiimagepickercontroller-croprect-seems-to-be-useless/</link>
		<comments>http://www.bunnyhero.org/2009/06/06/uiimagepickercontroller-croprect-seems-to-be-useless/#comments</comments>
		<pubDate>Sat, 06 Jun 2009 17:52:58 +0000</pubDate>
		<dc:creator>bunnyhero</dc:creator>
				<category><![CDATA[iPhone]]></category>
		<category><![CDATA[images]]></category>
		<category><![CDATA[UIImagePickerController]]></category>

		<guid isPermaLink="false">http://www.bunnyhero.org/?p=190</guid>
		<description><![CDATA[[UPDATE: In iPhone OS 3.0, the cropRect behaves more consistently (even if it's still a little odd), see Stormy Productions' Image Picker Sample, which works perfectly in 3.0. This article only applies to 2.2.1.] I am using UIImagePickerController to let the user choose an image from their photo library, and allowing image editing (move and scale). When the user is done moving and scaling, the OS calls my UIImagePickerControllerDelegate&#8216;s didFinishPicking method with information about the original image and the cropping rect in editingInfo. One might think that the cropping rectangle returned by the UIImagePickerController would be in the coordinate system of the original UIImage, since that would make the most sense. One would be wrong, however. Based on my own experiments on my iPhone and various threads on Apple message boards, it seems that sometimes the cropping rectangle is based on a 640&#215;480 image (that is: the original photo is first resized to 640&#215;480 pixels, and the cropRect is in the resized image&#8217;s coordinate system). But not always! Screenshots taken on iPhone (using power button + home button), which are 320&#215;480, have a cropRect based on the original image size. So that&#8217;s easy to deal with then, right? Just compare [...]]]></description>
			<content:encoded><![CDATA[<p><em>[<strong>UPDATE:</strong> In iPhone OS 3.0, the cropRect behaves more consistently (even if it's still a little odd), see Stormy Productions' <a href="http://blog.stormyprods.com/2009/06/image-picker-sample.html">Image Picker Sample</a>, which works perfectly in 3.0. This article only applies to 2.2.1.]</em></p>
<p>I am using <a href="http://developer.apple.com/iphone/library/documentation/uikit/reference/UIImagePickerController_Class/UIImagePickerController/UIImagePickerController.html"><code>UIImagePickerController</code></a> to let the user choose an image from their photo library, and allowing image editing (move and scale).</p>
<p>When the user is done moving and scaling, the OS calls my <a href="http://developer.apple.com/iphone/library/documentation/uikit/reference/UIImagePickerControllerDelegate_Protocol/UIImagePickerControllerDelegate/UIImagePickerControllerDelegate.html"><code>UIImagePickerControllerDelegate</code></a>&#8216;s <a href="http://developer.apple.com/iphone/library/documentation/uikit/reference/UIImagePickerControllerDelegate_Protocol/UIImagePickerControllerDelegate/UIImagePickerControllerDelegate.html#//apple_ref/doc/uid/TP40007069-CH3-SW4">didFinishPicking</a> method with information about the original image and the cropping rect in <code>editingInfo</code>.<br />
<img src="http://www.bunnyhero.org/wp-content/uploads/2009/06/img_0004.jpg" alt="move and scale" title="move and scale" width="320" height="480" class="aligncenter size-full wp-image-194" /><br />
One might think that the cropping rectangle returned by the <code>UIImagePickerController</code> would be in the coordinate system of the original <code>UIImage</code>, since that would make the most sense. One would be wrong, however. Based on my own experiments on my iPhone and various threads on Apple message boards, it seems that <strong><em>sometimes</em> the cropping rectangle is based on a 640&#215;480 image</strong> (that is: the original photo is <em>first resized to 640&#215;480 pixels</em>, and the cropRect is in <em>the resized image&#8217;s coordinate system</em>).</p>
<p>But not always! Screenshots taken on iPhone (using power button + home button), which are <strong>320&#215;480, have a cropRect based on the original image size</strong>.</p>
<p>So that&#8217;s easy to deal with then, right? Just compare the original image&#8217;s size to see if it&#8217;s 320&#215;480 or not&#8230;</p>
<p>Not so fast. That does not always work. I have on my iPhone some 320&#215;480 images that, when picked with the image picker, return <strong>cropRects that are in some weird coordinate system</strong>. An unzoomed (1:1) crop returns a width and height of 432&#215;433! That would imply the <strong>image is scaled to 432&#215;648 before cropping</strong>. Odd!</p>
<p>(Where did these images come from? Both of them were created by other iPhone apps, saving a 320&#215;480 image to the photo library. <em><strong>UPDATE:</strong> it seems to happen with JPEGs of certain sizes/proportions. See my <a href="http://www.bunnyhero.org/2009/06/06/uiimagepickercontroller-croprect-seems-to-be-useless/comment-page-1/#comment-26797">comments</a> for <a href="http://www.bunnyhero.org/2009/06/06/uiimagepickercontroller-croprect-seems-to-be-useless/comment-page-1/#comment-26798">sample images</a>.</em>)</p>
<p>Unfortunately, so far I have been unable to distinguish between these two types of 320&#215;480 images in code. <strong>Without being able to get reliable info about the coordinate system of the cropping rect, the cropping rect is basically useless.</strong> (And no, you can&#8217;t just compare the cropRect to see if it&#8217;s 432 pixels wide :P Once you scale that picture in the image picker, the width could be anything, still in that weird coordinate system.)</p>
<p>If anyone has any code that <em>reliably</em> deals with <em>all images</em> (including images of arbitrary dimension [e.g 527 x 325] that are saved to the iPhone), at all zoom levels, please let me know :)</p>
]]></content:encoded>
			<wfw:commentRss>http://www.bunnyhero.org/2009/06/06/uiimagepickercontroller-croprect-seems-to-be-useless/feed/</wfw:commentRss>
		<slash:comments>12</slash:comments>
		</item>
	</channel>
</rss>
