Android Camera Quality: objectively assessing those happy snaps

It can be debated that the camera is one of the most used features of a smartphone, and thus one of the most important. It’s no wonder too – the inclusion of a small and convenient camera subsystem in the everyday phone has created more opportunities for capturing those quick snaps that wind up on Facebook, your wallpaper, or in the family album. Wherever it ends up though, no one wants the blurry photo of Sasquatch, or even something that was missed entirely (some of the device’s we’ve seen are so slow, they’d only capture an empty track during the 100m sprint!).

While imaging sensors and lenses in smartphones have come a long way since the days of non-autofocus VGA shooters, even the best snappers struggle to match the performance of a basic pocket point and shoot camera. At Apkudo, via our Apkudo Device Analytics product, we deeply assess the user experience of pre-launch Android devices for most OEMs worldwide (we have over 6 pre-launch devices in our lab just this week!). It’s a lot of fun, and interestingly, by a reasonable margin, the most common user experience issues we discover are camera related –  ranging from low shutter speeds, to distortion effects, to poor color accuracy, and beyond.

One reason for this massive variation in camera quality is the fact that phone cameras are really only marketed by their megapixel rating, something that is a flawed metric in itself. Only recently have some OEMs tried to improve on this by touting a zero shutter-delay on their ICS devices, particularly as it is a highlight feature of ICS.

However, this is only a small aspect of the user experience relating to camera response and image quality. Many manufacturers advertise that their camera is really awesome, or it is excellent at low light, or captures images with vivid and stunning colors. Unfortunately, there is no metric to gauge this claim by, or to compare with one another. Is my camera that takes “Lifelike images with stunning realism” better than that one which does “incredible color and vividness”, or that other one which tells me it has “superb camera quality”?

It comes as no surprise that these claims mean little when it comes time for a user to decide which phone camera will best satisfy their needs.

So how can this be situation be improved? Standards! In particular, standards whereby various metrics of phone camera can be objectively compared, just like they are with professional DSLR’s.

And that is why I’m currently 36,000ft in the air, writing this blog on the way to the first meeting of IEEE P1858™ – the Draft Standard for Camera Phone Image Quality (CPIQ) working group. Apkudo has joined specifically to take part in setting a standard for camera phone image quality.

And what can Apkudo offer in this area? Simple. We have assessed every Android device that’s ever been released. The amount of data we’ve collected is immense – thousands of data points on metrics such as shutter lag, shot-to-shot latency, sharpness across the image, color accuracy and saturation, vignetting, time to first shot, color temperature – the list goes on. We’re currently using that data to assist OEMs and Operators to improve their pre-launch devices, and we intend on now using it to help the ecosystem at large.

Here’s a very small sampling of that data to whet your appetite:

Sharpness Graph

Here we’re  looking at a bit of sharpness at some points across a sample image. MTF50 can be correlated to perceived image sharpness, whereas overshoot corresponds well with post-process sharpening techniques by increasing perceived contrast between edges. Obviously having an overly low MTF50 will result in blurry images. However, what it doesn’t show is artificially introduced sharpness. This is where the overshoot measure helps. The HTC Desire VC has a good sharpness by MTF50 measure on first glance, but take a closer look, and it’s over sharpening is through the roof. And this,  leads to a common ‘halo’ effect affecting all edges.

HTC Desire VC with halo effect.

Samsung Galaxy Nexus.

On the other hand, the Galaxy Nexus seems to have a lower perceived sharpness. However, it has very little post processing applied, so it’s doing pretty well without much assistance.

A few more metrics:

Shutter lag, color, and Imatest results.

Here we’re looking at some camera delay tests, some camera saturation accuracy and distortion, and Imatest results. It’s fairly interesting that the One S is just about twice as quick at firing up that camera app than the other devices, including other ICS devices and the Galaxy Nexus rocking some Android Jelly Bean action.

Shot-to-shot is always an interesting one, and there seems to be two clear groups of performers. Ones that take more than a second per image, and ones that take less than half a second. Granted some of these devices have a burst mode that speeds things up a little, but we reckon that if you’re in a hurry to take a few quick pics in succession, you’re not going to have time to find that burst mode anyway.

