Multi-Kamera-Unterstützung

Android 9 führte die API-Unterstützung für Geräte mit mehreren Kameras durch ein neues logisches Kameragerät ein, das aus zwei oder mehr physischen Kamerageräten besteht, die in die gleiche Richtung zeigen. Das logische Kameragerät wird als einzelnes CameraDevice/CaptureSession für eine App bereitgestellt, die eine Interaktion mit HAL-integrierten Multikamerafunktionen ermöglicht. Apps können optional auf zugrunde liegende physische Kamerastreams, Metadaten und Steuerelemente zugreifen und diese steuern.

Unterstützung mehrerer Kameras

Abbildung 1 . Unterstützung mehrerer Kameras

In diesem Diagramm sind verschiedene Kamera-IDs farblich gekennzeichnet. Die App kann Rohpuffer von jeder physischen Kamera gleichzeitig streamen. Es ist auch möglich, separate Steuerelemente festzulegen und separate Metadaten von verschiedenen physischen Kameras zu erhalten.

Beispiele und Quellen

Geräte mit mehreren Kameras müssen mit der logischen Multikamera-Fähigkeit beworben werden.

Kameraclients können die Kamera-ID der physischen Geräte abfragen, aus denen eine bestimmte logische Kamera besteht, indem sie getPhysicalCameraIds() aufrufen. Die als Teil des Ergebnisses zurückgegebenen IDs werden dann verwendet, um physische Geräte einzeln über setPhysicalCameraId() zu steuern. Die Ergebnisse solcher Einzelanfragen können aus dem vollständigen Ergebnis abgefragt werden, indem getPhysicalCameraResults() wird.

Einzelne physische Kameraanforderungen unterstützen möglicherweise nur eine begrenzte Teilmenge von Parametern. Um eine Liste der unterstützten Parameter zu erhalten, können Entwickler getAvailablePhysicalCameraRequestKeys() aufrufen.

Physische Kamerastreams werden nur für Anfragen ohne erneute Verarbeitung und nur für Monochrom- und Bayer-Sensoren unterstützt.

Implementierung

Support-Checkliste

So fügen Sie logische Geräte mit mehreren Kameras auf der HAL-Seite hinzu:

Bei Geräten mit Android 9 müssen Kamerageräte das Ersetzen eines logischen YUV/RAW-Streams durch physische Streams derselben Größe (gilt nicht für RAW-Streams) und desselben Formats von zwei physischen Kameras unterstützen. Dies gilt nicht für Geräte mit Android 10.

Für Geräte mit Android 10, bei denen die Kamera-HAL-Geräteversion 3.5 oder höher ist, muss das Kameragerät isStreamCombinationSupported unterstützen, damit Apps abfragen können, ob eine bestimmte Stream-Kombination mit physischen Streams unterstützt wird.

Stream-Konfigurationskarte

Für eine logische Kamera sind die obligatorischen Stream-Kombinationen für das Kameragerät einer bestimmten Hardwarestufe identisch mit denen, die in CameraDevice.createCaptureSession erforderlich sind. Alle Streams in der Stream-Konfigurationszuordnung müssen logische Streams sein.

Für ein logisches Kameragerät, das RAW-Fähigkeit mit physischen Subkameras unterschiedlicher Größe unterstützt, darf das logische Kameragerät nicht zu physischen Subkameras mit unterschiedlichen Sensorgrößen wechseln, wenn eine App einen logischen RAW-Stream konfiguriert. Dadurch wird sichergestellt, dass vorhandene RAW-Erfassungs-Apps nicht kaputt gehen.

Um den von HAL implementierten optischen Zoom durch Umschalten zwischen physischen Subkameras während der RAW-Aufnahme zu nutzen, müssen Apps physische Subkamera-Streams anstelle eines logischen RAW-Streams konfigurieren.

Garantierte Stream-Kombination

Sowohl die logische Kamera als auch ihre zugrunde liegenden physischen Kameras müssen die obligatorischen Stream-Kombinationen garantieren, die für ihre Geräteebenen erforderlich sind.

Ein logisches Kameragerät sollte basierend auf seiner Hardwarestufe und seinen Fähigkeiten genauso funktionieren wie ein physisches Kameragerät. Es wird empfohlen, dass der Funktionssatz eine Obermenge der einzelnen physischen Kameras ist.

