For those that have followed the state of camera software in AOSP and Google Camera in general, it’s been quite clear that this portion of the experience has been a major stumbling block for Android. Third party camera applications are almost always worse for options and camera experience than first party ones. Manual controls effectively didn’t exist because the underlying camera API simply didn’t support any of this. Until recently, the official Android camera API has only supported three distinct modes. These modes were preview, still image capture, and video recording. Within these modes, capabilities were similarly limited. It wasn’t possible to do burst image capture in photo mode or take photos while in video mode. Manual controls were effectively nonexistent as well. Even something as simple as tap to focus wasn’t supported through Android’s camera API until ICS (4.0). In response to these issues, Android OEMs and silicon vendors filled the gap in capabilities with custom, undocumented camera APIs. While this opened up the ability to deliver much better camera experiences, these APIs were only usable in the OEM’s camera applications. If there were no manual controls, there was no way for users to get a camera application that had manual controls.

With Android L, this will change. Fundamentally, the key to understanding this new API is understanding that there are no longer distinct modes to work with. Photos, videos, and previews are all processed in the same exact way. This opens up a great deal of possibility, but also means more work on the part of the developer to do things correctly. Now, instead of sending capture requests in a given mode with global settings, individual requests for image capture are sent to a request queue and are processed with specific settings for each request.

This sounds simple enough, but the implications are enormous. First, image capture is much faster. Before, if the settings for an image changed the entire imaging pipeline would have to clear out before another image could be taken. This is because any image that entered the pipeline would have settings changed while processing, which means that the settings would be inconsistent and incorrect. This slowed things down greatly because of this wait period after each change to capture settings. With the new API, you simply request captures with specific settings (device dependent) so there’s no need to wait on the pipeline with settings changes. This dramatically increases the maximum capture rate regardless of the format used. In other words, the old API set changes globally. This slowed down image capture every time image settings changed because all of the images in the pipeline had to be discarded once the settings were changed. In the new API, settings are done on a per-image basis. This means that no discarding has to happen, which means image capture stays fast.

The second implication is that the end user will have much more control over the settings that they can use. These have been discussed before in the context of iOS 8’s manual camera controls, but in effect it’s now possible to control shutter speed, ISO, focus, flash, white balance manually, along with options to control exposure level bias, exposure metering algorithms, and also select the capture format. This means that the images can be output as JPEG, YUV, RAW/DNG, or any other format that is supported.

While not an implication, the elimination of distinction between photo and video is crucial. Because these distinctions are removed, it’s now possible to do burst shots, full resolution photos while capturing lower resolution video, and HDR video. In addition, because the pipeline gives all of the information on the camera state for each image, Lytro-style image refocusing is doable, as are depth maps for post-processing effects. Google specifically cited HDR+ in the Nexus 5 as an example of what’s possible with the new Android camera APIs.

This new camera API will be officially released in Android L, and it’s already usable on the Android L preview for the Nexus 5. While there are currently no third party applications that take advantage of this API, there is a great deal of potential to make camera applications that greatly improve upon OEM camera applications. However, the most critical point to take away is that the new camera API will open up the possibility for applications that no one has thought of yet. While there are still issues with the Android camera ecosystem, with the release of Android L software won’t be one of them.

POST A COMMENT

32 Comments

View All Comments

  • Filiprino - Sunday, July 20, 2014 - link

    The possiblity of shooting RAW is a big improvement. The JPEG process removes a lot of detail. Reply
  • Rockmandash12 - Sunday, July 20, 2014 - link

    About time..

    Also, I'm curious; would these APIs be able to make an app that doesn't use the dedicated imaging chip on the HTC One M7? The purple haze issue is due to an overhearing dedicated imaging chip, and if you could process images without using that chip, shouldn't it fix the purple haze issue?
    Reply
  • TerdFerguson - Sunday, July 20, 2014 - link

    Add a global way to disable the camera, or I don't care. Reply
  • shabby - Sunday, July 20, 2014 - link

    Where does google plan to store all these raw files? Surely not in its meager 16/32gb phones does it? Give us back our sdcards google! Reply
  • Filiprino - Sunday, July 20, 2014 - link

    Only in your dreams you will see Google backing SD Card storage. Reply
  • shabby - Sunday, July 20, 2014 - link

    Well the only other solution is 64/128gb storage options. Because the cloud doesn't work with raw images and possibly 4k video. Reply
  • Mayuyu - Sunday, July 20, 2014 - link

    On the cloud of course. We also all have unlimited data plans and there aren't any places in the world without 3g connectivity. Reply
  • soccerballtux - Tuesday, July 22, 2014 - link

    the latency is horrendous. Takes 5 seconds just to load, when if it were on the phone itself it would be instant. Reply
  • Milind - Thursday, October 30, 2014 - link

    You missed the sarcasm. Reply
  • edzieba - Monday, July 21, 2014 - link

    "Lytro-style image refocusing is doable"

    To be pedantic: you could do focus-stacking with multiple exposures, you might even be able to infer a depth map (or add an additional depth-sensing imager) and use a hyperfocal lens to reestimate focus in software, but you cannot magically turn a single-lens-assembly focal plane camera into a light-field camera (e.g. Lytro).
    Reply

Log in

Don't have an account? Sign up now