Unterstützung mehrerer Kameras

Mit Android 9 wurde die API-Unterstützung für Geräte mit mehreren Kameras eingeführt. Dazu wurde ein neues logisches Kameragerät entwickelt, das aus zwei oder mehr physischen Kamerageräten besteht, die in dieselbe Richtung zeigen. Das logische Kameragerät wird einer App als einzelnes CameraDevice/CaptureSession präsentiert, sodass die Interaktion mit HAL-integrierten Funktionen für mehrere Kameras möglich ist. 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. Außerdem ist es möglich, separate Einstellungen festzulegen und separate Metadaten von verschiedenen physischen Kameras zu erhalten.

Beispiele und Quellen

Geräte mit mehreren Kameras müssen mit der logischen Funktion für mehrere Kameras beworben werden.

Kameraclienten können die Kamera-ID der physischen Geräte, aus denen eine bestimmte logische Kamera besteht, durch Aufrufen von getPhysicalCameraIds() abfragen. Die im Ergebnis zurückgegebenen IDs werden dann verwendet, um physische Geräte einzeln über setPhysicalCameraId() zu steuern. Die Ergebnisse solcher einzelnen Anfragen können aus dem vollständigen Ergebnis abgerufen werden, indem getPhysicalCameraResults() aufgerufen wird.

Einzelne physische Kameraanfragen unterstützen möglicherweise nur eine begrenzte Teilmenge von Parametern. Entwickler können eine Liste der unterstützten Parameter mit dem Aufruf von getAvailablePhysicalCameraRequestKeys() abrufen.

Streams von physischen Kameras werden nur für Anfragen ohne erneute Verarbeitung und nur für monochrome und Bayer-Sensoren unterstützt.

Implementierung

Support-Checkliste

So fügen Sie logische Multikamera-Geräte 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. Das gilt nicht für Geräte mit Android 10.

Bei Geräten mit Android 10, auf 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 Streamkombination mit physischen Streams unterstützt wird.

Karte der Streamkonfiguration

Für eine logische Kamera sind die obligatorischen Streamkombinationen für das Kameragerät einer bestimmten Hardwareebene dieselben wie in CameraDevice.createCaptureSession. Alle Streams in der Streamkonfigurationszuordnung müssen logische Streams sein.

Wenn eine logische Kamera mit RAW-Funktion und physischen Unterkameras unterschiedlicher Größe von einer App für einen logischen RAW-Stream konfiguriert wird, darf die logische Kamera nicht zu physischen Unterkameras mit unterschiedlichen Sensorgrößen wechseln. So wird sichergestellt, dass vorhandene RAW-Aufnahme-Apps nicht mehr funktionieren.

Um den HAL-implementierten optischen Zoom zu nutzen, indem während der RAW-Aufnahme zwischen physischen Unterkameras gewechselt wird, müssen Apps physische Unterkamerastreams anstelle eines logischen RAW-Streams konfigurieren.

Garantierte Streamkombination

Sowohl die logische Kamera als auch die zugrunde liegenden physischen Kameras müssen die für ihre Geräteebenen erforderlichen obligatorischen Streamkombinationen unterstützen.

Ein logisches Kameragerät sollte sich je nach Hardwareebene und Funktionen genauso verhalten wie ein physisches Kameragerät. Es wird empfohlen, dass der Funktionsumfang ein Superset des Funktionsumfangs einzelner physischer Kameras ist.

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

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

  • Hinzufügen von zwei Rohdatenstreams, einem von jeder physischen Kamera, wenn die logische Kamera keine RAW-Funktion bietet, die zugrunde liegenden physischen Kameras jedoch schon. Dies tritt in der Regel auf, wenn die physischen Kameras unterschiedliche Sensorgrößen haben.

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

Hinweise zu Leistung und Stromverbrauch

  • Leistung:

    • Das Konfigurieren und Streamen physischer Streams kann die Erfassungsrate der logischen Kamera aufgrund von Ressourcenbeschränkungen verlangsamen.
    • Wenn Sie physische Kameraeinstellungen anwenden, kann sich die Erfassungsrate verlangsamen, wenn die zugrunde liegenden Kameras auf unterschiedliche Frameraten eingestellt werden.

  • Stromversorgung:

    • Die Energieoptimierung von HAL funktioniert weiterhin im Standardfall.
    • Durch das Konfigurieren oder Anfordern physischer Streams kann die interne Energieoptimierung von HAL überschrieben werden, was zu einem höheren Energieverbrauch führt.

Personalisierung

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

  • Die zusammengeführte Ausgabe des logischen Kamerageräts hängt vollständig von der HAL-Implementierung ab. Die Entscheidung, wie zusammengeführte logische Streams von den physischen Kameras abgeleitet werden, ist für die App und das Android-Kamera-Framework transparent.
  • Einzelne physische Anfragen und Ergebnisse können optional unterstützt werden. Die Menge der verfügbaren Parameter in solchen Anfragen hängt auch vollständig von der jeweiligen HAL-Implementierung ab.
  • Ab Android 10 kann die HAL die Anzahl der Kameras reduzieren, die von einer App direkt geöffnet werden können, indem sie einige oder alle PHYSICAL_IDs in getCameraIdList nicht bewirbt. Beim Aufrufen von getPhysicalCameraCharacteristics müssen dann die Merkmale der physischen Kamera zurückgegeben werden.

Zertifizierungsstufe

