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 mit zwei oder mehr physischen Kameras erstellt, die in dieselbe Richtung zeigen. Das logische Kameragerät wird einer App als einzelnes CameraDevice/CaptureSession zur Verfügung gestellt, sodass eine 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 gleichzeitig Rohpuffer von jeder physischen Kamera streamen. Außerdem ist es möglich, separate Steuerelemente festzulegen und separate Metadaten von verschiedenen physischen Kameras zu erhalten.

Beispiele und Quellen

Bei Geräten mit mehreren Kameras muss die logische Multi-Kamera-Funktion 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 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 abgefragt werden, indem getPhysicalCameraResults() aufgerufen wird.

Einzelne Anfragen für physische Kameras unterstützen möglicherweise nur einen begrenzten Teil der Parameter. Entwickler können getAvailablePhysicalCameraRequestKeys() aufrufen, um eine Liste der unterstützten Parameter zu erhalten.

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

Implementierung

Checkliste für den Support

So fügen Sie auf HAL-Seite logische Multi-Kamera-Geräte hinzu:

Auf Geräten mit Android 9 müssen Kameras 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.

Streamkonfigurationskarte

Bei einer logischen Kamera entsprechen die erforderlichen Streamkombinationen für das Kameragerät einer bestimmten Hardwareebene den Anforderungen in CameraDevice.createCaptureSession. Alle Streams in der Streamkonfigurationskarte müssen logische Streams sein.

Wenn eine App einen logischen RAW-Stream für ein logisches Kameragerät konfiguriert, das RAW-Funktionen mit physischen Unterkameras unterschiedlicher Größe unterstützt, darf das logische Kameragerät nicht zu physischen Unterkameras mit unterschiedlichen Sensorgrößen wechseln. So wird sichergestellt, dass vorhandene Apps zur RAW-Aufnahme nicht beschädigt werden.

Wenn Apps den von HAL implementierten optischen Zoom nutzen möchten, indem sie während der RAW-Aufnahme zwischen physischen Unterkameras wechseln, müssen sie physische Unterkamerastreams anstelle eines logischen RAW-Streams konfigurieren.

Kombination aus garantierten Streams

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

Ein logisches Kameragerät sollte auf der Grundlage seiner Hardwareebene und -funktionen genauso funktionieren wie ein physisches Kameragerät. Es wird empfohlen, dass die Funktionen der virtuellen Kamera die der einzelnen physischen Kameras übertreffen.

Auf Geräten mit Android 9 muss die logische Kamera für jede Kombination von garantierten Streams Folgendes unterstützen:

  • Ein logischer YUV_420_888- oder Rohstream wird durch zwei physische Streams derselben Größe und desselben Formats ersetzt, die jeweils von einer separaten physischen Kamera stammen, vorausgesetzt, Größe und Format werden von den physischen Kameras unterstützt.

  • Es werden zwei Rohstreams hinzugefügt, einer von jeder physischen Kamera, wenn die logische Kamera keine RAW-Funktion anbietet, die zugrunde liegenden physischen Kameras aber schon. Das tritt in der Regel auf, wenn die physischen Kameras unterschiedliche Sensorgrößen haben.

  • Verwendung physischer Streams anstelle eines logischen Streams mit derselben Größe und demselben Format. Die Framerate der Aufnahme darf dadurch nicht verlangsamt werden, wenn die minimale Framedauer der physischen und logischen Streams gleich ist.

Hinweise zu Leistung und Stromverbrauch

  • Leistung:

    • Die Konfiguration und das Streaming physischer Streams kann die Aufnahmerate der logischen Kamera aufgrund von Ressourceneinschränkungen verlangsamen.
    • Wenn Sie die Einstellungen der physischen Kamera anwenden, kann die Aufnahmerate sinken, wenn die zugrunde liegenden Kameras unterschiedliche Frameraten haben.

  • Stromversorgung:

    • Die Energieoptimierung von HAL funktioniert weiterhin standardmäßig.
    • Wenn Sie physische Streams konfigurieren oder anfordern, wird möglicherweise die interne Energieoptimierung von HAL überschrieben und es wird mehr Strom verbraucht.

Personalisierung

Sie können die Geräteimplementierung auf folgende Arten anpassen:

  • Die Fusionsausgabe des logischen Kamerageräts hängt vollständig von der HAL-Implementierung ab. Die Entscheidung, wie die zusammengeführten logischen Streams aus 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 verfügbaren Parameter in solchen Anfragen sind ebenfalls vollständig von der jeweiligen HAL-Implementierung abhängig.
  • Ab Android 10 kann die HAL die Anzahl der Kameras reduzieren, die von einer App direkt geöffnet werden können, indem einige oder alle PHYSICAL_IDs in getCameraIdList nicht gesendet werden. Beim Aufrufen von getPhysicalCameraCharacteristics müssen dann die Eigenschaften der physischen Kamera zurückgegeben werden.

