Still Image Performance

After discussing the general architecture and the software experience of the camera on the ZenFone 2, we're ready to take a look at how it actually performs when taking photos in the real world. Since the world is very diverse, a camera needs to be able to adapt to various conditions. Lighting may not always be optimal, and if a scene has a significant amount of movement then driving long shutter speeds with the help of OIS in order to keep ISO down no longer becomes a viable option.

The first test I'm doing is an outdoor test during the day. There's ample lighting from the sun, and the scene has a variety of objects and surfaces that can be examined to see how well detail is resolved by the ZenFone 2 in optimal shooting conditions.

Looking at the overall image, it's clear to me that this sensor is capable of taking good photos. Unfortunately, there are a lot of issues related to the processing that ASUS is doing that really bring down the image quality. Not limited to this scene is the camera's tendency to oversaturate colors, as well as some very heavy sharpening that causes white and black borders on the edges of objects. Despite being taken at the base ISO of 50 and a shutter speed of 1/1135 seconds, there's still noise in the blue parts of the sky, which doesn't happen on any of the other devices in the comparison.

ZenFone 2 on the left, Nexus 6 on the right

Above is a 100% crop of the bicycle in the distance from the ZenFone 2 and Nexus 6 photos. I chose the Nexus 6 to compare to because it has the same resolution and pixel size. As you can see, in the ZenFone 2 photo there's a black border around the frame of the bike as well as the rings of the bike rack. There's also more noise on the concrete road in the background, and just an overall lower level of detail in areas like the grass and the second bike rack further in the background.

Some of the issues that I've mentioned are the result of the "Optimization" setting in the camera menu. This setting is set to auto by default, and it changes the amount of sharpening and noise reduction done during processing, as well as other aspects like contrast and color saturation. Turning this setting off makes some noticeable changes to the appearance of images, but not all of them are positive.


Above you can change between a 100% crop of an image taken with ASUS's optimization set to auto, and one where it is set to off. It's clear that when optimization is turned off the issues with heavy noise and dark edges caused by sharpening are eliminated. However, the image is also considerably softer, and no matter how hard I tried I could not get the leaves and flowers to appear as sharp and in focus when optimization was off as when it was set to auto. ASUS also gives you the option to manually set these values. While I'm sure you could spend your time tweaking them to get an optimal balance, that completely defeats the point having a camera mode where everything is automatic. Ultimately ASUS has to improve their algorithms and processing for shooting in auto mode.

The next test uses the same seen as the first test, but it is done at night where lighting is scarce and only provided by a handful of lamps on the road and on the sides of some of the buildings. Most smartphones now produce usable images with good lighting, and so low light performance has really become the area where a device needs to excel in order to be considered among the best smartphone cameras.

Relative to the other smartphones I'm comparing it to, the ZenFone 2's photo quality at night actually ends up being pretty good. Both it and the two Nexus devices didn't expose for the sky very well, but the ZenFone 2 is much brighter in the rest of the scene. It also has more detail on the pavement than the Nexus 6, but it also has more noise throughout the image. I think it actually outperformed the iPhone 5s overall as well, with a much more accurate white balance, and more detail on fine objects such as the bicycle and bike racks in the distance.

The black borders caused by ASUS's sharpening during processing are definitely still visible in areas where objects are in the light, but it's much less distracting when the scene is already very dark in general. Overall, I would actually rank the ZenFone 2 somewhere between the Nexus 6 and Galaxy S6 Edge in this scene, with the S6 Edge being the overall best of the photos despite being somewhat overexposed.

Special Camera Modes

In addition to the standard auto and manual modes, ASUS offers a variety of camera modes for special circumstances. There are ones like beautification mode and HDR, which I don't really care for that much. I'm actually shocked that there's no auto HDR in the automatic mode to begin with. However, there are two camera modes that I'd like to talk about because of how prominent they are in ASUS's marketing for the ZenFone 2 and its "PixelMaster" camera.

The first mode that I'd like to examine is the Super Resolution mode. This camera mode merges together the details of four slightly shifted images to produce a much higher resolution image. ASUS claims the images are up to 52MP in resolution, which is four times the native resolution of the sensor. In practice, my image was slightly over 50MP which is pretty close to what ASUS claimed.

Because of the immense size of the 50MP photo I was unable to include it in a gallery. You can view the super resolution photo here, and the normal resolution photo here. I recommend taking a look at them scaled to a reasonable size and seeing if you can notice any notable differences in sharpness.