Logische Geräte mit mehreren Kameras müssen den Kamera-CTS wie jede andere reguläre Kamera bestehen. Die Testläufe für diesen Gerätetyp finden Sie im Modul LogicalCameraDeviceTest.

Diese drei ITS-Tests sind auf Systeme mit mehreren Kameras ausgerichtet, um die richtige Zusammenführung von Bildern zu ermöglichen:

Die Tests für Szene 1 und Szene 4 werden mit dem ITS-in-a-box-Testaufbau ausgeführt. Beim test_multi_camera_match-Test wird geprüft, ob die Helligkeit der Bildmitte übereinstimmt, wenn beide Kameras aktiviert sind. Im test_multi_camera_alignment-Test wird geprüft, ob Kameraabstände, Ausrichtungen und Verzerrungsparameter richtig geladen werden. Wenn das System mit mehreren Kameras eine Kamera mit weitem Sichtfeld (>90°) umfasst, ist die Version 2 der ITS-Box erforderlich.

Sensor_fusion ist ein zweiter Prüfstand, der wiederholte, vorgeschriebene Bewegungen des Smartphones ermöglicht und dafür sorgt, dass die Zeitstempel des Gyroskops und des Bildsensors übereinstimmen und die Multikamera-Frames synchronisiert sind.

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

Best Practices

Damit Sie die durch die Unterstützung mehrerer Kameras aktivierten Funktionen voll ausschöpfen und gleichzeitig die App-Kompatibilität beibehalten können, sollten Sie beim Implementieren eines logischen Geräts mit mehreren Kameras folgende Best Practices beachten:

  • (Android 10 oder höher) Physische Unterkameras in getCameraIdList ausblenden. Dadurch wird die Anzahl der Kameras reduziert, die von Apps direkt geöffnet werden können. Apps benötigen dann keine komplexe Logik zur Kameraauswahl mehr.
  • (Android 11 oder höher) Implementieren Sie für ein logisches Gerät mit mehreren Kameras, das optischen Zoom unterstützt, die ANDROID_CONTROL_ZOOM_RATIO-API und verwenden Sie ANDROID_SCALER_CROP_REGION nur für das 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 das 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 anpassen, um das Sichtfeld nach dem Zoomen als aktives Sensorarray zu behandeln. Weitere Informationen zur Zusammenarbeit von ANDROID_SCALER_CROP_REGION und ANDROID_CONTROL_ZOOM_RATIO finden Sie unter camera3_crop_reprocess#cropping.
  • Bei Geräten mit mehreren Kameras mit unterschiedlichen Funktionen muss das Gerät die Unterstützung für einen bestimmten Wert oder Bereich für ein Steuerelement nur dann angeben, 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 so vor:
    • Wenn die aktiven Arraygrößen der physischen Kameras unterschiedlich sind, muss die Kamera-HAL die Zuordnung der aktiven Arrays der physischen Kameras zum aktiven Array 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, sodass das Koordinatensystem aus Sicht der App die aktive Arraygröße der logischen Kamera ist.
    • Wenn die Weitwinkel- und Telekameras Autofokus unterstützen, die Ultraweitwinkelkamera jedoch einen festen Fokus hat, muss die logische Kamera Autofokusunterstützung angeben. Das HAL muss eine Autofokus-Zustandsmaschine für die Ultraweitwinkelkamera simulieren, damit die Tatsache, dass die zugrunde liegende physische Kamera einen festen Fokus hat, für die App transparent ist, wenn die App auf das Ultraweitwinkelobjektiv zoomt. Die Autofokus-Zustandsmaschinen für die unterstützten AF-Modi funktionieren wie erwartet.
    • Wenn die Weitwinkel- und Telekameras 4K @ 60 fps unterstützen und die Ultraweitwinkelkamera nur 4K @ 30 fps oder 1080p @ 60 fps, aber nicht 4K @ 60 fps, muss die logische Kamera in ihren unterstützten Streamkonfigurationen 4K @ 60 fps angeben. So wird die Integrität der logischen Kamerafunktionen gewährleistet und die App kann nicht das Problem haben, dass sie bei einem ANDROID_CONTROL_ZOOM_RATIO-Wert von weniger als 1 keine 4K-Auflösung bei 60 fps erreicht.
  • Ab Android 10 ist keine logische Multikamera erforderlich, um Streamkombinationen 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 die Tiefenmessung mit Stereobildern und die Bewegungsverfolgung besser zu unterstützen, sollte das Sichtfeld der physischen Stream-Ausgaben so groß wie möglich sein. Wenn ein physischer Stream und ein logischer Stream jedoch von derselben physischen Kamera stammen, kann es aufgrund von Hardwarebeschränkungen sein, dass das Sichtfeld des physischen Streams mit dem des logischen Streams übereinstimmt.
    • Um den durch mehrere physische Streams verursachten Speicherdruck zu verringern, sollten Apps discardFreeBuffers verwenden, um die kostenlosen Puffer (Puffer, die vom Consumer freigegeben, aber noch nicht vom Producer aus der Warteschlange entfernt wurden) freizugeben, wenn ein physischer Stream voraussichtlich für einen bestimmten Zeitraum im Leerlauf ist.
    • Wenn physische Streams von verschiedenen physischen Kameras normalerweise nicht an dieselbe Anfrage angehängt werden, sollten Apps surface group verwenden, damit ein Puffer für zwei App-orientierte Oberflächen verwendet wird und der Arbeitsspeicherverbrauch sinkt.