You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
133 lines
6.3 KiB
133 lines
6.3 KiB
TestingCamera2 is a test application for the Android camera2 API (android.hardware.camera2.*).
|
|
|
|
1. Overview
|
|
|
|
The goal of Testingcamera2 is to allow all API primitives and behaviors to be excercised through
|
|
a reasonable UI, and allow simple demos and test cases to be built on top of it.
|
|
|
|
The concepts the application uses match the concepts of the API itself, so any given configuration
|
|
in the application can easily be reproduced directly with the camera2 API.
|
|
|
|
2. UI concepts:
|
|
|
|
The UI is divided into two panels, organized either side-by-side (in landscape orientations) or
|
|
above each other (in portrait orientations).
|
|
|
|
The left (or above) panel generally displays output from the camera subsystem, while the right
|
|
(or below) panel generally has controls for interacting with the camera subsystem.
|
|
|
|
Each category of object in the API is configured through a pane dedicated to that category; the
|
|
panes are grouped in lists by category, and can be added, removed, or collapsed from view
|
|
arbitrarily.
|
|
|
|
The left pane contains target panes along with the app's overall log pane. The right pane contains
|
|
camera, request, burst, and utility panes.
|
|
|
|
The basic operation of the app is as follows:
|
|
|
|
1. Add a camera pane, select camera to use
|
|
2. Add at least one target pane, and for each, select the kind of target desired and its
|
|
configuration options.
|
|
3. Open and configure the camera from the camera pane
|
|
4. Add a request pane, select the desired camera and targets, and the desired use case template.
|
|
5. Start capturing images with either 'capture' (one-shot) or 'repeat' (continuous) buttons on
|
|
the request.
|
|
|
|
The application also has a set of preset configurations that can be accessed from the top-right
|
|
dropdown menu, to speed up operation.
|
|
|
|
2.1. Camera panes
|
|
|
|
The camera pane includes device-level controls for a single camera, which can be selected from all
|
|
the cameras available on the Android device. It allows for opening the device, reading out its
|
|
camera characteristics information, for configuring a set of targets, and for stopping or flushing
|
|
the camera.
|
|
|
|
2.2. Target panes
|
|
|
|
Target panes represent various destinations for camera data. The kind of destination desired, and
|
|
the camera this target is meant for, are always available to select. Each kind of destination
|
|
has its own set of controls for configuration and operation.
|
|
|
|
The pane always has a 'configure' toggle, which specifies whether that target pane will be included
|
|
in the selected camera's next configure operation. Until the target pane is included in a camera's
|
|
configuration, it cannot be used as a target for capture requests to that camera.
|
|
|
|
2.2.1. TextureView and SurfaceView targets
|
|
|
|
These are basic outputs generally used for camera preview; each is simply configured by the size
|
|
of buffers it requests from the camera.
|
|
|
|
2.2.2. ImageReader target
|
|
|
|
This is the basic still capture output, used for JPEG or uncompressed data that needs to be
|
|
application-accessible. It is simply configured with the desired output format, and the size.
|
|
|
|
2.2.3. MediaCodec and MediaRecorder targes
|
|
|
|
These are video recording targets, which use the Android device's video encoding APIs to create
|
|
video files.
|
|
|
|
2.2.4. RenderScript target
|
|
|
|
This target sends camera data to a RenderScript Allocation, from which it can be efficiently
|
|
processed by Android's RenderScript APIs.
|
|
|
|
2.3. Request panes
|
|
|
|
Request panes are used to set up the configuration for a single camera capture request. It includes
|
|
all the settings required for the camera device to capture a frame of data. It contains selectors
|
|
for the camera to send the request to, and then which of the configured target panes to use for
|
|
image output. A given request can send data to any subset of the configured targets, but it
|
|
must include at least one target.
|
|
|
|
The camera device provides default values for all the request settings for various use cases; the
|
|
starting template can be selected from the dropdown.
|
|
|
|
Once a camera has been opened and configured, and the correct target(s) has been selected for the
|
|
request, the request can be sent to the camera with either the capture or repeat buttons.
|
|
|
|
Capture is a one-shot operation, which simply instructs the camera to capture a single frame of
|
|
data. This is commonly used for high-resolution snapshots, for triggering autofocus, or other
|
|
single-occurance events. Captures are queued and processed in FIFO order.
|
|
|
|
Repeat is a continuous operation, where the camera device continually captures the images using
|
|
the same request settings. These have lower priority than captures, so if some request is actively
|
|
repeating, other requests can still use the 'capture' action to trigger single captures. Another
|
|
request triggering repeat will pre-empt any previous repeat actions by other requests.
|
|
|
|
To stop repeating, use the camera pane's stop method.
|
|
|
|
2.4. Burst panes
|
|
|
|
Burst panes simply aggregate together a set of requests into a single high-speed burst. Bursts
|
|
are captured atomically with no intervening other requests. Similarly to single requests, they
|
|
can be one-shot or continuous.
|
|
|
|
The burst pane contains the target camera to send the burst to, and then allows including one or
|
|
more requests into the burst, from the list of requests that target the chosen camera.
|
|
|
|
2.5. Utility panes
|
|
|
|
Utility panes are catchall panes, which can implement various kinds of ease-of-use functionality,
|
|
such as implementing simple autofocus operation, still capture sequencing, or other high-level
|
|
functions.
|
|
|
|
2.6. Configuration load/save
|
|
|
|
TestingCamera2 supports loading a predefined set of panes from an XML definition. The definitions
|
|
can either be one of the default included sets, or located on the device SD card.
|
|
|
|
3. Internal architecture
|
|
|
|
Each pane is a specialized view, with a few generic methods for setting them up and notifying them
|
|
of changes in other panes. Panes are tracked by a global pane tracker, which allows individual
|
|
panes to notify others of status changes (such as a change in the selected camera, so that all
|
|
panes targeting that camera pane can update their displayed settings choices), to find panes of
|
|
given types, and so on.
|
|
|
|
The operation of the camera devices is centralized in a single camera ops class, which keeps track
|
|
of open devices, notifies panes about changes to camera device status, and allows the utility panes
|
|
to intercept/override camera device operations as desired.
|
|
|