Camera - Stills and Video

For whatever reason, the Nexus line has never been synonymous with good camera quality. The Nexus One, Nexus S, and now Galaxy Nexus have shipped with 5 MP rear facing cameras, and though quality has increased with each generation, optical quality has never really been cutting edge. The Galaxy Nexus again sports a 1.3 MP front facing camera and 5 MP rear facing camera with an LED flash.

When I learned that TI had been selected as the silicon partner for Android 4.x, one of the first things that struck me was that it was highly likely they’d turn around the stigma that Nexus doesn’t care about camera quality. TI has traditionally had great ISP in their SoCs, and we’ve seen good things out of OMAP4 in the past. The fruits of that collaboration manifest themselves in a few places on the Galaxy Nexus, but the most obvious is the device’s instantaneous capture functionality.

The feature is simple - tap the camera button and you capture a full size 5 MP image of the 960x720 preview frame being displayed. No doubt, ISP is simply capturing a buffer of images constantly, and when you tap on the capture button you grab the current one. It works extremely well in practice, you can mash the button pretty fast. I recorded and measured a capture speed of ~2.7 FPS, which is pretty darn impressive for a smartphone.

Galaxy Nexus / Android 4.0.2 - Camera Capture Speed by AnandTech

There’s no preview after capture, though you can now tap the small thumbnail and get a full screen preview of the last captured image without leaving the camera app.

There are also options to quickly send the image off to some social services based on their own intents.

It’s worth talking about the sweeping positive changes that have been made to the entire Android camera UI as well. If you played the audio sample above, you’ll notice that the guillotine-sounding capture sound from Android 2.x has now been replaced with a much better tone. The rest of the UI now looks and feels accordingly less hokey. Iconography rotates immediately based on orientation, and all the menus feel fluid.

Under settings for still capture are options for flash mode, white balance, manual exposure, some shooting modes, and inside the expanded menu picture size (5MP, 3MP, 2MP, 1.3MP, VGA, QVGA) and an option for whether or not to store geolocation information. On the front facing camera you get auto white balance, exposure, scenes, and shooting sizes of 1.3 MP, VGA, and QVGA.

The capture preview also fully implements tap to focus and expose, and tracks faces around if in the scene. I noted a small change between 4.0.1 (no doubt the result of what was noted in some other reviews) - pressing and holding the capture button no longer toggles an AF/AE run, instead still image capture runs continuous auto focus just like video. To actually verify focus, your only option is tapping to focus. I feel like this does make some sense if you interpret instant capture liberally - obviously you still need to focus - but it does break the capture button paradigm that’s been established for a super long time. Just make sure you’re focused before tapping the capture button.

The other cool new feature is a panorama mode, which is now directly incorporated into the Android camera UI. Switch into this mode, and the preview window becomes smaller, but now enables you to shoot panoramas. Hit capture, and you can pan to create an image up to 3936 pixels wide by about 700 pixels tall. I created two and tossed them in our miscellaneous gallery. In this shooting mode there aren’t any options at all, but the functionality produces some pretty impressive looking results.

OMAP4's two ARM Cortex M3s

I mentioned that TI clearly worked with Google on developing both the instant capture and other ISP related features, and after a bit of poking figured out how. We’ve talked about OMAP4 before, and its dual Cortex-M3 subsystem. In OMAP4, these Cortex M3s are used for ISP related functionality (TI calls this its Imaging SubSystem - ISS), and by default both run a realtime operating system of their own that works together for still image compensation, ISP, and display subsystem control. Inside /system/vendor/firmware is a 4.5 MB file named “ducati-m3.bin” which contains many camera related references, including the names and types of what I believe are the two Samsung CMOS sensors used in the Galaxy Nexus. Regardless, this file no doubt contains the realtime OS which runs on both Cortex M3s.


And much later on, we have endless references to what can only be the two CMOS sensors used in the Galaxy Nexus - the rear facing 5 MP Samsung S5K4E1G and front facing 1.3 MP S5K6A1G. The rear facing S5K4E1G is a 1/4” front side illuminated sensor with 1.4µm pixels and a capture size of 2608 x 1960, and the front facing S5K6A1G is a 1/6” front side illuminated sensor with 1.75µm pixels and a capture size of 1280x1024. I’m pretty certain that the rear camera also is a 4P (4 plastic elements) system with a focal length of 3.37 mm, F/# of 2.8, and a diagonal field of view of 68 degrees.

Update: ChipWorks has put the Galaxy Nexus CMOS under their x-ray machine and seen S5K4E5 markings, which is the equivalent (same specs) backside-illuminated counterpart to the S5K4E1 I outlined above. Our findings were from decompiling 'ducati-m3.bin' which contains references to S5K4E1 and no references to S5K4E5, however. Given the similarities it's possible the two share the same driver platform, and hence we see this behavior inside the ISS code.

Unfortunately with specs like those it’s very apparent that having a high-end sensor and optical system wasn’t the highest of priorities. That said, the Galaxy Nexus does have some great ISP and camera features, it’s just curious that there isn’t a better 8 MP module or at least a BSI 5 MP module in the current one’s place.