Upscaled Normal Resolution on the left, Super Resolution on the right

The above photos compare a crop from the normal resolution photo taken using the auto mode and the photo from the Super Resolution mode. I've enlarged the normal resolution photo to 2x in order to make the crops the same size. While this has an impact on the quality of the normal photo, the point I'm trying to make is preserved because there's really no visible improvement in sharpness from using the Super Resolution mode that I can see even after blowing up the original image. There's definitely a visible reduction in noise throughout the frame, but it's not noise that you'll be able to see during normal viewing anyway, and a denoising filter in a photo editing application could achieve a similar effect. In the end I don't really think that the Super Resolution mode is very useful.

The second camera mode that I wanted to talk about is the low light mode. Some users may be familiar with this type of mode from other smartphones and from digital cameras. Essentially what the camera is doing in the low light mode is merging adjacent pixels together in order to combine their luminances. This is known as pixel binning, and at the sensor level this is done by combining charges on the CCD/CMOS sensor. For our purposes, it's easier to just discuss the end product which is a significantly improved signal to noise ratio (SNR) at the expense of spatial resolution. A commonly used form of pixel binning in cameras is 2x2 binning, where the light of four pixels is essentially combined into one pixel. This would confirm ASUS's claimed 400% increase in sensitivity when using the low light mode.

The downside is, of course, the lower spatial resolution. The use of 2x2 pixel binning and EIS during low light mode means that the resolution of the images is limited to 3MP. This means that it's only worth using this mode in circumstances where it's dark enough that you won't be able to see the subject of the photo properly in the normal camera mode. I've taken a couple of comparison images to see how well this feature works.


I chose this first scene because it doesn't have any lighting within the frame. I'll explain why that is in a moment, but for now lets discuss what improvements the low light mode makes in this scene. The most obvious improvement is that the scene is much brighter. The original photo is so dark that you can't even tell there are trees and power lines in the background. The bins are also very hard to make out, and only show up because of their white labels. You would also never know that on the right side of the frame there is part of another car being shown. In the image taken using the low light mode, all of these parts of the image are clearly visible and recognizable.

The obvious downside to the low light image is a loss in resolution. While the auto mode image is very dark, there's clearly more detail on the ground, as well as on the features of the cars that are bright enough to be seen such as the tires of the silver car on the left side, and the license plate of the car on the right. In the low light mode there's a lot of smearing and blur in those areas, and the noise throughout the image is not as fine grained.


In this second scene I've deliberately chosen an area where there's a light source visible in the scene. This puts less of a strain on the auto mode so we can see how low light mode improves over auto mode photos that actually aren't that bad. It also highlights some of the limitations of pixel binning.

In this case, the low light mode is again much brighter than the auto mode photo. However, while the low light mode pulls parts of the scene like the trees and the sky out of the shadows, the difference in quality between it and the auto mode photo is very noticeable and makes it difficult to choose which of the shots has more redeeming qualities. The blurring throughout the low light image scrubs away essentially all of the details. The cars are not as sharp, and the details of the bricks on the house are completely lost. The inclusion of a light source in the scene presents another problem. Since the camera is basically exposing for the darkest part of the scene, the light is completely over exposed and distracts from the other parts of the photo.

In this case, it's hard to say that the low light mode photo is certainly the better one, as it's not as hard to see the objects in the photo as it was in the first test case. You trade much of the detail to obtain a better exposure, and while that may still give the low light mode the edge here, in any case where there's even a bit more lighting I would probably opt for the normal auto mode or manual mode. In general, my recommendation would be to only use the low light mode when it's so dark that you won't be able to see what the subject of the photo even is with the normal camera modes.

My overall verdict on the ZenFone 2's camera quality is somewhat mixed. It actually did fairly well in the night time test, but during the day the image quality was negatively impacted by ASUS's processing. The sharpening causes white and black halos around objects, the images had a much higher level of blurriness than I would expect from a shot with a sub 1ms shutter speed, and at base ISO there was visible noise in the sky that I can't even begin to explain. I would love if some of these problems could be fixed in a potential software update, because I think that they are going to show up in the majority of circumstances where users will be taking photos. At present, these processing issues really cripple an aspect of the ZenFone 2 that I believe could be optimized to perform much better than it currently does.

Camera Architecture and UX Video 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