Posts tagged ‘Ice Cream Sandwich’
Regional carrier Cincinnati Bell was faced with a problem: Customers were returning too many Android devices, and operating costs were slowly rising as a result.
With smartphone penetration moving past the mass market and into the laggard category, many are getting their first taste of smartphones on free and lower-power Android devices, and they’re not thrilled. The core reason for customer device returns at Cincinnati Bell was poor user experience.
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
Hear ye, hear ye, fellow tech nerds! The glorious Consumer Electronics Show is upon us and you know what that means, right? A crop of new Android phones! But with the bountiful harvest of these snazzy new gadgets comes…dun dun dun…fragmentation!
Ah, fragmentation. The Android application developers mortal coil. Different UIs from different OEMs, divergence in hardware, look and feel, behavior, APIs, etc, etc, we developers need a hero. Enter Ice Cream Sandwich. While ICS is a step in the right direction for fragmentation in some respects (e.g. unifying Honeycomb and Gingerbread), there are some ways it makes things a bit harder:
Screen Resolutions
The launch of ICS coincided with the new Galaxy Nexus touting an unprecedented 1280 x 720 display compared to the ‘ordinary’ 800 x 480 displays of the past. Plucked against Gingerbread, ICS also brings along a new method of reporting screen resolutions and adds a new kick with on-screen ‘hardware’ keys for phones. On devices without dedicated hardware keys, a portion of the screen is allocated to providing on-screen hardware keys, thus slightly altering the remaining available display region. Previous methods to report the screen resolution, display.getWidth/getHeight have been deprecated and replaced by display.getSize.
These differences may lead to complications with unusual object placement/layouts and simple incompatibilities. For example, the popular 3rd party keyboard, ‘Swype’ is problematic on the Galaxy Nexus with a message explaining an unsupported screen resolution. A temporary solution has been discovered by users by modifying the config file, ‘display0_SwypeScreen.ini’ to suit the appropriate screen size.
Menus
For devices without physical hardware keys, ICS programmatically displays a virtual menu key depending if the application requires it. A new ‘Action Bar’ has been brought over from Android 3.0 which is included if the activity uses the Theme.Halo theme – which is the default theme if either the targetSdkVersion or minSdkVersion is set to 11 or greater. In the presence of the action bar, a menu key will appear typically near the top right of the display. In absence, a menu key appears among the row of soft keys to the bottom of the display. However, even between standard Google applications like Gmail, Calendar, Maps, Gallery, Market, etc, which make use of the new Action Bar, the location of the virtual menu key varies making the user search around for three little dots.
In addition to the differences in the virtual menu key’s location, the operation of the menu key can occasionally be problematic. In certain apps such as Gravity Guy, Guerrilla Bob, and Market Enabler, a virtual menu key appears at the bottom next to the row of soft keys, yet it doesn’t serve any purpose. Pressing the menu key yields no response leading the user to think something has gone awry. Similarly before being updated, the popular application ‘Facebook for Android’ did not have any menu key appear at all despite the undoubted existence of a menu page.
Hardware Acceleration
As the display resolutions of Android mobile devices reach PC levels (many 13″ laptops are only at 1280 x 800), the demand for offloading screen rendering to the GPU is ever more important especially when a fluid 60fps experience is desired. ICS incorporates the level of hardware acceleration that existed with Android 3.0. Dianne Hackborn from Google:
“The implementation [of hardware acceleration] in Android 4.0 is not any more full than in 3.0… The main change in this regard in Android 4.0 is that now apps that are explicitly targeting 4.0 or higher will have acceleration enabled by default rather than having to put android:hardwareAccelerated=”true” in their manifest.”
This similarity brings forth drawbacks for developers who may want to use hardware acceleration. A number of operations such as Canvas.clipPath, Canvas.drawPicture and Paint.setLinearText are not supported by hardware acceleration at the moment. Tiny Towers crashes with logcat citing ‘E/AndroidRuntime(20581): java.lang.
UnsupportedOperationException at android.view.GLES20Canvas.clipPath’ when GPU acceleration is forced. Whilst this may be a non-issue for Bob and Jane, developers may find it difficult and frustrating to have to re-develop their application to take advantage of hardware acceleration in order to improve user experience. In the case of new applications, a dilemma may arise between using a certain operation but not being able to gain hardware acceleration, against a possibly less favorable operation but able to be accelerated.
New API’s
Often with a major OS release comes a number of new additions. In the case of Android 4.0, one of these is a new set of documented APIs for accessing Calendar data. However, as this was only released with Android 4.0, a number of developers had previously developed their applications using old undocumented Calendar APIs, some of which use low-level access to the calendar database.
As mentioned here http://android-developers.blogspot.com/2011/10/ics-and-non-public-apis.html, some developers may find that their apps won’t run correctly on ICS without some updates being made. Applications such as SMS Backup+ were initially broken after ICS first released owing to a change in Calendar APIs, with recent specific changes just made in order to have Calendar features working once more. https://github.com/jberkel/sms-backup-plus/pull/206. It is without a doubt that these new API’s ease the task for future apps and developers, but in the mean time in order to support older releases, a bit of extra work needs to be done.
With all new OS version and device releases, there’s going to be some good and some bad. Google is trying to steer the Android ship away from fragmentation by offering a common base for all mobile devices and providing more official APIs for developers to use. However, changes need to be made. As developers we can’t rest on our laurels and wait for Google to figure it out, and we definitely can’t wait around for every OEM to push ICS updates for every Android model – some of the most popular devices may not even get it. We need to write code and then it to make sure it actually works on real devices. Unless everyone starts churning out code according to the books and the professors who jabbered on about ‘tightly coupled code’, certain things are going to break one way or another.
If only there were a way to see my app run on all of these devices so I could know with confidence that it works…oh, wait.
-Benjamin Tseng
Apkudo Engineer
apkudo 