自 2025 年 3 月 27 日起,我們建議您使用 android-latest-release
而非 aosp-main
建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
中繼資料和控制項
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
為了支援 Android 架構儲存原始圖片檔案,您必須提供大量關於感應器特性的中繼資料。這類資訊包括色彩空間和鏡頭陰影功能。
這些資訊大多是相機子系統的靜態屬性,因此可以在設定任何輸出管道或提交任何要求之前查詢。新的相機 API 可大幅擴充 getCameraInfo()
方法提供的資訊,並將這項資訊提供給應用程式。
此外,手動控制相機子系統時,需要各種裝置提供的目前狀態回饋,以及在擷取特定影格時使用的實際參數。硬體實際使用的控件實際值 (曝光時間、影格持續時間和感度) 必須納入輸出中繼資料。這項資訊非常重要,可讓應用程式瞭解何時發生了夾取或捨入,並補償用於擷取圖片的實際設定。
舉例來說,如果應用程式在要求中將影格持續時間設為 0,HAL 就必須將影格持續時間限制在該要求的實際影格持續時間下限,並在輸出結果中繼資料中回報該限制的持續時間下限。
因此,如果應用程式需要導入自訂的 3A 例行程序 (例如,為 HDR 連拍功能正確測量),就必須瞭解用於擷取收到的最新結果集的設定,以便更新下次要求的設定。因此,新的相機 API 會在每個擷取的畫面中加入大量動態中繼資料。這包括用於擷取的請求和實際參數,以及額外的個別影格中繼資料,例如時間戳記和統計資料產生器輸出內容。
個別設定控制
對於大多數設定,我們希望您可以在每個影格中變更設定,而不會對輸出影格串流造成明顯的卡頓或延遲。理想情況下,輸出影格速率應由擷取要求的影格時間長度欄位單獨控制,且不受處理區塊設定的任何變更影響。實際上,某些特定控制項的變更速度較慢,包括相機管道的輸出解析度和輸出格式,以及影響實體裝置的控制項 (例如鏡頭對焦距離)。稍後會詳細說明各控制組的確切規定。
支援原始感應器資料
除了舊版 API 支援的像素格式之外,新版 API 還新增了支援原始感應器資料 (Bayer RAW) 的需求,以便支援進階相機應用程式,以及原始圖片檔案。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間:2025-03-26 (世界標準時間)。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["缺少我需要的資訊","missingTheInformationINeed","thumb-down"],["過於複雜/步驟過多","tooComplicatedTooManySteps","thumb-down"],["過時","outOfDate","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["示例/程式碼問題","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間: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."]]