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 einzelne 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 codiert. 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, aus denen eine bestimmte logische Kamera besteht, abfragen, 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 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

Support-Checkliste

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 sind die erforderlichen Streamkombinationen für das Kameragerät einer bestimmten Hardwarestufe mit den Angaben in CameraDevice.createCaptureSession identisch. 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 garantiertem Stream

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, sofern Größe und Format von den physischen Kameras unterstützt werden.

  • 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.
    • Das Anwenden physischer Kameraeinstellungen kann die Aufnahmerate verlangsamen, wenn die zugrunde liegenden Kameras auf unterschiedliche Frame-Rates eingestellt werden.

  • Stromversorgung:

    • Die Energieoptimierung von HAL funktioniert weiterhin standardmäßig.
    • Das Konfigurieren oder Anfordern von physischen Streams kann die interne Energieoptimierung von HAL überschreiben und mehr Strom verbrauchen.

Personalisierung

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

  • Die fusionierte Ausgabe 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 Anfragen und Ergebnisse für physische Produkte 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 Testläufe, die auf diesen Gerätetyp ausgerichtet sind, 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 dem Test-Rig ITS-in-a-Box ausgeführt. Der test_multi_camera_match-Test bestätigt, dass die Helligkeit in der Mitte der Bilder übereinstimmt, wenn beide Kameras aktiviert sind. Der test_multi_camera_alignment-Test prüft, ob die Parameter für Kameraabstände, Ausrichtungen und Verzerrungen korrekt geladen wurden. Wenn das Mehrkamerasystem eine Weitwinkelkamera (> 90°) enthält, ist die Version 2 der ITS-Box 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. Außerdem 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 direkt von Anwendungen geöffnet werden können, sodass Anwendungen keine komplexe Kameraauswahllogik haben müssen.
  • (Android 11 oder höher) Implementieren Sie für ein logisches Gerät mit mehreren Kameras, das den optischen Zoom unterstützt, die ANDROID_CONTROL_ZOOM_RATIO API und verwenden Sie ANDROID_SCALER_CROP_REGION nur zum Zuschneiden des Seitenverhältnisses. Mit ANDROID_CONTROL_ZOOM_RATIO kann das Gerät herauszoomen und eine bessere Präzision erzielen. 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 nur dann die Unterstützung eines bestimmten Werts oder Bereichs für ein Steuerelement 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, damit das Koordinatensystem aus Sicht der App der aktiven Arraygröße der logischen Kamera entspricht.
    • Wenn die Weitwinkel- und Teleobjektivkameras den Autofokus unterstützen, die Ultraweitwinkelkamera jedoch einen Fixfokus hat, muss die logische Kamera den Autofokus unterstützen. 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 hinauszoomt. 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. Dadurch wird die Integrität der logischen Kamerafunktionen gewährleistet und die App verhindert, dass 4K bei 60 fps bei einem ANDROID_CONTROL_ZOOM_RATIO-Wert von weniger als 1 nicht erreicht wird.
  • 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 aus Stereo- und Bewegungserkennung besser zu verarbeiten, sollte das Sichtfeld der physischen Streamausgaben so groß wie möglich sein, was mit der Hardware möglich ist. Wenn ein physischer Stream 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 übereinstimmt.
    • 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 an die App gerichtete Oberflächen verwendet wird. Dadurch wird der Arbeitsspeicherverbrauch reduziert.