Camera Architecture

When it comes to generational camera improvements, the device it makes the most sense to compare the ZenFone 2 to is the ZenFone 5. Unfortunately, I don't have information about the exact sensor that was used in the ZenFone 5. On a basic level, ASUS has moved from an 8MP sensor to a 13MP one, while maintaining the same F/2.0 aperture. The rear camera flash has also been upgraded from a single LED to a dual LED "Real Tone" flash. The spec table below should provide some perspective on the technical aspects of the ZenFone 2's camera system.

ASUS ZenFone 2 Cameras
Front Camera - Resolution 5MP (2560x1920)
Front Camera - Sensor OmniVision OV5670
(1.12µm, 1/5")
Front Camera - Focal Length 3.3mm
Front Camera - Max Aperture F/2.0
Rear Camera - Resolution 13MP (4096x3072)
Rear Camera - Sensor Toshiba T4K37 (1.12µm, 1/3.07")
Rear Camera - Focal Length 3.8mm (28m eff)
Rear Camera - Max Aperture F/2.0

The ZenFone 2 is the only device I know of to use Toshiba's T4K37 sensor. This is a sister sensor of the T4KA7 used in the HTC One (M9), which has the same pixel size but a higher 20.7MP resolution and thus a larger sensor. However, the sensor is just one part of the optical system, and I wouldn't draw any conclusions about the ZenFone 2's camera quality based on another phone that uses a similar sensor.

ASUS is using a fairly fast aperture of F/2.0 for both the front and back sensors. While this allows for more light to be collected, it can also cause visible aberration in photos and alters the depth of field in photographs. Unfortunately, there's no OIS on the rear-facing camera to compensate for hand shake which could enable longer exposures. What I find interesting is that ASUS never pushes the camera beyond a shutter speed of 1/12s and never exceeds an ISO of 1600. I had thought the max ISO might be a bit higher in the darkest of scenes.

Now that the hardware of the camera system is out of the way, I want to touch on the auto-focus and capture latency on the ZenFone 2. This is a best case test where the camera is pointed at a bright and high contrast target, and so the results for capture time and auto-focus time will vary depending on the lighting of the scene. In particular, the longer exposure times in low light will cause a significant increase in capture latency.

Camera Focus Latency (Shooting ISO 12233 Target)Camera Shot Latency (Shooting ISO 12233 Target)

In the focus latency test, the ZenFone 2 ends up being the slowest device on the chart. It's around the same speed as the HTC One (M9) but this is likely due to a lack of PDAF/laser AF and similar troubles with ISP rather than anything related to the camera sensor itself. Shot latency is also fairly long, but not the worst result we've seen. Prior to a recent update, the shot latency was an extremely long 2.4 seconds, and so the current result is a significant improvement over my first tests. It's still very long though, and it's something I would attribute to the ISP that is used, as the ZenFone is in no danger of running out of free RAM to use as a buffer for photos which rules out issues with NAND write speeds.

Camera UX

The camera application on a smartphone can have an enormous impact on the shooting experience. The application needs to have a well designed layout for the controls, which can be a difficult balance between exposing too many things on the screen and hiding too many options in layers upon layers of menus. Equally important is making sure that the preview has a high frame rate so the user can see how stable the camera is, as well as a high resolution and an accurate aspect ratio so photos can be framed and composed properly. Using a camera can be a frustrating experience when any of these aspects are handled poorly, and it can lead to a potential photo opportunity being missed as the user fights with the camera application.

The camera interface on the ZenFone 2 is fairly well designed, but there are a few things that the user needs to tweak before they begin using it. The most important part is the photo resolution setting. By default, the camera is set to take cropped 10MP 16:9 photos. Given that the camera is a 4:3 13MP sensor, the only reason I can explain the default setting is that it means there's no switch in preview size between taking photos and shooting video. In any case, I immediately changed the setting to 13MP, and all the photos in the review were taken in that configuration. Another setting I enabled was touch auto exposure, which is just something I personally prefer to have enabled.

As for the auto mode interface, it has a good balance of exposing necessary controls and hiding more seldom used ones. On the right side there are buttons to take photos and shoot video, as well as a button in the bottom right which allows you to change between the various shooting modes. Another button may dynamically appear in the bottom left depending on your shooting conditions, and it may tell you to change to various other shooting modes to improve photo quality. In this case, it's recommending to use the low light mode because the preview is very dark.

The gear on the left side of the display opens up the settings menu. This menu is basically a very long list of options, so I'm glad that Asus thought to put shortcuts on the top that can bring you right to a specific group of settings that pertain to a certain shooting mode. You'll also notice that even though we're using auto mode, this menu can be used to force certain settings like the exposure bias, the ISO, and the white balance. There are also some additional settings for sharpness, contrast, saturation, etc. I don't really see the value of these options outside of a manual mode, as a good auto mode should be capable of determining the best values for these settings on its own.

The last part of the camera UI that I want to discuss is the manual mode. I think ASUS actually has one of the better implemented manual camera modes that I've seen on a smartphone, although it's not without its issues. As you can see above, the manual mode comes with a histogram and a gradienter. These are nice features for users who will need them, and ASUS gives you the ability to turn them off which I have done for both of them as I find them distracting when trying to compose photos. You'll also notice that in this mode the photo and video shooting modes are split into two sections that you access via a slider, rather than having both buttons on the screen at the same time. This is because the video mode is locked to 30 frames per second and so the shutter speed controls have to be removed from the menu.

To adjust settings like shutter speed, ISO, white balance, etc, you simply tap on the blue slider button in the top right. This brings up a menu with two columns, where the different settings are stacked in the right column, and the values for those settings are in the left column. I like this design because it's easy to use with a single finger on the right side of the device, and when it's closed you can still see the values you've chosen in the top left of the camera preview.

My one big issue with ASUS's manual controls is that the steps between possible values are not very fine. For example, you can see above that your options for ISO are limited to values that double in size as you go up the scale. While many professional DSLRs and mirrorless cameras also don't offer the ability to select any desired ISO value, they have a large range of values that you can select. For example, where the ZenFone 2 goes from 100 to 200 ISO, my camera has 125 and 160 in between. There are also apps for iOS and Android that allow you to select any value for the ISO. What also bothers me is that the range of ISO values stops at 800, while the auto mode will push ISO as high as 1600 in low light. The shutter speed is also capped at 1/500 seconds, which is much longer than some of the shutter speeds the phone will use in good lighting.

Since ASUS can push updates to their apps via Google Play, I'm hopeful that they will improve on this with a future camera update. They already have a solid interface and a good set of features, and there's just a few things that they haven't gotten quite right yet.

NAND Memory Performance Still Image Performance
Comments Locked

147 Comments

View All Comments

  • der - Tuesday, May 26, 2015 - link

    Sweet review mates. Y'all the best!
  • Daniel Egger - Tuesday, May 26, 2015 - link

    Two things:
    1) The x86 problems are very real; about any serious Android application contains native code for performance reasons, the rest are very non-demanding gimmicks or simple games. There're still plenty of application which do not even attempt to run on x86 which can be easily seen by e.g. checking the F-Droid repository with the app. And of those which do run quite a few simply don't work correctly; I've found quite a few of those in the Humble Bundles. My suspicion is that the developers do compile them for x86 but do not really test them on that platform...
    2) Those Silvermont cores do have decent performance but I've yet to see a single implementation where battery life doesn't suck. One discovery I've made is that those devices are very reluctant to go into deep sleep, even with some tweaking they'll usually stay on the lowest possible frequency most of the time. Could be that the software is not quite ready to properly handle those Intel cores or they simply suck...
  • MikhailT - Tuesday, May 26, 2015 - link

    Both are software issues. Google doesn't have any incentives to stick with ARM only, they'd want to work with Intel to fix these issues.

    At my work, we had an issue where our app would crash on Intel devices, it took us a few weeks to figure out that it was a low-level bug in Android. We filed a bug report but no news if Google or Intel will fix it. We managed to work around it but it was difficult and took a lot of time.

    The latest rumors is that Android M is supposed to work on the battery issues. Hopefully, that includes optimization for Intel SoCs.
  • kpb321 - Tuesday, May 26, 2015 - link

    I was surprised that the review seemed to skip this entirely. It is certainly an issue when dealing with x86 android phones. Theoretically any app that doesn't include NDK "should" work fine on x86. My experience with Android phones/tablets was that I don't ever recall installing a single app that had NDK in the permissions list so it didn't seem like it was very common to me. On the other hand I've never actually had an intel tablet to actually see how good or bad it was.
  • Brandon Chester - Tuesday, May 26, 2015 - link

    I also reviewed the Venue 8, and like I said in both this review and that review, I have never found a single app that doesn't work because the SoC is x86. A lot of people like to say that there are lots of apps that have issues, but they never seem to name any so there's no way for me to actually confirm that. If people do know of some problematic apps please let me know via email or Twitter so I can take a look.
  • Muyoso - Tuesday, May 26, 2015 - link

    An app called Photo direct that I use for work crashes instantly when launched.
  • rocketbuddha - Wednesday, May 27, 2015 - link

    I bought a Dell Venue 8 with KitKat
    http://www.bestbuy.com/site/dell-venue-8-8-intel-a...
    and found that it was the POS.
    Dunno if it was 1GB RAM that came with it, but it was hanging even while opening tabs in chrome/stock browser.

    With Lollipop, Google officially has both a ARM as well as x86 version it tests and releases. Pre-lollipop it was Intel who customized Android to work with its Atom processors.
  • Maleficum - Saturday, May 30, 2015 - link

    Brandon, you'd be really surprised to know that most apps in the top charts are using NDK.

    Google claims that 85% apps are written in Java. I'm not saying it's a lie, but it is far from realistic since most apps in the top charts - apps most people use most of their time - are NDK based.

    Even more surprising would be the fact that roughly half of these apps contain ARM binaries only, thus forced to run via binary translation that results in a performance reduction of roughly 70% while the power consupmtion doubles.

    In that sense, your article is misleading IMHO, simply repeating Google's claims.

    http://www.theregister.co.uk/2014/05/02/arm_test_r...

    I think it's clear why so many apps are NDK based: Java isn't simply the right language for computationally intensive apps, and primitive apps written in Java cannot make it into the top charts.

    And app developers aren't interested much in supporting x86 natively considering the tiny market share. No one can blame them for neglecting x86.

    That's the reason why I'd never buy nor recommend x86 Android phones, and Intel having difficulties getting foothold in mobile segment.

    I think it would be worth an investigation and probably a separate article.
  • Thunderc8 - Saturday, May 30, 2015 - link

    I have installed all known apps and then some and all working perfect and super fast. If what you say is true then Intel CPU is a beast since it looses so much performance and at the same time is so Damn fast.
  • coolied - Wednesday, May 27, 2015 - link

    NDK wouldn't be in the permissions list, it simply means the app was coded in C++ and not JAVA. Unfortunately, most apps you would WANT to run and run WELL are written in C++ aka most 3D games.

Log in

Don't have an account? Sign up now