The Cameras

If there’s one thing that people were waiting for with the iPad 2, it’s the inclusion of cameras. CPU and GPU performance improvements with the iPad 2 are dramatic, but it’s the cameras that will drive both existing and new iPad customers to the device. For being probably the single most notable difference between the iPad 2 and its predecessor, the camera execution and experience on the iPad 2 is actually surprisingly bad. 

I could pretty much sum up the iPad 2 cameras with one word: mediocre. The interface, the physical placement of the rear camera, and finally actual quality all leave room for considerable improvement. If you want a video overview of the entire iPad 2 camera situation, check out our video review

The front facing camera is actually about where it should be, in fact. VGA is standard fare for iOS devices because right now FaceTime is just 320x240 from iDevices. My issue isn’t with the front facing camera, it’s the back camera that really under-delivers, and for that reason the iPad 2 feels like it’s a device saddled with two front-facing cameras. The fact that they’re better than nothing (e.g. iPad 1) is small consolation for how seriously underwhelming the rear camera is. 

Both cameras are identical to what comes in the iPod Touch 4th generation, a device that starts at $229. At $499, it doesn’t seem like a completely unreasonable thing to expect cameras that are at least somewhat better. 

Let’s start with the camera user interface. At first glance, it’s the exact same as the camera interface on the iPhone and iPod Touch. Capture button in the center, a link to the photo application with thumbnail of the last captured photo in the bottom left, a digital zoom slider after a tap, and a switch between video and still at right. Up in the top right is the switch-front-back camera button as well. The iPad has no HDR options, and obviously no LED flash options either. Tapping on the preview exposes for the tapped region, but since the rear camera is fixed focus, focus doesn’t change. 

What’s really annoying about this interface is that it rotates.

I’ve spent every second since first picking up the iPad 2 wondering what possessed Apple’s UI designers to make this decision, asking myself what possible benefits this choice could have. The only possible one is that this is an equalizer for left-handed users, but then why not simply make an option in settings to change the location of the bar from the left to the right side? 

The problem with keeping the capture/switch bar at the bottom of each orientation is that it puts the capture button in the absolute worst possible place.

At each orientation, the capture button is dead center at the bottom. The result is that to tap capture, you need to either stretch your thumb all the way to reach it, or remove your hand and tap with the index finger.

 

Both of those result in a much less stable grip position and add to shake. Moreover, it’s a downright fatiguing position to have to hold the iPad in for any length of time. It’s somewhat annoying in portrait, but downright frustrating in landscape.

Putting the capture button here is painful. Were it left closest to the home button like it is on smaller iDevices, the capture button would be right near where the thumb naturally rests. Tap it with your thumb, and boom, no problem. Maybe a transparent button would also make sense.

The other problem with the capture interface is that if you have relatively large palms or tightly grip the iPad 2 to brace it and reduce shake, you run the risk of causing an unintended touch on the lower right or left corners. Numerous times, I went to hit capture and found that nothing happened. When that occurred, generally it was because I was touching the bottom left or right with my palm inadvertently. Touch filtering or heck, maybe some of that multitouch wizardry would go a long way here, Apple. 

The final problem is with placement of the actual camera. Because of its position in the extreme top left (viewed from the back), the only viable way to hold the iPad 2 for landscape capture is with the home button on the right side. Hold it naturally with the button on the left side, and you'll end up blocking the camera with your hand like this:

The image preview in still mode is cropped to 4:3 and upscaled to XGA. The native resolution of the rear camera is 1280x720 (16:9). To get to 960x720 (4:3) Apple simply cuts off 160 pixels on the left and right. The fact that the image preview in still capture mode is upscaled to the full size of the iPad 2 display accentuates its underwhelming and noisy quality dramatically. It doesn’t look awesome. The front facing VGA camera blown up to XGA is even less impressive. 

The only positive side effect of all this is that image capture is insanely quick. You can literally mash the capture button on both the front and rear cameras and capture essentially as fast as you can tap. No doubt some of that is the A5's impressive speed gains, but the other part of it is just the low resolution of those two cameras.

 

 

HDMI Mirroring & Charging Video and Still Quality Analysis
POST A COMMENT

189 Comments

View All Comments

  • PeteH - Saturday, March 19, 2011 - link

    In the Garage Band section:

    "There are three Smart Instruments - Piano, Bass, Guitar, and Drums."

    I'm pretty sure that "three" should be a "four."
    Reply
  • VivekGowri - Sunday, March 20, 2011 - link

    Ahaha, I'm an idiot - thanks for catching that, it'll be fixed. Reply
  • PeteH - Sunday, March 20, 2011 - link

    As far as typos go that one isn't remotely bad. I once published a spec (internally) that had a section detailing how asynchronous boundaries were handled in my section of a chip. Unfortunately I had titled that section "Cock Domain Crossings." Reply
  • Anand Lal Shimpi - Sunday, March 20, 2011 - link

    A few years ago I used the word overcocking instead of overclocking in an article. Reply
  • UNLK A6 - Saturday, March 19, 2011 - link

    I'd like some clarification about LINPACK and Geekbench. Are these benchmarks created by compiling some portable code for each platform as a measure of floating point performance? Or, is this supposed to be some measure of how fast one can do linear algebra or DSP on the platform? On Mac OS and iOS, one wouldn't compile say LINPACK for this but use the hand-tuned LAPACK/BLAS and DSP routines built into Apple's Accelerate Framework. The difference between the two can be huge. Which do these benchmarks purport to supply--generic floating point performance or available linear algebra and DSP performance on the platform? Reply
  • metafor - Sunday, March 20, 2011 - link

    I believe Linpack on both iOS and Android are plainly compiled (by the JIT in the case of Android) to run on the platform. They don't make any calls against the onboard DSP's nor do they use NEON beyond what the compiler is able to auto-vectorize. Reply
  • name99 - Sunday, March 20, 2011 - link

    Apple supplies all the Linpack routines in optimized NEON code as part of the OS (in the Accelerate framework). Intelligent apps that need them use those routines.
    Android, as far as I know, does not provide an equivalent.

    You can use apps that deliberately bypass these iOS routines if you wish to get a handle on the raw FP performance of the hardware, but
    (a) it doesn't give actual linear algebra performance, if that is something your app or algorithm really cares about AND
    (b) it's kinda dumb because if you care about fp performance in any way, you'll be using NEON, so what's the value in a benchmark that doesn't exercise NEON?
    Reply
  • nimus - Sunday, March 20, 2011 - link

    I hope AnandTech can do a comprehensive comparison of the usability/feature strengths between the Android, Apple iOS, BlackBerry Tablet OS (QNX), HP webOS, and any others tablet OSes.

    It will be interesting to see how the Windows Tablet OS will be able to compete when it finally is released for ARM processors.
    Reply
  • KidneyBean - Sunday, March 20, 2011 - link

    I'm using a tablet, so I can't see the mouse-over pics :-( Reply
  • tcool93 - Sunday, March 20, 2011 - link

    I don't know where the reviewer gets the idea Netbooks are much faster. That is nonsense. Here is a video showing an ARM 9 processor being just as fast, yet the ARM 9 processor is running 1/3 the speed of the Netbook Atom. (500mhz vs. 1600mhz for the Netbook).

    http://www.youtube.com/watch?v=W4W6lVQl3QA&fea...

    The Netbook also has a graphics accelerator in it, and the ARM shown in this video doesn't.
    Reply

Log in

Don't have an account? Sign up now