When android.control.awbMode is not OFF, TRANSFORM_MATRIX should be ignored.

This matrix is either set by HAL when the request android.colorCorrection.mode is not TRANSFORM_MATRIX, or directly by the application in the request when the android.colorCorrection.mode is TRANSFORM_MATRIX.

In the latter case, the HAL may round the matrix to account for precision issues; the final rounded matrix should be reported back in this matrix result metadata.

The 4-channel white-balance gains are defined in the order of [R G_even G_odd B], where G_even is the gain for green pixels on even rows of the output, and G_odd is the gain for greenpixels on the odd rows. if a HAL does not support a separate gain for even/odd green channels, it should use the G_even value,and write G_odd equal to G_even in the output result metadata.

This array is either set by HAL when the request android.colorCorrection.mode is not TRANSFORM_MATRIX, or directly by the application in the request when the android.colorCorrection.mode is TRANSFORM_MATRIX.

The ouput should be the gains actually applied by the HAL to the current frame.

This matrix is either set by HAL when the request android.colorCorrection.mode is not TRANSFORM_MATRIX, or directly by the application in the request when the android.colorCorrection.mode is TRANSFORM_MATRIX.

In the latter case, the HAL may round the matrix to account for precision issues; the final rounded matrix should be reported back in this matrix result metadata.

The 4-channel white-balance gains are defined in the order of [R G_even G_odd B], where G_even is the gain for green pixels on even rows of the output, and G_odd is the gain for greenpixels on the odd rows. if a HAL does not support a separate gain for even/odd green channels, it should use the G_even value,and write G_odd equal to G_even in the output result metadata.

This array is either set by HAL when the request android.colorCorrection.mode is not TRANSFORM_MATRIX, or directly by the application in the request when the android.colorCorrection.mode is TRANSFORM_MATRIX.

The ouput should be the gains actually applied by the HAL to the current frame.

For example, if EV step is 0.333, '6' will mean an exposure compensation of +2 EV; -3 will mean an exposure compensation of -1

Note that even when AE is locked, the flash may be fired if the AE mode is ON_AUTO_FLASH / ON_ALWAYS_FLASH / ON_AUTO_FLASH_REDEYE.

Only effective if android.control.mode = AUTO.

If auto-exposure is active, HAL auto-focus routine is enabled, then HAL auto-exposure routine overrides the control variables that relate to auto-exposure routine, and these override values are then available in the result metadata for that capture.

For example, if auto-exposure is enabled in a request, the HAL should overwrite the exposure, gain, and frame duration fields (and potentially the flash fields, depending on AE mode) of the request. The overridden values are then provided back to the user in the corresponding result.

Each area is a rectangle plus weight: xmin, ymin, xmax, ymax, weight. The rectangle is defined inclusive of the specified coordinates.

The coordinate system is based on the active pixel array, with (0,0) being the top-left pixel in the active pixel array, and (android.sensor.info.activeArraySize.width - 1, android.sensor.info.activeArraySize.height - 1) being the bottom-right pixel in the active pixel array. The weight should be nonnegative.

If all regions have 0 weight, then no specific metering area needs to be used by the HAL. If the metering region is outside the current android.scaler.cropRegion, the HAL should ignore the sections outside the region and output the used sections in the frame metadata

Only constrains AE algorithm, not manual control of android.sensor.exposureTime

This entry is normally set to IDLE, or is not included at all in the request settings. When included and set to START, the HAL must trigger the autoexposure precapture metering sequence.

The effect of AE precapture trigger depends on the current AE mode and state; see the camera HAL device v3 header for details.

Only effective if android.control.mode = AUTO.

If lens is controlled by HAL auto-focus algorithm, the HAL should report the current AF status in android.control.afState in result metadata.

Each area is a rectangle plus weight: xmin, ymin, xmax, ymax, weight. The rectangle is defined inclusive of the specified coordinates.