Auf Geräten mit Android 9 muss die logische Kamera für jede garantierte Stream-Kombination Folgendes unterstützen:

  • Ersetzen eines logischen YUV_420_888- oder RAW-Streams durch zwei physische Streams derselben Größe und desselben Formats, jeweils von einer separaten physischen Kamera, vorausgesetzt, dass die Größe und das Format von den physischen Kameras unterstützt werden.

  • Hinzufügen von zwei RAW-Streams, einen von jeder physischen Kamera, wenn die logische Kamera keine RAW-Fähigkeit ankündigt, die zugrunde liegenden physischen Kameras jedoch. Dies tritt normalerweise auf, wenn die physischen Kameras unterschiedliche Sensorgrößen haben.

  • Verwenden von physischen Streams anstelle eines logischen Streams derselben Größe und desselben Formats. Dies darf die Framerate der Erfassung nicht verlangsamen, wenn die minimale Framedauer der physischen und logischen Streams gleich ist.

Leistungs- und Energieüberlegungen

  • Leistung:

    • Das Konfigurieren und Streamen von physischen Streams kann die Erfassungsrate der logischen Kamera aufgrund von Ressourcenbeschränkungen verlangsamen.
    • Das Anwenden physischer Kameraeinstellungen kann die Aufnahmerate verlangsamen, wenn die zugrunde liegenden Kameras in unterschiedliche Bildraten versetzt werden.

  • Leistung:

    • Die Leistungsoptimierung von HAL arbeitet im Standardfall weiter.
    • Das Konfigurieren oder Anfordern von physischen Streams kann die interne Energieoptimierung von HAL außer Kraft setzen und einen höheren Stromverbrauch verursachen.

Anpassung

Sie können Ihre Geräteimplementierung auf folgende Weise anpassen.

  • Der verschmolzene Ausgang des logischen Kamerageräts hängt vollständig von der HAL-Implementierung ab. Die Entscheidung, wie fusionierte logische Streams von den physischen Kameras abgeleitet werden, ist für die App und das Android-Kamera-Framework transparent.
  • Individuelle physische Anfragen und Ergebnisse können optional unterstützt werden. Der Satz verfügbarer Parameter in solchen Anforderungen hängt auch vollständig von der spezifischen HAL-Implementierung ab.
  • Ab Android 10 kann die HAL die Anzahl der Kameras reduzieren, die direkt von einer App geöffnet werden können, indem sie sich dafür entscheidet, einige oder alle PHYSICAL_IDs nicht in getCameraIdList . Der Aufruf getPhysicalCameraCharacteristics muss dann die Eigenschaften der physischen Kamera zurückgeben.

Validierung

Logische Geräte mit mehreren Kameras müssen Kamera-CTS wie jede andere normale Kamera passieren. Die Testfälle, die auf diesen Gerätetyp abzielen, finden Sie im LogicalCameraDeviceTest -Modul.

Diese drei ITS-Tests zielen auf Mehrkamerasysteme ab, um die ordnungsgemäße Zusammenführung von Bildern zu erleichtern:

Die Tests Szene 1 und Szene 4 laufen mit dem ITS-in-a-Box -Prüfstand. Der Test test_multi_camera_match behauptet, dass die Helligkeit der Mitte der Bilder übereinstimmt, wenn beide Kameras aktiviert sind. Der Test test_multi_camera_alignment , dass Kameraabstände, Ausrichtungen und Verzerrungsparameter richtig geladen sind. Wenn das Multikamerasystem eine Wide FoV-Kamera (>90o) enthält, ist die rev2-Version der ITS-Box erforderlich.

Sensor_fusion ist ein zweiter Prüfstand, der wiederholte, vorgeschriebene Telefonbewegungen ermöglicht und bestätigt, dass die Zeitstempel des Gyroskops und des Bildsensors übereinstimmen und dass die Multikamera-Frames synchron sind.

Alle Boxen sind über AcuSpec, Inc. ( www.acuspecinc.com , fred@acuspecinc.com) und MYWAY Manufacturing ( www.myway.tw , sales@myway.tw) erhältlich. Darüber hinaus kann die rev1 ITS-Box über West-Mark ( www.west-mark.com , dgoodman@west-mark.com) erworben werden.

Empfohlene Vorgehensweise