We found the shutter lag to be pretty good on these phones, given that most of them are at least Android 4.0 (and so featuring that zero shutter lag perk). Interestingly though, the Motorola Droid 4 we analyzed is still running Gingerbread, yet keeps up with its younger brethren.

Below, we can see how each device handles color reproduction, saturation and even just to the naked eye, exposure. Some phones have a tendency to over expose, whereas some tend to underexpose. Others, like the Samsung SGS3, seem to get this just right. Color temperature is also exposed to the naked eye through the bottom row of grey patches. Of course this is all going to be dependant on the viewing monitor, but assuming it’s calibrated, the Ascend D1 and Desire VC both show a fairly warm tint, whereas the Droid 4 is hitting the other end of the scale with cool temperatures. Some of the complex analysis is handled by the excellent software produced by Imatest, which provides accurate and reproducible data that is invaluable to the classification and assessment of a phone camera.

Samsung Galaxy S3

HTC One S

Samsung/Google Galaxy Nexus

Huawei Ascend D1

HTC Desire VC

HTC One X

Motorola Droid 4

The results we’ve presented just begin to scratch the surface of the camera analysis we do here at Apkudo. Analyzing so many devices for OEMs and Operators affords us the opportunity to provide lots of insight and actionable recommendations as to why a camera might perform poorly and what can be done to fix it. When we saw that the IEEE would be putting together a working group to create a standard for methods and metrics to judge camera phone image quality, we knew we’d have a lot to offer. We are a company whose mission is to optimize the Android user experience – not just for OEMs, Operators, and developers – but for everyone. We believe we can help lead the charge in creating this industry standard to reach the end goal of a better user experience. For everyone.

—
Benjamin Tseng | Director of Device Analytics
Apkudo Inc.
+1 443 453 3172
+61 422 387 773

Run Google Play on an emulator and pretend to be any device

Since the beginning of time man has sought to virtualize the human experience. We go to sleep and have life-like experiences in our dreams, we connect to internet sites like Chatroulette to virtually meet strangers (and inadvertently catch a glimpse of some old man balls from time to time), 1995 brought us the classic Denzel Washington/Russell Crowe sci-fi action thriller Virtuosity, and nerds gather in herds online to play StarCraft (myself included) and become virtual intergalactic heroes. The journey to virtualize reality has been a long time coming. The next logical step… to run Google Play on a virtual mobile device? “Of course!” said no one.

Alas, our journey continues. Our odyssey starts with the awesome blog post “Installing Google Play on Android Emulator.” The author, Piotr Buda, was able to successfully install the Google Play application on an emulator. However, you’ll notice that in the comments and subsequent blog post he (and his readers) were unable to download and install applications: the effects of the dastardly Error 491. Additionally, the applications they were able to view were severely limited. After reading both posts, the Apkudo team attempted to take it a step further and a) get downloads working and b) be able to browse and download any app.

Installing Google Play on an Android emulator requires three separate APKs: GoogleLoginService.apk, GoogleServicesFramework.apk, and Phonesky.apk (older versions will be named ‘Vending.apk’.) All three are located in the /system/app/ folder on your device. You can issue an adb pull command to pull each one off of your device (you generally don’t need root to pull). We pulled ours off of a Samsung Galaxy S III (the version of the store that we pulled was 3.5.16)

Next we just push the three APKs to install on the emulator (we made a simple modification to the shell script from the original blog post):

#!/bin/sh
echo "remounting..."
adb remount
echo "pushing login apk..."
adb push GoogleLoginService.apk /system/app/.
echo "pushing framework apk..."
adb push GoogleServicesFramework.apk /system/app/.
echo "pushing vending apk..."
adb push Phonesky.apk /system/app/.
echo "done"

Once the three APKs are installed, it is trivial to get the market executing. You’ll need to enter your account information when prompted and accept the market update if required (the update will generally not be successful, but it doesn’t seem to matter). You should now be able to browse and search the Play Store. Except, of course, you’ll usually hit an Error 491 when you try to download!

Solving Error 491