The coordinate system is based on the active pixel array, with (0,0) being the top-left pixel in the active pixel array, and (android.sensor.info.activeArraySize.width - 1, android.sensor.info.activeArraySize.height - 1) being the bottom-right pixel in the active pixel array. The weight should be nonnegative.

If all regions have 0 weight, then no specific focus area needs to be used by the HAL. If the focusing region is outside the current android.scaler.cropRegion, the HAL should ignore the sections outside the region and output the used sections in the frame metadata

This entry is normally set to IDLE, or is not included at all in the request settings.

When included and set to START, the HAL must trigger the autofocus algorithm. The effect of AF trigger depends on the current AF mode and state; see the camera HAL device v3 header for details. When set to CANCEL, the HAL must cancel any active trigger, and return to initial AF state.

Note that AWB lock is only meaningful for AUTO mode; in other modes, AWB is already fixed to a specific setting

[BC - AWB lock,AWB modes]

Only effective if android.control.mode = AUTO.

Only used in AUTO mode.

Each area is a rectangle plus weight: xmin, ymin, xmax, ymax, weight. The rectangle is defined inclusive of the specified coordinates.

The coordinate system is based on the active pixel array, with (0,0) being the top-left pixel in the active pixel array, and (android.sensor.info.activeArraySize.width - 1, android.sensor.info.activeArraySize.height - 1) being the bottom-right pixel in the active pixel array. The weight should be nonnegative.

If all regions have 0 weight, then no specific metering area needs to be used by the HAL. If the metering region is outside the current android.scaler.cropRegion, the HAL should ignore the sections outside the region and output the used sections in the frame metadata

Only used if android.control.mode != OFF.

High-level 3A control. When set to OFF, all 3A control by the HAL is disabled. The application must set the fields for capture parameters itself.

When set to AUTO, the individual algorithm controls in android.control.* are in effect, such as android.control.afMode.

When set to USE_SCENE_MODE, the individual controls in android.control.* are mostly disabled, and the HAL implements one of the scene mode settings (such as ACTION, SUNSET, or PARTY) as it wishes. The HAL scene mode 3A settings are provided by android.control.sceneModeOverrides.

If enabled, video stabilization can modify the android.scaler.cropRegion to keep the video stream stabilized

When a scene mode is enabled, the HAL is expected to override aeMode, awbMode, and afMode with its preferred settings for that scene mode.

To simplify communication with old camera API applications, the service wants this override list in the static metadata. The order of this list matches that of availableSceneModes, with 3 entires for each scene mode. The overrides listed for SCENE_MODE_FACE_PRIORITY are ignored, since for that mode, the application-set aeMode, awbMode, and afMode are used instead, like they are when android.control.mode is AUTO.

It is recommended that for FACE_PRIORITY, the overrides should be set to 0. As an example, if availableSceneModes is { FACE_PRIORITY, ACTION, NIGHT }, then the service expects this field to have 9 entries; for example { 0 , 0, 0, ON_AUTO_FLASH, AUTO, CONTINUOUS_PICTURE, ON_AUTO_FLASH, INCANDESCENT, AUTO }

Must be 0 if no CAMERA2_TRIGGER_PRECAPTURE_METERING trigger received yet by HAL. Always updated even if AE algorithm ignores the trigger

Each area is a rectangle plus weight: xmin, ymin, xmax, ymax, weight. The rectangle is defined inclusive of the specified coordinates.

The coordinate system is based on the active pixel array, with (0,0) being the top-left pixel in the active pixel array, and (android.sensor.info.activeArraySize.width - 1, android.sensor.info.activeArraySize.height - 1) being the bottom-right pixel in the active pixel array. The weight should be nonnegative.

If all regions have 0 weight, then no specific metering area needs to be used by the HAL. If the metering region is outside the current android.scaler.cropRegion, the HAL should ignore the sections outside the region and output the used sections in the frame metadata

Whenever the AE algorithm state changes, a MSG_AUTOEXPOSURE notification must be send if a notification callback is registered.

Only effective if android.control.mode = AUTO.

If lens is controlled by HAL auto-focus algorithm, the HAL should report the current AF status in android.control.afState in result metadata.