So what does still image quality end up looking like? To evaluate the Galaxy Nexus’ camera, we turned to our lightbox tests with the lights on and off, outdoor testing at our test locations, and the new semi-revamped camera tests with the ISO12233, distortion, and color checker charts.

In the lightbox tests with the lights on the Galaxy Nexus honestly surprised me with very sharp high frequency features, good dynamic range, and decent white balance/saturation. There’s some sensor noise even in this well lit scene, but nothing too crazy. Though the 5 MP sensor is FSI, it does include all the CMOS features (like correlated double sampling) that are a huge part of reducing noise. For a 5 MP shooter the Galaxy Neuxs looks shockingly good in our lightbox test with the lights on.

With the lights off the Galaxy Nexus (and Android 4.0’s camera application) correctly preflash and illuminate the scene for autofocus. We get a nicely focused and exposed image in the complete dark here, though noise reduction is clearly turned all the way up and there’s some obvious blurring from noise-mitigation, but overall again not bad at all. I’m also impressed with how even the illumination is - Samsung put a nice diffuser/fresnel lens on their single LED flash.

In the more controlled testing, I think we get a sense for how good the ISP is. The GMB color checker card looks pretty decent, and in the distortion plot we see minimal distortion (though that’s really nothing special for an F/2.8 system). In the ISO 12233 chart I can see up to the 13 line in the tangential and saggital direction, and find that thankfully Google/TI didn’t subject themselves to the sharpening kernel that Samsung usually implements. On 8 MP shooters, we can obviously recover more spatial frequencies (up to the 17 line) but the Galaxy Nexus doesn’t do all that bad here.

Next up are our outdoor smartphone camera test locations, of which 3-7 remain available and refreshed each time we get a new device. Note that although I spend a lot of time trying to make sure lighting is roughly the same, seasons do change and there’s going to be some variance in here purely due to it being outside.

Performance in locations 3, 6, and 7 looks very good. In 4 and 5 I can’t shake the feeling that the Galaxy Nexus produced very undersaturated and lifeless looking images, however. There aren’t any problems with sharpness at all in any of the images, though we’re talking about a shooting environment with ample daylight lighting the scene.

I also took many miscellaneous photos with the Galaxy Nexus (both variants) and tossed them into a gallery below. In real world shooting I encountered many more poorly lit indoor environments where you can really see the noise (and noise mitigation features) kick into overdrive. The burger photo with and without flash is particularly telling, as I took this in the same position with flash on and off.

The Galaxy Nexus’ camera is definitely not the best around, but if you do a lot of outdoor shooting in good lighting environments, the Galaxy Nexus is competent enough to get the job done. It’s really only in low light scenarios indoors or at night where its CMOS sensor really shows its age and can struggle, especially if you shoot without flash. It is very confusing why the Galaxy Nexus includes such a lower-end CMOS sensor considering the device's positioning as a super high end smartphone.

That said, what is awesome are the improvements that Google has made to the AOSP camera application, which show a phenomenal amount of polish and careful thought. The new UI is a huge jump forward from the camera application in 2.x, which never felt quite right. New features like instant capture and a much better organized UI really help the shooting experience feel awesome on the Galaxy Nexus, even if it isn’t driven by the most expensive sensor in the world.


How the Galaxy Nexus captures video is the next important thing, and there are a few more awesome features here that are part of ICS.

First off, the Galaxy Nexus captures H.264 video in 1080p24 at 9.6 Mbps baseline with 1 reference frame. 720p video is captured at 30 FPS H.264 at 8 Mbps baseline. Audio is single channel AAC at 96 kbps and 48 kHz. It’s a bit odd and disappointing to see video being captured at just 24 FPS, baseline, and such a comparatively low bitrate to boot (other devices are shipping with 15-18 Mbps High Profile or 24 Mbps baseline). To date I haven’t seen any smartphone cameras capture at anything but 30 FPS, as well.

MediaInfo 1080p24 (Left), 720p30 (Right)

What’s puzzling is that OMAP4460’s encoder is capable of much more than these settings. I feel like yet again we have a Nexus that isn’t quite at parity with the video encoder quality of other devices, though this time around the device does shoot 1080p at the very least.

To gauge quality we took videos at our smartphone bench video location and shot some videos. I originally shot all my bench videos on the GSM/UMTS Galaxy Nexus running 4.0.1, and noticed some interesting behavior in the resulting video. Those are all still live, though I shot another video to highlight exactly what this behavior is and have seen some other end users note it and question what’s going on. It appears to be some overly aggressive electronic image stabilization or perhaps a rolling shutter correction firmware bug, but either way this behavior has been fixed in Android 4.0.2 and above. The videos below have been re-shot running Android 4.0.2 accordingly.

1080p24 Video Sample

720p30 Video Sample

720p30 Front Facing Video Sample

In addition, the videos have been uploaded in their original form in a big zip (136 MB) if you want to watch without YouTube’s transcode.

