Auf Geräten mit Android 13 und höher unterstützt Android die 10‑Bit-Kameraausgabe über Profile für den dynamischen Bereich, die vom Kameraclient im Rahmen der Streamkonfiguration konfiguriert werden können. Gerätehersteller können Unterstützung für 10‑Bit-Profile mit dynamischem Bereich wie HLG10, HDR 10, HDR 10+ und Dolby Vision hinzufügen.
Durch die Unterstützung der 10‑Bit-Kameraausgabe können Kameraclienten unterstützte 10‑Bit-Profile für den dynamischen Bereich eines Geräts ermitteln, indem sie getSupportedProfiles
aufrufen.
Das Framework gibt dann eine Instanz von DynamicRangeProfiles
zurück, die Informationen zu unterstützten Profilen für den dynamischen Bereich und, falls verfügbar, Einschränkungen für die Aufnahmeanfrage enthält. Das Profil HLG10
muss unterstützt werden. Das empfohlene Profil für den dynamischen Bereich ist im Feld REQUEST_RECOMMENDED_TEN_BIT_DYNAMIC_RANGE_PROFILE
aufgeführt.
Kameraclients können Streamkombinationen konfigurieren, indem sie setDynamicRangeProfile
aufrufen.
Weitere Informationen zu obligatorischen Ausgabestreamkombinationen finden Sie in der Tabelle Zusätzliche garantierte Konfigurationen für 10-Bit-Ausgabe unter Reguläre Aufnahme.
Voraussetzungen
Damit die Kameraausgabe mit 10 Bit unterstützt wird, muss das Gerät einen Kamerasensor mit mindestens 10 Bit und entsprechender ISP-Unterstützung haben. Weitere Informationen zu den entsprechenden Kompatibilitätsanforderungen für die 10‑Bit-Unterstützung finden Sie im Abschnitt 7.5. Kameras im CDD.
Implementierung
Um die Unterstützung für die 10‑Bit-Kameraausgabe zu ermöglichen, müssen Gerätehersteller die folgenden Camera AIDL HAL-Integrationen durchführen:
- Schließe
ANDROID_REQUEST_AVAILABLE_CAPABILITIES_DYNAMIC_RANGE_TEN_BIT
in die Kamerafunktionen ein. - Füllen Sie
ANDROID_REQUEST_AVAILABLE_DYNAMIC_RANGE_PROFILES_MAP
mit allen unterstützten Profilen für den dynamischen Bereich und einer Bitmap der Einschränkungen. Das ProfilHLG10
muss unterstützt werden. Sie müssen auch ein empfohlenes Profil für den dynamischen Bereich angeben, um Kamera-Clients über das optimal unterstützte Format zu informieren. - Achte darauf, dass der Profilwert für den dynamischen Bereich bei der Streamkonfiguration für Streams im Format P010 unterstützt wird, oder dass ein implementierungsdefiniertes Format (
ImageFormat.PRIVATE
) unterstützt wird. - Legen Sie je nach Profil für den dynamischen Bereich den statischen oder dynamischen Metadatenpuffer der verarbeiteten Gralloc 4-Puffer fest, bevor Sie den Kameradienst benachrichtigen.
Weitere Informationen zur 10‑Bit-Kameraausgabe in der Kamera-HAL finden Sie unter metadata_definitions.xml
:
DYNAMIC_RANGE_TEN_BIT
- HAL-Details für
availableDynamicRangeProfilesMap
recommendedTenBitDynamicRangeProfile
10BIT_OUTPUT
Eine Referenzimplementierung der Kamera-HAL, die 10‑Bit-Kameraausgabe unterstützt, finden Sie unter /hardware/google/camera/devices/EmulatedCamera/hwl
.
Zertifizierungsstufe
Um die Implementierung der 10‑Bit-Kameraausgabe zu validieren und dafür zu sorgen, dass Drittanbieter-Apps die Funktion aktivieren können, empfehlen wir, die folgenden drei Validierungsphasen durchzuführen.
- Funktionale Richtigkeit der API testen
- Vergleich zwischen der nativen Kamera-App und einer Drittanbieter-App
- Standard Dynamic Range und High Dynamic Range im Vergleich
Für die visuelle Validierung der 10‑Bit-Kameraausgabe wird davon ausgegangen, dass das Gerät die Anzeige von HDR unterstützt (Display mit mehr als 1.000 Nits) und die App zur Videowiedergabe (z. B. Google Fotos) die Wiedergabe von HDR-Videos unterstützt.
Funktionale Richtigkeit der API testen
Führen Sie die folgenden CTS-, Camera ITS- und VTS-Tests aus, um die funktionale Richtigkeit der 10-Bit-Kameraausgabe zu testen:
hardware/interfaces/camera/provider/aidl/vts/
: Tests für grundlegende Erkennung, Konfiguration und Streaming sowie Prüfungen auf das Vorhandensein von HDR-Metadaten, sofern erforderlich.tests/camera/src/android/hardware/camera2/cts/
: Sorgt dafür, dass sich die Kamera gemäß den AOSP-API-Spezifikationen verhält.cts/apps/CameraITS
: Bestätigt, dass das allgemeine Videoverhalten bei Verwendung von HDR-Profilen konsistent ist. Der spezifische Test isttests/scene4/test_video_aspect_ratio_and_crop.py
.
Vergleich zwischen nativer Kamera und Drittanbieter-App
Wir empfehlen dringend, dafür zu sorgen, dass die Ergebnisse der Aufnahme von 10‑Bit-Videos mit einer Drittanbieter-App ähnlich, wenn nicht identisch mit der nativen Kamera-App sind. Das bedeutet, dass die Einstellungen wie Belichtung, Dynamikbereich und Farbe von der nativen App auf Drittanbieter-Apps übertragen werden sollten. Wenn Sie das Videorekordverhalten einer Drittanbieter-App, die 10-Bit-Kameraausgabe auf Ihrem Gerät unterstützt, überprüfen möchten, verwenden Sie die Camera2Video-Beispiel-App auf GitHub. Die folgenden Richtlinien sollen die sichtbaren Aspekte von HDR ohne objektive Zahlen veranschaulichen, da Sensoren, Displays, Betrachtungsbedingungen und Anbieterpräferenzen variieren.
Vorgeschlagene Szenen für den Vergleich
Um die native Kamera-App mit einer Drittanbieter-App zu vergleichen, nehmen Sie Videos in verschiedenen Szenen mit der nativen Kamera-App und der Camera2Video-Beispiel-App auf. Die folgenden Szenen werden für den Vergleich empfohlen:
- Eine Szene mit mittlerem bis schwachem Licht und einem hellen Objekt, z. B. einer Kerze oder einer kleinen hellen Lichtquelle, die einen großen Helligkeitsbereich erzeugt. So können Sie das Verhalten der automatischen Belichtung und den Dynamikbereich prüfen.
- Eine helle Außenszene mit leuchtenden Farben und reflektierenden Objekten wie Chromstoßstangen an einem Auto, die helle Highlights erzeugen. Das bestätigt das Rendering für helle Szenen mit noch helleren Highlights.
- Eine Szene mit mittlerem und niedrigem Dynamikbereich, z. B. eine natürliche Innenaufnahme in einem Zuhause oder Büro. Das bestätigt, dass sich weniger extreme Lichtverhältnisse wie erwartet verhalten.
Wir empfehlen, in allen Szenen Personen und Gesichter zu verwenden, um Belichtung, Farbe und Hautton zu überprüfen. Durch die Reduzierung der Variation zwischen den Aufnahmen werden Vergleiche zwischen aufeinanderfolgenden Aufnahmen erleichtert.
Standard- und High-Dynamic-Range vergleichen
Um sicherzustellen, dass die Verwendung eines 10‑Bit-Dynamikbereichsprofils gegenüber einem Standarddynamikbereichsprofil einen wahrnehmbaren Vorteil bietet, vergleiche Videoaufnahmen mit SDR (kein HDR-Profil) mit HDR-Videos, um zu bestätigen, dass wichtige Aspekte von HDR in den Aufnahmen enthalten sind. Verwenden Sie zum Vergleichen von SDR und HDR die Camera2Video-Beispiel-App und die vorgeschlagenen Szenen, um die native Kamera-App und Drittanbieter-Apps zu vergleichen.
Im Folgenden finden Sie wichtige Aspekte, die Sie in den vorgeschlagenen Szenen überprüfen sollten. Displaypanels, die HDR unterstützen, haben unterschiedliche Helligkeitsstufen (gemessen in Nits oder Lumen). Die folgenden Zahlen sind daher nur Beispiele:
- In der Szene mit mittlerem bis schwachem Licht werden die hellen Spitzlichter der Kerze oder der kleinen Lampe im HDR-Clip mit der maximalen Helligkeit für das Display (möglicherweise bis zu 1.000 cd/m²) und im SDR-Clip mit der maximalen Helligkeit für SDR (ca. 100 cd/m²) wiedergegeben. In einem HDR-Clip sollten die hellen Highlights auf dem Display leuchten und die Wahrnehmung des Nutzers vom tatsächlichen Dynamikbereich der Szene wiedergeben. Im Vergleich zum HDR-Clip sollte der SDR-Clip flacher und weniger hell erscheinen.
- In der hellen Ausgabeszene zeigt der HDR-Clip je nach Abstimmung des Geräts einen deutlichen Unterschied in der Bildschirmhelligkeit im Vergleich zum SDR-Clip. Beim HDR-Clip sollte die Bildschirmhelligkeit für die gesamte Szene (je nach Headroom) höher sein, z. B. bis zu 800 cd/m², und noch höher für die hellen Spitzlichter wie die Chromstoßstangen, die sich an der maximalen Helligkeit orientieren sollten.
- Bei Aufnahmen im Innenbereich mit mittlerem und niedrigem Dynamikbereich sind die HDR- und SDR-Clips in Bezug auf Farbe und Ton ähnlich. Die HDR-Aufnahme ist jedoch möglicherweise heller als die SDR-Aufnahme. Das HDR-Bild sollte nicht dunkler als das SDR-Bild sein. Wenn dies aufgrund der Optimierungsoptionen nicht möglich ist, muss das Verhalten der Drittanbieter-App dem Verhalten der nativen Kamera-App entsprechen.