Each area is a rectangle plus weight: xmin, ymin, xmax, ymax, weight. The rectangle is defined inclusive of the specified coordinates.

The coordinate system is based on the active pixel array, with (0,0) being the top-left pixel in the active pixel array, and (android.sensor.info.activeArraySize.width - 1, android.sensor.info.activeArraySize.height - 1) being the bottom-right pixel in the active pixel array. The weight should be nonnegative.

If all regions have 0 weight, then no specific focus area needs to be used by the HAL. If the focusing region is outside the current android.scaler.cropRegion, the HAL should ignore the sections outside the region and output the used sections in the frame metadata

Whenever the AF algorithm state changes, a MSG_AUTOFOCUS notification must be send if a notification callback is registered.

Must be 0 if no CAMERA2_TRIGGER_AUTOFOCUS trigger received yet by HAL. Always updated even if AF algorithm ignores the trigger

[BC - AWB lock,AWB modes]

Only effective if android.control.mode = AUTO.

Only used in AUTO mode.

Each area is a rectangle plus weight: xmin, ymin, xmax, ymax, weight. The rectangle is defined inclusive of the specified coordinates.

The coordinate system is based on the active pixel array, with (0,0) being the top-left pixel in the active pixel array, and (android.sensor.info.activeArraySize.width - 1, android.sensor.info.activeArraySize.height - 1) being the bottom-right pixel in the active pixel array. The weight should be nonnegative.

If all regions have 0 weight, then no specific metering area needs to be used by the HAL. If the metering region is outside the current android.scaler.cropRegion, the HAL should ignore the sections outside the region and output the used sections in the frame metadata

Whenever the AWB algorithm state changes, a MSG_AUTOWHITEBALANCE notification must be send if a notification callback is registered.

High-level 3A control. When set to OFF, all 3A control by the HAL is disabled. The application must set the fields for capture parameters itself.

When set to AUTO, the individual algorithm controls in android.control.* are in effect, such as android.control.afMode.

When set to USE_SCENE_MODE, the individual controls in android.control.* are mostly disabled, and the HAL implements one of the scene mode settings (such as ACTION, SUNSET, or PARTY) as it wishes. The HAL scene mode 3A settings are provided by android.control.sceneModeOverrides.

Edge/sharpness/detail enhancement. OFF means no enhancement will be applied by the HAL.

FAST/HIGH_QUALITY both mean HAL-determined enhancement will be applied. HIGH_QUALITY mode indicates that the HAL should use the highest-quality enhancement algorithms, even if it slows down capture rate. FAST means the HAL should not slow down capture rate when applying edge enhancement.

Edge/sharpness/detail enhancement. OFF means no enhancement will be applied by the HAL.

FAST/HIGH_QUALITY both mean HAL-determined enhancement will be applied. HIGH_QUALITY mode indicates that the HAL should use the highest-quality enhancement algorithms, even if it slows down capture rate. FAST means the HAL should not slow down capture rate when applying edge enhancement.

Power for snapshot may use a different scale than for torch mode. Only one entry for torch mode will be used

Clamped to (0, exposure time - flash duration).

If no flash, none of the flash controls do anything. All other metadata should return 0

1 second too long/too short for recharge? Should this be power-dependent?

Power for snapshot may use a different scale than for torch mode. Only one entry for torch mode will be used

Clamped to (0, exposure time - flash duration).

85-95 is typical usage range

When set to (0, 0) value, the JPEG EXIF must not contain thumbnail, but the captured JPEG must still be a valid image.

When a jpeg image capture is issued, the thumbnail size selected should have the same aspect ratio as the jpeg image.

Below condiditions must be satisfied for this size list:

• The sizes must be sorted by increasing pixel area (width x height). If several resolutions have the same area, they must be sorted by increasing width.
• The aspect ratio of the largest thumbnail size must be same as the aspect ratio of largest size in android.scaler.availableJpegSizes. The largest size is defined as the size that has the largest pixel area in a given size list.
• Each size in android.scaler.availableJpegSizes must have at least one corresponding size that has the same aspect ratio in availableThumbnailSizes, and vice versa.
• All non (0, 0) sizes must have non-zero widths and heights.

