自 2025 年 3 月 27 日起,我们建议您使用 android-latest-release
而非 aosp-main
构建 AOSP 并为其做出贡献。如需了解详情,请参阅 AOSP 的变更。
元数据和控件
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
要支持通过 Android 框架保存原始图片文件,需要具有大量有关传感器特性的元数据,包括色彩空间和镜头遮蔽功能等信息。
其中大多数信息是相机子系统的静态属性,因此可以在配置任何输出流水线或提交任何请求之前进行查询。新的相机 API 极大地扩展了 getCameraInfo()
方法提供的信息,以便将此类信息提供给应用。
此外,手动控制相机子系统需要各种设备提供的有关其当前状态的反馈,以及在捕获指定帧时使用的实际参数。必须在输出元数据中包含硬件实际使用的控件(曝光时间、帧时长和感光度)的实际值。这一点至关重要,这样应用就知道限制或舍入何时发生,并且可以补偿用于图片拍摄的实际设置。
例如,如果应用在请求中将帧时长设置为 0,HAL 必须将帧时长限制到该请求的实际最小帧时长,并在输出结果元数据中报告这一受限制的最小时长。
因此,如果应用需要实现一个自定义 3A 例程(例如,为了适当地测量 HDR 连拍),则需要知道用于捕获其收到的最新一组结果的设置,以便更新下一个请求的设置。因此,新的相机 API 会向每个捕获的帧添加大量动态元数据。这包括用于捕获的已请求参数和实际参数,以及时间戳和统计信息生成器输出等其他每帧元数据。
每个设置的控件
对于大多数设置而言,它们应该能够随着每一帧发生变化,而不会给输出帧流带来明显的卡顿或延迟。理想情况下,输出帧速率应该仅由捕获请求的帧时长字段控制,且不受处理块配置发生的任何变化影响。 实际上,我们已经知道一些特定控件发生变化的速度非常缓慢;这些控件包括相机流水线的输出分辨率和输出格式,以及影响实体设备的控件(例如镜头焦距)。稍后会详细说明每个控制集的确切要求。
原始传感器数据支持
除了旧 API 支持的像素格式之外,新 API 还添加了对原始传感器数据 (Bayer RAW) 的支持要求,既适用于高级相机应用,又支持原始图片文件。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-03-26。
[null,null,["最后更新时间 (UTC):2025-03-26。"],[],[],null,["# Metadata and controls\n\nMetadata support\n----------------\n\nTo support the saving of raw image files by the Android framework, substantial\nmetadata is required about the sensor's characteristics. This includes\ninformation such as color spaces and lens shading functions.\n\nMost of this information is a static property of the camera subsystem and can\ntherefore be queried before configuring any output pipelines or submitting any\nrequests. The new camera APIs greatly expand the information provided by the\n`getCameraInfo()` method to provide this information to the\napp.\n\nIn addition, manual control of the camera subsystem requires feedback from the\nassorted devices about their current state, and the actual parameters used in\ncapturing a given frame. The actual values of the controls (exposure time, frame\nduration, and sensitivity) as actually used by the hardware must be included in\nthe output metadata. This is essential so that apps know when either\nclamping or rounding took place, and so that the app can compensate for\nthe real settings used for image capture.\n\nFor example, if an app sets frame duration to 0 in a request, the HAL\nmust clamp the frame duration to the real minimum frame duration for that\nrequest, and report that clamped minimum duration in the output result metadata.\n\nSo if an app needs to implement a custom 3A routine (for example, to\nproperly meter for an HDR burst), it needs to know the settings used to capture\nthe latest set of results it has received to update the settings for\nthe next request. Therefore, the new camera API adds a substantial amount of\ndynamic metadata to each captured frame. This includes the requested and actual\nparameters used for the capture, as well as additional per-frame metadata such\nas timestamps and statistics generator output.\n\nPer-setting control\n-------------------\n\nFor most settings, the expectation is that they can be changed every frame,\nwithout introducing significant stutter or delay to the output frame stream.\nIdeally, the output frame rate should solely be controlled by the capture\nrequest's frame duration field, and be independent of any changes to processing\nblocks' configuration. In reality, some specific controls are known to be slow\nto change; these include the output resolution and output format of the camera\npipeline, as well as controls that affect physical devices, such as lens focus\ndistance. The exact requirements for each control set are detailed later.\n\nRaw sensor data support\n-----------------------\n\nIn addition to the pixel formats supported by\nthe old API, the new API adds a requirement for support for raw sensor data\n(Bayer RAW), both for advanced camera apps as well as to support raw\nimage files."]]