Camera

The iPhone 5s continues Apple’s tradition of sensible improvements to camera performance each generation. I was pleased to hear Phil Schiller deliver a line about how bigger pixels are a better route to improving image quality vs. throwing more at the problem. I remember hearing our own Brian Klug deliver almost that exact same message a year earlier when speaking to some engineers at another phone company.

The iPhone 5s increases sensor size compared to the iPhone 5. Last week Brian dug around and concluded that the 5s’ iSight camera sensor likely uses a format very similar to that of the HTC One. The difference here is while HTC opted for even larger pixels (arriving at 4MP), Apple chose a different balance of spatial resolution to light sensitivity with its 8MP sensor.

One thing ingrained in my mind from listening to Brian talk about optics is that there is no perfect solution, everything ultimately boils down to a selection of tradeoffs. Looking at Apple/HTC vs. the rest of the industry we see one set of tradeoffs, with Apple and HTC optimizing for low light performance while the rest of the industry chasing smaller pixel sizes. Even within Apple and HTC however there are differing tradeoffs. HTC went more extreme in pixel size while Apple opted for more spatial resolution.

iPhone 4, 4S, 5, 5S Cameras
Property iPhone 4 iPhone 4S iPhone 5 iPhone 5S
CMOS Sensor OV5650 IMX145 IMX145-Derivative ?
Sensor Format 1/3.2"
(4.54x3.42 mm)
1/3.2"
(4.54x3.42 mm)
1/3.2" ~1/3.0"
(4.89x3.67 mm)
Optical Elements 4 Plastic 5 Plastic 5 Plastic 5 Plastic
Pixel Size 1.75 µm 1.4 µm 1.4 µm 1.5 µm
Focal Length 3.85 mm 4.28 mm 4.10 mm 4.12 mm
Aperture F/2.8 F/2.4 F/2.4 F/2.2
Image Capture Size 2592 x 1936
(5 MP)
3264 x 2448
(8 MP)
3264 x 2448
(8 MP)
3264 x 2448
(8 MP)
Average File Size ~2.03 MB (AVG) ~2.77 MB (AVG) ~2.3 MB (AVG) 2.5 MB (AVG)
From Brian's excellent iPhone 5s Camera Analysis post

Apple moved to 1.5µm pixels, up from 1.4µm in the iPhone 5. Remember that we’re measuring pixel size in a single dimension, so the overall increase in pixel size amounts to around 15%. Apple also moved to a faster aperture (F/2.2 vs. F/2.4 on the iPhone 5) to increase light throughput. The combination can result in significantly better photos than the outgoing 5 when taking photos in low light.

iPhone 5/5c Low Light

iPhone 5s Low Light

With the move to larger pixels, Apple has done away with its 2x2 binning mode in low light settings. The iPhone 5 would oversample each pixel after scene brightness dropped below a certain threshold to improve low light performance. The oversampled image would then be upscaled to the full 8MP, trading off spatial resolution for low light performance. The iPhone 5s doesn’t have to make this tradeoff. In practice I didn’t find any situations where the 5s’ low light performance suffered as a result. It always seemed to produce better shots than the iPhone 5.

iPhone 5/5c

iPhone 5s

Unlike some of the larger flagships we’ve reviewed lately, the iPhone 5s doesn’t ship with optical image stabilization (OIS). We’ve seen devices from HTC, LG and Nokia all ship with OIS, and have generally been pleased with the results. It’s not a surprise that the 5s doesn’t come with OIS as it’s largely the same physical platform as the outgoing 5. Still it would be great to see an Apple device ship with OIS. Perhaps on a larger iPhone.

As is always the case in space constrained camera systems, what Apple could not achieve in the physical space it hopes to make up for computationally. The 5s leverages electronic image stabilization as well as automatic combination of multiple frames from the capture buffer in order to deliver the sharpest shots each time.

Apple’s cameras have traditionally been quite good, not just based on sensor selection but looking at the entire stack from its own custom ISP (Image Signal Processor) and software. With the A7 Apple introduces a brand new ISP. Although we know very little about the new ISP, you can find references to Apple’s H6 ISP if you dig around.