This is used for sizing the gralloc buffers for JPEG

85-95 is typical usage range

If no JPEG output is produced for the request, this must be 0.

Otherwise, this describes the real size of the compressed JPEG image placed in the output stream. More specifically, if android.jpeg.maxSize = 1000000, and a specific capture has android.jpeg.size = 500000, then the output buffer from the JPEG stream will be 1000000 bytes, of which the first 500000 make up the real data.

When set to (0, 0) value, the JPEG EXIF must not contain thumbnail, but the captured JPEG must still be a valid image.

When a jpeg image capture is issued, the thumbnail size selected should have the same aspect ratio as the jpeg image.

Will not be supported on most devices. Can only pick from supported list

Will not be supported on most devices. Can only pick from supported list

Will not be supported on most devices.

0 = infinity focus. Used value should be clamped to (0,minimum focus distance)

Will not be supported on most devices.

If variable aperture not available, only setting should be for the fixed aperture

If not available, only setting is 0. Otherwise, lists the available exposure index values for dimming (2 would mean the filter is set to reduce incoming light by two stops)

If optical zoom not supported, only one value should be reported

[DNG wants a function instead]. What's easiest for implementers? With an array size (M, N), entry (i, j) provides the destination for pixel (i/(M-1) * width, j/(N-1) * height). Data is row-major, with each array entry being ( (X, Y)_r, (X, Y)_g, (X, Y)_b ) )

The hyperfocal distance is used for the old API's 'fixed' setting

If the lens is fixed-focus, this should be 0

The map should be on the order of 30-40 rows and columns, and must be smaller than 64x64.

Examples:

(0,0) means that the camera optical axis is perpendicular to the display surface;

(45,0) means that the camera points 45 degrees up when device is held upright;

(45,90) means the camera points 45 degrees to the right when the device is held upright.

Use FACING field to determine perpendicular outgoing direction

Will not be supported on most devices. Can only pick from supported list

Will not be supported on most devices. Can only pick from supported list

Will not be supported on most devices.

Should be zero for fixed-focus cameras

If variable focus not supported, can still report fixed depth of field range

Will not be supported on most devices.

Noise filtering control. OFF means no noise reduction will be applied by the HAL.

FAST/HIGH_QUALITY both mean HAL-determined noise filtering will be applied. HIGH_QUALITY mode indicates that the HAL should use the highest-quality noise filtering algorithms, even if it slows down capture rate. FAST means the HAL should not slow down capture rate when applying noise filtering.

Noise filtering control. OFF means no noise reduction will be applied by the HAL.

FAST/HIGH_QUALITY both mean HAL-determined noise filtering will be applied. HIGH_QUALITY mode indicates that the HAL should use the highest-quality noise filtering algorithms, even if it slows down capture rate. FAST means the HAL should not slow down capture rate when applying noise filtering.

Normalized coordinates refer to those in the (-1000,1000) range mentioned in the android.hardware.Camera API.

HAL implementations should instead always use and emit sensor array-relative coordinates for all region data. Does not need to be listed in static metadata. Support will be removed in future versions of camera service.

HAL implementations should implement AF trigger modes for AUTO, MACRO, CONTINUOUS_FOCUS, and CONTINUOUS_PICTURE modes instead of using this flag. Does not need to be listed in static metadata. Support will be removed in future versions of camera service

HAL implementations should use gralloc usage flags to determine that a stream will be used for zero-shutter-lag, instead of relying on an explicit format setting. Does not need to be listed in static metadata. Support will be removed in future versions of camera service.

Does not need to be listed in static metadata. Support for partial results will be reworked in future versions of camera service. This quirk will stop working at that point; DO NOT USE without careful consideration of future support.