Um die Vorteile der Multi-Kamera-Funktionen voll auszuschöpfen und gleichzeitig die App-Kompatibilität aufrechtzuerhalten, befolgen Sie diese Best Practices bei der Implementierung eines logischen Multi-Kamera-Geräts:

  • (Android 10 oder höher) Physische Subkameras von getCameraIdList . Dies reduziert die Anzahl der Kameras, die direkt von Apps geöffnet werden können, wodurch die Notwendigkeit für Apps entfällt, über eine komplexe Kameraauswahllogik zu verfügen.
  • (Android 11 oder höher) Implementieren Sie für ein logisches Gerät mit mehreren Kameras, das optischen Zoom unterstützt, die API ANDROID_CONTROL_ZOOM_RATIO und verwenden ANDROID_SCALER_CROP_REGION nur zum Zuschneiden des Seitenverhältnisses. ANDROID_CONTROL_ZOOM_RATIO ermöglicht es dem Gerät, herauszuzoomen und eine bessere Präzision beizubehalten. In diesem Fall muss die HAL das Koordinatensystem von ANDROID_SCALER_CROP_REGION , ANDROID_CONTROL_AE_REGIONS , ANDROID_CONTROL_AWB_REGIONS , ANDROID_CONTROL_AF_REGIONS , ANDROID_STATISTICS_FACE_RECTANGLES und ANDROID_STATISTICS_FACE_LANDMARKS , um das Post-Zoom-Sichtfeld als das aktive Sensorarray zu behandeln. Weitere Informationen darüber, wie ANDROID_SCALER_CROP_REGION mit ANDROID_CONTROL_ZOOM_RATIO zusammenarbeitet, finden Sie unter camera3_crop_reprocess#cropping .
  • Stellen Sie bei Geräten mit mehreren Kameras und physischen Kameras mit unterschiedlichen Funktionen sicher, dass das Gerät die Unterstützung für einen bestimmten Wert oder Bereich für ein Steuerelement nur ankündigt, wenn der gesamte Zoombereich den Wert oder Bereich unterstützt. Wenn die logische Kamera beispielsweise aus einer Ultraweitwinkel-, einer Weitwinkel- und einer Telekamera besteht, gehen Sie wie folgt vor:
    • Wenn die Größen der aktiven Arrays der physischen Kameras unterschiedlich sind, muss die Kamera-HAL die Zuordnung von den aktiven Arrays der physischen Kameras zu den aktiven Arrays der logischen Kamera für ANDROID_SCALER_CROP_REGION , ANDROID_CONTROL_AE_REGIONS , ANDROID_CONTROL_AWB_REGIONS , ANDROID_CONTROL_AF_REGIONS , ANDROID_STATISTICS_FACE_RECTANGLES und ANDROID_STATISTICS_FACE_LANDMARKS vornehmen, damit diese von den Apps stammen Perspektive ist das Koordinatensystem die Größe des aktiven Arrays der logischen Kamera.
    • Wenn die Weitwinkel- und Telekameras den Autofokus unterstützen, die Ultraweitwinkelkamera jedoch einen festen Fokus hat, stellen Sie sicher, dass die logische Kamera die Autofokus-Unterstützung ankündigt. Die HAL muss eine Autofokus-Zustandsmaschine für die Ultrawide-Kamera simulieren, damit beim Herauszoomen der App auf das Ultrawide-Objektiv die Tatsache, dass die zugrunde liegende physische Kamera fest fokussiert ist, für die App und die Autofokus-Zustandsmaschinen für die unterstützten AF-Modi transparent ist funktionieren wie erwartet.
    • Wenn die Weitwinkel- und Telekameras 4K @ 60 fps unterstützen und die Ultrawide-Kamera nur 4K @ 30 fps oder 1080p @ 60 fps unterstützt, aber nicht 4K @ 60 fps, stellen Sie sicher, dass die logische Kamera nicht 4k @ 60 fps ankündigt seine unterstützten Stream-Konfigurationen. Dies garantiert die Integrität der logischen Kamerafunktionen und stellt sicher, dass die App nicht auf das Problem stößt, 4k @ 60 fps bei einem ANDROID_CONTROL_ZOOM_RATIO Wert von weniger als 1 nicht zu erreichen.
  • Ab Android 10 ist keine logische Multi-Kamera erforderlich, um Stream-Kombinationen zu unterstützen, die physische Streams enthalten. Wenn die HAL eine Kombination mit physischen Streams unterstützt:
    • (Android 11 oder höher) Um Anwendungsfälle wie Tiefe von Stereo und Bewegungsverfolgung besser handhaben zu können, machen Sie das Sichtfeld der physischen Stream-Ausgänge so groß wie dies durch die Hardware erreicht werden kann. Wenn jedoch ein physischer Stream und ein logischer Stream von derselben physischen Kamera stammen, können Hardwareeinschränkungen dazu führen, dass das Sichtfeld des physischen Streams mit dem des logischen Streams identisch ist.
    • Um den durch mehrere physische Streams verursachten Speicherdruck zu beheben, stellen Sie sicher, dass Apps discardFreeBuffers verwenden, um die freien Puffer (Puffer, die vom Verbraucher freigegeben, aber noch nicht aus der Warteschlange entfernt wurden) freizugeben, wenn erwartet wird, dass ein physischer Stream für einen bestimmten Zeitraum inaktiv ist von Zeit.
    • Wenn physische Streams von verschiedenen physischen Kameras normalerweise nicht an dieselbe Anfrage angehängt werden, stellen Sie sicher, dass Apps eine surface group verwenden, sodass eine Pufferwarteschlange verwendet wird, um zwei App-zugewandte Oberflächen zu sichern, wodurch der Speicherverbrauch reduziert wird.