The iPhone 5s Review
by Anand Lal Shimpi on September 17, 2013 9:01 PM EST- Posted in
- Smartphones
- Apple
- Mobile
- iPhone
- iPhone 5S
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) |
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):
Facebook
Twitter
RSS
464 Comments
View All Comments
Dug - Wednesday, September 18, 2013 - link
"maybe you should hire a developer to write native cross platform benchmark tools"WHY? It is not going to make any difference. Developers aren't writing native cross platform programs. If they can take advantage of anything that's in the system, then show it off.
That would be like telling car manufacturers to redesign a hybrid to gas only to compare with all the other gas only cars.
ddriver - Wednesday, September 18, 2013 - link
"Developers aren't writing native cross platform programs"Maybe it is about time you crawl from under the rock you are living under... Any even remotely concerned with performance and efficiency application pretty much mandates it is a native application. It would be incredibly stupid to not do it, considering the "closest" to native language Java is like 2-3 times slower and users 10-20 times as much memory.
Dug - Wednesday, September 18, 2013 - link
Exactly my point! "native cross platform" Each cross-platform solution can only support a subset of the functionality included in each native platform.It doesn't get you anywhere to produce a native cross platform benchmark tool.
Again you have to mitigate to names and snide comments because you are wrong.
ddriver - Wednesday, September 18, 2013 - link
What you talk about is I/O, events and stuff like that. When it comes to pure number crunching the same code can execute perfectly well for every platform it is complied against. Actually, some modern frameworks go even further than that and provide ample abstractions. For example, the same GUI application can run on Windows, Linux, MacOS, iOS and Android, apart from a few other minor platforms.Anand Lal Shimpi - Wednesday, September 18, 2013 - link
Ultimately the benchmarking problem is being fixed, just not on the time scale that we want it to. I figured we'd be better off by now, and in many ways we are (WebXPRT, Browsermark are both steps in the right direction, we have more native tools under Android now) but part of the problem is there was a long period of uncertainty around what OSes would prevail. Now that question is finally being answered and we're seeing some real investment in benchmarks. Trust me, I tried to do a lot behind the scenes over the past 4 years (some of which Brian and I did recently) but this stuff takes time. I remember going through this in the early days of the PC industry too though, I know how it all ends - it'll just take a little time to get there.Actually I think 128-bit registers might've been optional on v7.
The only reason encryption results are in that table is because that's how Geekbench groups them. There's no nefarious purpose there (note that it's how we've always reported the Geekbench results, as they are reported in the test themselves).
In my experience with the 5s I haven't noticed any performance regressions compared to the 5/5c. I'm not saying they don't exist and I'll continue to hunt, it's just that they aren't there now. I believe I established the reasoning for why you'd want to do this early, and again we're talking about at most 12 months before they should start the move to 64-bit anyways. Apple tends to like its ISA transitions to be as quick and painless as possible, and moving early to ARMv8 makes a lot of sense in that light. Sure they are benefiting from the marketing benefits of having a feature that no one else does, but what company doesn't do that?
I don't believe the move to 64-bit with Cyclone was driven first and foremost by marketing. Keep in mind that this architecture was designed when a bunch of certain ex-AMDers were over there too...
Take care,
Anand
BrooksT - Wednesday, September 18, 2013 - link
Why would Anand write cross-platform benchmarks that have no connection to real world usage? Especially when you then complain that the 64 bit coverage isn't real world enough?ddriver - Wednesday, September 18, 2013 - link
For starters, putting the encryption results in their own graph, like every other review before that, and side to side comparison between geekbench ST/MT scores for A7 and competing v7 chips would be a good start toward a more objective and less biased article.And I know I am asking a lot, but an edit feature in the comment section is long overdue...
TheBretz - Wednesday, September 18, 2013 - link
For what it's worth this is NOT a case of LITERALLY comparing "Apples" and "Oranges" - it is a case of comparing "Apple" and many other manufacturers, but there was no fruit involved in the comparison, only smarthphones and tablets.ddriver - Wednesday, September 18, 2013 - link
Apples to oranges is a figure of speech, it has nothing to do with the company apple... It concerns comparing incomparable objects which is the case of completely different JS implementations on iOS and Android.Arbee - Wednesday, September 18, 2013 - link
Please name any case when AT's benchmarks and reviews have been proven to be biased or inaccurate. There's a reason the writers at other sites consider AT the gold standard for solid technical commentary (Engadget, Gizmodo, and the Verge all regularly credit AT on technical stories). As far as bias, have you *heard* Brian cooing about practically wanting to marry the Nexus 5? ;-)I think what actually happened here is that apparently Apple engineers listen to the AT podcast, because aside from 802.11ac and the screen size the 5S is designed almost perfectly to AT's well-known and often-stated specifications. It hits all of Anand's chip architecture geekery hot buttons in a way that Samsung's mashups of off-the-shelf parts never will, and they used Brian's exact line "Bigger pixels means better pictures" in the presentation. And naturally, if someone gives you what you want, you're likely to be happy with it. This is why people have Amazon gift lists ;-)
Krait's 128 bit SIMD definitely helps, but it won't match true v8 architecture designs. I've written commercially shipping ARM assembly, and there's a *lot* of cruft in the older ISA that v8 cleans right up. And it lets compilers generate *much* more favorable code. I'll be surprised if the next Snapdragons aren't at least 32-bit v8. Qualcomm has been pretty forward-looking aside from their refusal to cooperate with the open-source community (Freedreno FTW).
As far as 64 bit on less than 4 GB of RAM, it enables applications to more freely operate on files in NAND without taking up huge amounts of RAM (via mmap(), which the Linux kernel in Android of course also has). Apps like Loopy HD and MultiTrack DAW (not to mention Apple's own iMovie and GarageBand) will definitely be able to take advantage.