The entries in the result metadata buffers for a single capture may not overlap, except for this entry. The FINAL buffers must retain FIFO ordering relative to the requests that generate them, so the FINAL buffer for frame 3 must always be sent to the framework after the FINAL buffer for frame 2, and before the FINAL buffer for frame 4. PARTIAL buffers may be returned in any order relative to other frames, but all PARTIAL buffers for a given capture must arrive before the FINAL buffer for that capture. This entry may only be used by the HAL if quirks.usePartialResult is set to 1.

Only meaningful when android.request.type == REPROCESS. Ignored otherwise

If no output streams are listed, then the image data should simply be discarded. The image data must still be captured for metadata and statistics production, and the lens and flash must operate as requested.

Video snapshot with preview callbacks requires 3 processed streams (preview, record, app callbacks) and one JPEG stream (snapshot)

Reset on release()

If no output streams are listed, then the image data should simply be discarded. The image data must still be captured for metadata and statistics production, and the lens and flash must operate as requested.

Any additional per-stream cropping must be done to maximize the final pixel area of the stream.

For example, if the crop region is set to a 4:3 aspect ratio, then 4:3 streams should use the exact crop region. 16:9 streams should further crop vertically (letterbox).

Conversely, if the crop region is set to a 16:9, then 4:3 outputs should crop horizontally (pillarbox), and 16:9 streams should match exactly. These additional crops must be centered within the crop region.

The output streams must maintain square pixels at all times, no matter what the relative aspect ratios of the crop region and the stream are. Negative values for corner are allowed for raw output if full pixel array is larger than active pixel array. Width and height may be rounded to nearest larger supportable width, especially for raw output, where only a few fixed scales may be possible. The width and height of the crop region cannot be set to be smaller than floor( activeArraySize.width / android.scaler.maxDigitalZoom ) and floor( activeArraySize.height / android.scaler.maxDigitalZoom), respectively.

When multiple streams are configured, the minimum frame duration will be >= max(individual stream min durations)

When multiple streams are configured, the minimum frame duration will be >= max(individual stream min durations)

The actual supported resolution list may be limited by consumer end points for different use cases. For example, for recording use case, the largest supported resolution may be limited by max supported size from encoder, for preview use case, the largest supported resolution may be limited by max resolution SurfaceTexture/SurfaceView can support.

When multiple streams are configured, the minimum frame duration will be >= max(individual stream min durations)

Any additional per-stream cropping must be done to maximize the final pixel area of the stream.

For example, if the crop region is set to a 4:3 aspect ratio, then 4:3 streams should use the exact crop region. 16:9 streams should further crop vertically (letterbox).

Conversely, if the crop region is set to a 16:9, then 4:3 outputs should crop horizontally (pillarbox), and 16:9 streams should match exactly. These additional crops must be centered within the crop region.

The output streams must maintain square pixels at all times, no matter what the relative aspect ratios of the crop region and the stream are. Negative values for corner are allowed for raw output if full pixel array is larger than active pixel array. Width and height may be rounded to nearest larger supportable width, especially for raw output, where only a few fixed scales may be possible. The width and height of the crop region cannot be set to be smaller than floor( activeArraySize.width / android.scaler.maxDigitalZoom ) and floor( activeArraySize.height / android.scaler.maxDigitalZoom), respectively.

1/10000 - 30 sec range. No bulb mode

Exposure time has priority, so duration is set to max(duration, exposure time + overhead)

ISO 12232:2006 REI method

Minimum duration is a function of resolution, processing settings. See android.scaler.availableProcessedMinDurations android.scaler.availableJpegMinDurations android.scaler.availableRawMinDurations

Needed for FOV calculation for old API

Maximum output resolution for raw format must match this in android.scaler.info.availableSizesPerFormat

Defines sensor bit depth (10-14 bits is expected)

As per DNG BlackLevelRepeatDim / BlackLevel tags

Use as follows XYZ = inv(transform) * clip( (raw - black level(raw) ) / ( white level - max black level) ). At least in the simple case