Apple continues to ship one of the better auto modes among smartphone cameras I've used. I still want the option of full manual controls, but for most users Apple's default experience should be a very good one.

Capturing shots under iOS 7 is incredibly quick. Shot to shot latency is basically instantaneous now, thanks to a very fast ISP and the A7’s ability to quickly move data in and out of main memory. It’s impossible to write shots to NAND this quickly so Apple is likely buffering shots to DRAM before bursting them out to non-volatile storage.

 

The new ISP enables a burst capture mode of up to 10 fps. To active burst mode simply hold down the shutter button and fire away. The iPhone 5s will maintain a 10 fps capture rate until the burst counter hits 999 images (which was most definitely tested). Although it took a while to write all 999 images, all of them were eventually committed to NAND.

Photos captured in burst mode are intelligently combined as to not clutter your photo gallery. The camera app will automatically flag what it thinks are important photos, but you’re free to choose as many (or as few) as you’d like to include in your normal browsing view. Since all of the photos captured in burst mode are physically saved, regardless of whether or not you select them to appear among your photos, you can always just pull them off the 5s via USB.

The rear facing camera is paired with a new dual-LED True Tone flash. Rather than featuring a single white LED to act as a flash, Apple equips the iPhone 5s with two LEDs with different color tones (one with a cool tone and one with a warm tone). When set to fire, the 5s’ ISP and camera system will evaluate the color temperature of the scene, pre-fire the flash and determine the right combination of the two LEDs to produce the most natural illumination of the subject.

I’m not a huge fan of flashes, but I have to say that in a pinch the True Tone flash is appreciably better than the single LED unit on the iPhone 5. Taking photos of people with the new True Tone flash enabled produces much warmer and more natural looking results:

True Tone Flash Enabled

Even if your subject happens to be something other than a person I’ve seen really good results from Apple’s True Tone flash.

I still believe the best option is to grab your photo using natural/available light, but with a smartphone being as portable as it is that’s not always going to be an option.

I have to say I appreciate the vector along which Apple improved the camera experience with the iPhone 5s. Improving low light performance (and quality in low light situations where you’re forced to use a flash) is a great message to carry forward.

Front Facing Camera

The iPhone 5s and iPhone 5c share the same upgraded front-facing FaceTime HD camera. The front facing camera gets a sensor upgrade, also with a move to larger pixels (1.9µm up from 1.75µm) while resolution and aperture remain the same at 720p and F/2.4. The larger sensor size once again improves low light performance of the FaceTime HD camera (iPhone 5 left vs. iPhone 5s right):

Battery Life Video
Comments Locked

464 Comments