Zertifizierungsstufe

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

Diese drei ITS-Tests sind auf Mehrkamerasysteme ausgerichtet, um die ordnungsgemäße Bildfusion zu ermöglichen:

Die Tests für Szene 1 und Szene 4 werden mit der Test-Rig ITS-in-a-Box ausgeführt. Beim test_multi_camera_match-Test wird geprüft, ob die Helligkeit im Zentrum der Bilder übereinstimmt, wenn beide Kameras aktiviert sind. Beim Test test_multi_camera_alignment wird geprüft, ob die Kameraabstände, ‑ausrichtungen und ‑verzerrungsparameter richtig geladen wurden. Wenn das Mehrkamerasystem eine Kamera mit Weitwinkelobjektiv (> 90 Grad) enthält, ist die Rev2-Version des ITS-Gehäuses erforderlich.

Sensor_fusion ist ein zweites Testgestell, das wiederholte, vorgeschriebene Smartphone-Bewegungen ermöglicht und dafür sorgt, dass die Zeitstempel des Gyroskops und des Bildsensors übereinstimmen und die Frames der Multi-Kamera 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. Darüber hinaus kann der ITS-Box der Version 1 über West-Mark (www.west-mark.com, dgoodman@west-mark.com) erworben werden.

Best Practices

Wenn Sie die Funktionen von Multi-Kameras voll ausschöpfen und gleichzeitig die App-Kompatibilität beibehalten möchten, beachten Sie bei der Implementierung eines logischen Multi-Kamera-Geräts die folgenden Best Practices:

  • (Android 10 oder höher) Untergeordnete Kameras aus 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 Gerät mit mehreren Kameras, das einen 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 dabei 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 anpassen, um das Sichtfeld nach dem Zoomen als aktives Sensorarray zu behandeln. Weitere Informationen zur Funktionsweise von ANDROID_SCALER_CROP_REGION mit 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 eines bestimmten Werts oder Bereichs für ein Steuerelement nur angeben, wenn der Wert oder Bereich vom gesamten Zoombereich unterstützt wird. Wenn die logische Kamera beispielsweise aus einer Ultraweitwinkel-, einer Weitwinkel- und einer Teleobjektivkamera besteht, gehen Sie so vor:
    • Wenn sich die aktiven Arraygrößen der physischen Kameras unterscheiden, muss die HAL der Kamera 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 der aktiven Arraygröße der logischen Kamera entspricht.
    • Wenn die Weitwinkel- und Teleobjektivkamera Autofokus unterstützen, die Ultraweitwinkelkamera aber einen festen Fokus hat, muss für die logische Kamera Autofokus unterstützt werden. Der HAL muss einen Autofokus-Zustandsautomaten für die Ultraweitwinkelkamera simulieren, damit die App nicht merkt, dass die zugrunde liegende physische Kamera einen Fixfokus hat, wenn sie mit dem Zoom auf das Ultraweitwinkelobjektiv herauszoomt. Außerdem müssen die Autofokus-Zustandsautomaten für die unterstützten AF-Modi wie erwartet funktionieren.
    • Wenn die Weitwinkel- und Teleobjektivkamera 4K mit 60 fps unterstützen und die Ultraweitwinkelkamera nur 4K mit 30 fps oder 1080p mit 60 fps, aber nicht 4K mit 60 fps, darf die logische Kamera in ihren unterstützten Streamkonfigurationen keine 4K-Auflösung mit 60 fps angeben. So wird die Integrität der logischen Kamerafunktionen gewährleistet und die App kann 4K bei 60 fps auch bei einem Wert von ANDROID_CONTROL_ZOOM_RATIO unter 1 erreichen.
  • Ab Android 10 ist keine logische Multi-Kamera mehr 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 Tiefenerfassung durch Stereo- und Bewegungserkennung besser zu verarbeiten, sollte das Sichtfeld der physischen Stream-Ausgaben so groß wie möglich sein, was mit der Hardware möglich ist. Wenn ein physischer und ein logischer Stream jedoch von derselben physischen Kamera stammen, kann es aufgrund von Hardwareeinschränkungen sein, dass das Sichtfeld des physischen Streams mit dem des logischen Streams identisch ist.
    • Um den durch mehrere physische Streams verursachten Speicherdruck zu beheben, sollten Apps discardFreeBuffers verwenden, um die kostenlosen Puffer (Puffer, die vom Verbraucher freigegeben, aber noch nicht vom Erzeuger aus der Warteschlange entfernt wurden) zu deallokieren, wenn ein physischer Stream voraussichtlich für einen bestimmten Zeitraum inaktiv sein wird.
    • Wenn physische Streams von verschiedenen physischen Kameras in der Regel nicht mit derselben Anfrage verknüpft sind, müssen Apps surface group verwenden, damit eine Pufferwarteschlange für zwei App-Oberflächen verwendet wird, was die Arbeitsspeichernutzung reduziert.