For android.sensor.sensitivity values less than or equal to this, all applied gain must be analog. For values above this, it can be a mix of analog and digital

A represents sensor read noise before analog amplification; B represents noise from A/D conversion and other circuits after amplification. Both noise sources are assumed to be gaussian, independent, and not to vary across the sensor

[EXIF LightSource tag] Must all these be supported? Need CCT for each!

1/10000 - 30 sec range. No bulb mode

Exposure time has priority, so duration is set to max(duration, exposure time + overhead)

ISO 12232:2006 REI method

Monotonic, should be synced to other timestamps in system

Whether face detection is enabled, and whether it should output just the basic fields or the full set of fields. Value must be one of the android.statistics.info.availableFaceDetectModes.

When set to ON, android.statistics.lensShadingMap must be provided in the output result metadata.

OFF means face detection is disabled, it must be included in the list.

SIMPLE means the device supports the android.statistics.faceRectangles and android.statistics.faceScores outputs.

FULL means the device additionally supports the android.statistics.faceIds and android.statistics.faceLandmarks outputs.

Whether face detection is enabled, and whether it should output just the basic fields or the full set of fields. Value must be one of the android.statistics.info.availableFaceDetectModes.

Only available if faceDetectMode == FULL

Only available if faceDetectMode == FULL

Only available if faceDetectMode != OFF

Only available if faceDetectMode != OFF. The value should be meaningful (for example, setting 100 at all times is illegal).

The k'th bucket (0-based) covers the input range (with w = android.sensor.info.whiteLevel) of [ k * w/N, (k + 1) * w / N ). If only a monochrome sharpness map is supported, all channels should have the same data

If only a monochrome sharpness map is supported, all channels should have the same data

The least shaded section of the image should have a gain factor of 1; all other sections should have gains above 1.

When android.colorCorrection.mode = TRANSFORM_MATRIX, the map must take into account the colorCorrection settings.

The shading map is for the entire active pixel array, and is not affected by the crop region specified in the request. Each shading map entry is the value of the shading compensation map over a specific pixel on the sensor. Specifically, with a (N x M) resolution shading map, and an active pixel array size (W x H), shading map entry (x,y) ϵ (0 ... N-1, 0 ... M-1) is the value of the shading map at pixel ( ((W-1)/(N-1)) * x, ((H-1)/(M-1)) * y) for the four color channels. The map is assumed to be bilinearly interpolated between the sample points.

The channel order is [R, Geven, Godd, B], where Geven is the green channel for the even rows of a Bayer pattern, and Godd is the odd rows. The shading map is stored in a fully interleaved format, and its size is provided in the camera static metadata by android.lens.info.shadingMapSize.

The shading map should have on the order of 30-40 rows and columns, and must be smaller than 64x64.

As an example, given a very small map defined as:

android.lens.info.shadingMapSize = [ 4, 3 ]
android.statistics.lensShadingMap =
[ 1.3, 1.2, 1.15, 1.2,  1.2, 1.2, 1.15, 1.2,
    1.1, 1.2, 1.2, 1.2,  1.3, 1.2, 1.3, 1.3,
  1.2, 1.2, 1.25, 1.1,  1.1, 1.1, 1.1, 1.0,
    1.0, 1.0, 1.0, 1.0,  1.2, 1.3, 1.25, 1.2,
  1.3, 1.2, 1.2, 1.3,   1.2, 1.15, 1.1, 1.2,
    1.2, 1.1, 1.0, 1.2,  1.3, 1.15, 1.2, 1.3 ]

The low-resolution scaling map images for each channel are (displayed using nearest-neighbor interpolation):

As a visualization only, inverting the full-color map to recover an image of a gray wall (using bicubic interpolation for visual quality) as captured by the sensor gives:

This may be different than the gains used for this frame, since statistics processing on data from a new frame typically completes after the transform has already been applied to that frame.

The 4 channel gains are defined in Bayer domain, see android.colorCorrection.gains for details.

This value should always be calculated by the AWB block, regardless of the android.control.* current values.