View All Comments

  • ddriver - Wednesday, September 18, 2013 - link

    I mean, only a true apple fanboy is capable of disregarding all that technical argumentation because of the mention of the term "apple fanboys". A drowning man will hold onto a straw :)
  • akdj - Thursday, September 19, 2013 - link

    You consider your comment 'technical argumentation'? It's not....it's your 'opinion'. I think you can rest assured Anand's site is geared much more to those of us interested in technology and less interested in being a 'fanboy'. In fact....so far reading through the comments, you're the first to bring that silly cliché up, "Fan Boy".
    A drowning man will hold on to anything to help save himself :)
  • Wilco1 - Wednesday, September 18, 2013 - link

    Good comment - I'm equally unimpressed by the comparison of a real phone with a Bay Trail tablet development board which has significantly higher TDP. And then calling it a win for Bay Trail based on a few rubbish JS benchmarks is even more ridiculous. These are not real CPU benchmarks but all about software optimization and tuning for the benchmark.

    Single threaded Geekbench 3 results show the A7 outperforming the 2.4GHz Bay Trail by 45%. That's despite the A7 running at only 54% of the frequency of Bay Trail! In short, A7 is 2.7 times faster than BT and on par/better than HasWell IPC...
  • tech4real - Wednesday, September 18, 2013 - link

    not trying to dismiss A7's cpu core, it's an amazing silicon and significantly steps up against A6, but is there a possibility that the geekbench3 is unfit to gauge average cross-ISA cross-OS cpu performance... To me, the likelihood of this is pretty high.
  • Wilco1 - Wednesday, September 18, 2013 - link

    Comparing different ISAs does indeed introduce inaccuracies due to compilers not being equal. Cross OS is less problematic as long as the benchmark doesn't use the OS a lot.

    It's a good idea to keep this in mind, but unfortunately there is little one can do about it. And other CPU benchmarks are not any better either, if you used SPEC then performance differences across different compilers are far larger than Geekbench (even on the same CPU the difference between 2 compilers can be 50%)...
  • Dooderoo - Wednesday, September 18, 2013 - link

    "The AES and SHA1 gains are a direct result of the new cryptographic instructions that are a part of ARMv8. The AES test in particular shows nearly an order of magnitude performance improvement".

    Your comment: "in reality the encryption workloads are handled in a fundamentally different way in the two modes [...] a mixed bad into one falsely advertising performance gains attributed to 64bit execution and not to the hardware implementations as it should"

    Maybe actually read the article?

    "The FP chart also shows no miracles, wider SIMD units result in almost 2x the score in few tests, nothing much in the rest"
    Exclude those test and you're still looking at 30% improvement. 30% increase in performance from a recompile counts at "nothing much" in what world?
  • ddriver - Wednesday, September 18, 2013 - link

    My point was encryption results should not have been included in the chart and presented as "benefits of 64bit execution mode" because they aren't.

    Also those 30% can easily be attributed to other incremental upgrades to the chip, like faster memory subsystem, better prefetchers and whatnot. Not necessarily 64bit execution, I've been using HPC software for years and despite the fact x64 came with double the registers, I did not experience any significant increase in the workloads I use daily - 3D rendering, audio and video processing and multiphysics simulations. The sole benefit of 64bit I've seen professionally is due to the extra ram I can put into the machine, making tasks which require a lot of ram WAY FASTER, sometimes 10s even 100s times faster because of the avoided swapping.

    Furthermore, I will no longer address technically unsubstantiated comments, in order to avoid spamming all over the comment space.
  • Dooderoo - Wednesday, September 18, 2013 - link

    "Furthermore, I will no longer address technically unsubstantiated comments, in order to avoid spamming all over the comment space."
    Man, you give up too easily.

    Encryption results are exactly that: "benefits of 64bit execution mode". Why? 32-bit A32 doesn't have the instructions, 64-bit A64 does. Clear and obvious benefit.

    "30% can easily be attributed to other incremental upgrades to the chip". Wouldn't the 32-bit version benefit from those as well?

    I'm beginning to think you don't understand that those results are both from the A7 SOC, once run with A32 and once with A64.
  • ddriver - Wednesday, September 18, 2013 - link

    ""30% can easily be attributed to other incremental upgrades to the chip". Wouldn't the 32-bit version benefit from those as well?"

    This may be correct. Unless I am overlooking execution mode details, of which I am not aware, and I expect neither are you, unless you are an engineer who has worked on the A7 chip. I don't think that data is available yet to comment on it in detail.

    But you are not correct about encryption results, because it is a matter of extra hardware implementation. It is like comparing software rendering to hardware rendering, a CPU with hardware implementation of graphics will be immensely faster at a graphics workload, even if it is the same speed as the one that runs graphics in software. If anything, the architecture upgrades of the A7 chip can at best result in 2x peak theoretical performance improvement, while the AES test shows 8+x improvement. This is because the performance boost is not due to 64 bit mode execution, but due to the extra hardware implementation that is exclusively available in that mode.
  • Dooderoo - Wednesday, September 18, 2013 - link

    "I don't think that data is available yet to comment on it in detail."
    Yet you're ok with calling the article "cunningly deceitful"? Weird.

Log in

Don't have an account? Sign up now