The 1080p video quality is decent, though you can see some encode artifacts from the lower bitrate, and honestly 24 FPS looks pretty jittery. Sharpness is decent, but the 720p sample at 30 FPS just looks better to me, and is probably the preset I’d use with the Galaxy Nexus most often as a result.

The other neat feature in video mode is of course the ability to shoot time lapse videos right in the camera UI. This is under video, not stills because the photos get merged together into a video. You can specify intervals of anywhere between 1 and 10 seconds in a few steps. In conjunction with a mount of some kind and a scene with some temporal variance, the results are actually pretty awesome.

I set up the Galaxy Nexus in a smartphone tripod mount and shot two time lapse videos - one on 10 second interval (for a sunset) and another on 1.5 second interval.


The rest of the video shooting UI is pretty similar to the one for still photography - flash settings, auto white balance, some shooting effects, video quality, and the location geotagging toggle.

I'm glad that Google fixed the annoying rolling shutter / image stabilization settings for video captured on the rear camera with 4.0.2 and above. That said, the Galaxy Nexus is still not quite up to the level of other devices with the video it's shooting on the rear side. OMAP4460 can encode 1080p video with much better efficiency and higher profile H.264 features than what it's set for right now, and I'm very puzzled why Google hasn't enabled these encode parameters which would help bump up quality. 

The SoC - TI's OMAP 4460 Display - 720p Super AMOLED HD


View All Comments

  • zorxd - Friday, January 20, 2012 - link

    They can have some differences (cache size, memory bandwidth, neon instructions) but the A9 is not an ISA. ARMv7 is.

    Given that it has the same configuration, an Apple A5 behave the same as a TI OMAP4 or a Samsung Exynos of the same clock speed. I beleive nVidia tegra2 lacks the neon instructions so can be slower in some cases. There is an article on Anandtech about this.

    Given that the iPhone 4S is only 800 MHz it is the slowest A9 CPU by far.
  • pSupaNova - Friday, January 20, 2012 - link

    The GPU's on the IPhone uses Tiling so in most GPU rendering tasks it will be a lot faster, However spit lots of Triangles at it and then see how fast it really it is. Reply
  • StormyParis - Wednesday, January 18, 2012 - link

    It's not all about performance, at least if you don't do FPS games. The screen on the Nexus is much bigger than on the 4S for example. For me, it's not about performance at all. I went for the GN for its even bigger screen, and that criteria alone was 95% of my decision, the remain 5% being "... and the rest don't suck", and "has xda-dev support'. Reply
  • humancyborg - Wednesday, January 18, 2012 - link

    Once you start accelerating the entire interface, performance becomes much more significant than just FPS games. There's a reason Apple uses such a gigantic and powerful GPU in their devices, and it's definitely not only for FPS gamers.

    Agree with you on the rest, there are other good reasons to buy this phone, just a shame that they skimped here. I have the 4S, GN and Lumia 800 currently and constantly switch around between them.
  • metafor - Wednesday, January 18, 2012 - link

    It doesn't really take a whole lot of resources to render a 2D interface. Just about any ol' GPU with OpenGL ES 2.0 support will do it.

    About the only thing where the GPU is the limiting factor is rendering 3D games. And even then, most if not the vast majority of games on the market will continue to be written for this level of hardware for at least the coming year.

    Honestly, people take benchmarks way too seriously.
  • doobydoo - Thursday, January 19, 2012 - link

    Actually, you're absolutely wrong.

    In fact, the GPU slowness is cited in this very article for causing slowdowns in situations where no 3D gaming is being done.

    Remember, the operating system as a whole is hardware accelerated, so every thing you do - animations, transitions, task switching, etc are carried out by the GPU. With the higher screen, the speed of the GPU becomes even more relevant.

    The combination of a high resolution screen and a low powered GPU is a bad combination and materially affects the performance of everything you do on the phone.
  • zorxd - Thursday, January 19, 2012 - link

    Do you remember the iPhone 4? Who complained that the GPU was slow? It was much slower than the SGX540 in the Galaxy S. Reply
  • metafor - Thursday, January 19, 2012 - link

    Speculation in an article isn't exactly proof of concept.

    Alpha blending, panning, compositing are very light tasks for a GPU pipeline; it's only a problem when a GPU is TMU-limited. And if it's TMU-limited, it would be obvious all the time.

    I don't think you quite grasp exactly what parts of UI rendering are handled -- or could be -- by the GPU and just how trivial it is compared to rendering a 3D game.
  • trob6969 - Wednesday, January 18, 2012 - link

    What i don't understand is why would samsung give the gn 1gig of ddr2 ram then give it an inferior GPU? But to be fair, Apple is no better. Why give iphone 4s a powerful GPU then give it only 512 mb of ram?! My old-ass og moto droid from over 2yrs. ago had that much! Reply
  • doobydoo - Thursday, January 19, 2012 - link

    As alluded to by numerous posters, including one in this comments section, iOS handles memory usage more efficiently than Android so it doesn't suffer any performance penalty as a result of having less RAM. Reply

Log in

Don't have an account? Sign up now