Reputation: 720
Android recently announced native Camera API which according to them is equivalent to the Java android.hardware.camera2
class. When should we consider using the NDK / C++ API ? Are there any performance improvements if we use the C++ code -- like preprocessing the frames? Do they Native API let you insert code that can be as part of of the HAL3 pipeline, for instance image processing/ computer vision code?
Upvotes: 6
Views: 6879
Reputation: 18137
The API is primarily there to be used by applications that don't have much of a Java component, for simplicity of implementation.
The performance may be slightly better for use cases where an app was just passing the camera image buffers via JNI into native code anyway, but the overhead of accessing direct ByteBuffers from Java android.media.Image objects is not very high. But setting up a bunch of Java code to do that may be annoying; for example, OpenCV could use the NDK directly in their Android camera wrappers, instead of the private (not guaranteed to be stable) native interfaces OpenCV has used in the past.
It's also there to be used as a stable interface for other native system components to get camera data, mostly for various OEM extensions.
The NDK API provides no more control over the actual image processing pipeline than the Java one.
The primary drawback is that unlike the Java API, the NDK API only supports LIMITED or better camera devices; there's no compatibility support for LEGACY devices. It also doesn't yet support reprocessing, which is less often used for the kinds of continuous processing applications where the NDK API makes more sense.
Upvotes: 7