The HAL must provide the estimate from its statistics unit on the white balance transforms to use for the next frame. These are the values the HAL believes are the best fit for the current output frame. This may be different than the transform used for this frame, since statistics processing on data from a new frame typically completes after the transform has already been applied to that frame.

These estimates must be provided for all frames, even if capture settings and color transforms are set by the application.

This value should always be calculated by the AWB block, regardless of the android.control.* current values.

Report NONE if there doesn't appear to be flickering illumination

Tonemapping / contrast / gamma curve for the blue channel, to use when android.tonemap.mode is CONTRAST_CURVE.

See android.tonemap.curveRed for more details.

Tonemapping / contrast / gamma curve for the green channel, to use when android.tonemap.mode is CONTRAST_CURVE.

See android.tonemap.curveRed for more details.

Tonemapping / contrast / gamma curve for the red channel, to use when android.tonemap.mode is CONTRAST_CURVE.

Since the input and output ranges may vary depending on the camera pipeline, the input and output pixel values are represented by normalized floating-point values between 0 and 1, with 0 == black and 1 == white.

The curve should be linearly interpolated between the defined points. The points will be listed in increasing order of P_IN. For example, if the array is: [0.0, 0.0, 0.3, 0.5, 1.0, 1.0], then the input->output mapping for a few sample points would be: 0 -> 0, 0.15 -> 0.25, 0.3 -> 0.5, 0.5 -> 0.64

Tonemapping / contrast / gamma curve for the blue channel, to use when android.tonemap.mode is CONTRAST_CURVE.

See android.tonemap.curveRed for more details.

Tonemapping / contrast / gamma curve for the green channel, to use when android.tonemap.mode is CONTRAST_CURVE.

See android.tonemap.curveRed for more details.

Tonemapping / contrast / gamma curve for the red channel, to use when android.tonemap.mode is CONTRAST_CURVE.

Since the input and output ranges may vary depending on the camera pipeline, the input and output pixel values are represented by normalized floating-point values between 0 and 1, with 0 == black and 1 == white.

The curve should be linearly interpolated between the defined points. The points will be listed in increasing order of P_IN. For example, if the array is: [0.0, 0.0, 0.3, 0.5, 1.0, 1.0], then the input->output mapping for a few sample points would be: 0 -> 0, 0.15 -> 0.25, 0.3 -> 0.5, 0.5 -> 0.64

When set to ON, the values used for black-level compensation must not change until the lock is set to OFF

Since changes to certain capture parameters (such as exposure time) may require resetting of black level compensation, the HAL must report whether setting the black level lock was successful in the output result metadata.

For example, if a sequence of requests is as follows:

• Request 1: Exposure = 10ms, Black level lock = OFF
• Request 2: Exposure = 10ms, Black level lock = ON
• Request 3: Exposure = 10ms, Black level lock = ON
• Request 4: Exposure = 20ms, Black level lock = ON
• Request 5: Exposure = 20ms, Black level lock = ON
• Request 6: Exposure = 20ms, Black level lock = ON

And the exposure change in Request 4 requires resetting the black level offsets, then the output result metadata is expected to be:

• Result 1: Exposure = 10ms, Black level lock = OFF
• Result 2: Exposure = 10ms, Black level lock = ON
• Result 3: Exposure = 10ms, Black level lock = ON
• Result 4: Exposure = 20ms, Black level lock = OFF
• Result 5: Exposure = 20ms, Black level lock = ON
• Result 6: Exposure = 20ms, Black level lock = ON

This indicates to the application that on frame 4, black levels were reset due to exposure value changes, and pixel values may not be consistent across captures.

The black level locking must happen at the sensor, and not at the ISP. If for some reason black level locking is no longer legal (for example, the analog gain has changed, which forces black levels to be recalculated), then the HAL is free to override this request (and it must report 'OFF' when this does happen) until the next time locking is legal again.

Whether the black level offset was locked for this frame. Should be ON if android.blackLevel.lock was ON in the capture request, unless a change in capture settings forced a black level reset.