If you have created your AVD for ICS or earlier you will undoubtedly encounter Error 491 when attempting to download an application. The reason is that a shared object file, libdrmframework_jni.so is missing from the /system/lib/ folder. You may also find that the DrmProvider.odex and DrmProvider.apk files are missing from the /system/app/ folder. It seems that standard Android AVD images do not include these files. In order to circumvent this, you can build the Android platform from source (see http://source.android.com/source/initializing.html); your AVDs should now include the relevant DRM files. (Note: pulling the .so off of your device and pushing them to the emulator will generally not work.) You can also, of course, just create an AVD for 4.1 Jelly Bean: AVDs that target 4.1 appear to include those missing files and should be able to download applications easily.

Google Play on an emulator.

Move along, not too many apps to see here!

Downloading Solitaire. Side note: I’m pretty good at Solitaire.

Circumventing Google Play Filters

As you browse the Play Store you’ll notice a startling lack of available applications. The Google Play Store filters the apps that you can view based on a handful of factors relating to hardware, software, and carrier. You can find most filters listed here: http://developer.android.com/guide/google/play/filters.html

Depending on which features you give your AVD, you will see a variety of available apps. However, you’ll still be unable to view a great deal of what the store has to offer simply because your AVD lacks a great many features. Therefore, we’ll need to get our hands dirty with the innards of the Google Play code (this could probably be accomplished in a few other ways, but this was the most practical.)

The basic idea is to capture and mock all of the device identifying information and metadata that Play compiles before it is sent off on the wire. You’ll first need to unzip each APK: unzip {apk} -d {out_dir}. Then, remove the META-INF folder within each (we’ll re-sign each APK later.) Use baksmali on the classes.dex of both Phonesky.apk and GoogleServicesFramework.apk. Now you’ll have access to the smali code for each APK.

Inside the  decompiled GoogleServicesFramework you’ll find a file entitled /com/google/android/gsf/checkin/CheckinRequestBuilder.smali. Poke around a bit, and you’ll notice that it contains a host of device identifying information, all of which we must intercept and mock. Inside the decompiled Phonesky you’ll find two files entitled /com/google/android/finsky/utils/DeviceConfigurationHelper.smali and /com/google/android/finsky/utils/VendingUtils.smali respectively. Again, each file contains device identifying information that Google Play will eventually serialize, send off into the cloud, and use to filter the apps that you can view on the store.

So now that we know what data is being sent, how do we intercept it and mock it?  First, you’re going to need data to mock. This is relativley simple, as you can pull most of that information from a real phone using some combination of adb shell getprop, adb shell pm, and adb shell dumpsys. On the other hand, you can build a simple application that pulls all of this data and dumps it out in a neat little file. The next step is to build a framework for mocking data. I built a java class composed entirely of static methods (it is very easy to hand insert into smali code (with some register finagling)) that I compiled and then decompiled back into smali. Inside each of the decompiled Google APKs, make the appropriate directories for your classes package, and copy over the smali file. You should now be able to call any of your static methods from Google code.

Now its a matter of using grep to find the right method calls in the files mentioned above. For each method found, comment it out, and insert your own, mocked method call.  For example, in DeviceConfigurationHelper.smaliI’ve replaced the call

invoke-virtual {v4}, Landroid/content/pm/PackageManager;->getSystemAvailableFeatures()[Landroid/content/pm/FeatureInfo;

with a call to my own getSystemAvailableFeatures() method. Finally, you’ll need to use smali to re-compile all of the code back into a classes.dex file (replace the old ones in Phonesky and GoogleServicesFramework respectively), re-zip into each into an apk (including GoogleLoginService), and re-sign each using jarsigner. Push them onto the emulator as always and you should be good to go.

Play thinks we’re a Galaxy Nexus!

Downloading Angry Birds Space.

Playing our downloaded app on the emulator!

For now, you can only download and install free apps. As you might imagine, getting paid apps on an emulator is a bit trickier. We’ll save that for a later post.

Happy hacking,

-Daniel Joyce, Software Engineer

You may wish to reference the following:
Smali and Baksmali
Android Api
Google Play Filters