Unterstützung mehrerer Kameras

Unter Android 9 wurde die API-Unterstützung für Geräte mit mehreren Kameras durch ein neues logisches Kamera-Gerät eingeführt, das aus zwei oder mehr physischen Kameras besteht, die in dieselbe Richtung zeigen. Das logische Kamera-Gerät wird einer App als einzelnes CameraDevice/CaptureSession präsentiert, sodass die Interaktion mit in HAL integrierten Funktionen für mehrere Kameras möglich ist. Apps können optional auf die zugrunde liegenden physischen Kamerastreams, Metadaten und Steuerelemente zugreifen und diese steuern.

Unterstützung mehrerer Kameras

Abbildung 1. Unterstützung für mehrere Kameras

In diesem Diagramm sind die verschiedenen 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 empfangen.

Beispiele und Quellen

Geräte mit mehreren Kameras müssen mit der logischen Multi-Kamera-Funktion beworben werden.

Kameraclient-Anwendungen 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 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. Um eine Liste der unterstützten Parameter zu erhalten, können Entwickler getAvailablePhysicalCameraRequestKeys() aufrufen.

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

Implementierung

Checkliste für die Unterstützung

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

Bei Geräten mit Android 9 müssen Kamerageräte das Ersetzen eines logischen YUV- oder 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.

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.

Zuordnung der Streamkonfiguration

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

Wenn eine App einen logischen RAW-Stream konfiguriert, darf das logische Kameragerät nicht zu physischen Unterkameras mit unterschiedlichen Sensorgrößen wechseln. So wird verhindert, dass vorhandene Apps für die RAW-Aufnahme nicht mehr funktionieren.

Wenn Sie den in HAL implementierten optischen Zoom nutzen möchten, indem Sie während der RAW-Aufnahme zwischen physischen Unterkameras wechseln, 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 obligatorischen Streamkombinationen garantieren, die für ihre Geräteebenen erforderlich sind.

Ein logisches Kameragerät sollte sich je nach Hardwareebene und Funktionen genauso verhalten wie ein physisches Kameragerät. Es wird empfohlen, dass das Feature-Set eine Obermenge der einzelnen physischen Kameras ist.

Bei 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, jeweils von einer separaten physischen Kamera, vorausgesetzt, Größe und Format werden von den physischen Kameras unterstützt.

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

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

Überlegungen zu Leistung und Stromverbrauch

  • Leistung:

    • Das Konfigurieren und Streamen physischer Streams kann die Aufnahmerate der logischen Kamera aufgrund von Ressourcenbeschränkungen verlangsamen.
    • Das Anwenden von Einstellungen für physische Kameras kann die Aufnahmerate verlangsamen, wenn die zugrunde liegenden Kameras mit unterschiedlichen Frameraten verwendet werden.

  • Stromverbrauch:

    • Die Energieoptimierung von HAL funktioniert im Standardfall weiterhin.
    • Das Konfigurieren oder Anfordern physischer Streams kann die interne Energieoptimierung von HAL überschreiben und zu einem höheren Energieverbrauch führen.

Anpassung

Sie können Ihre Geräteimplementierung so anpassen:

  • Die kombinierte Ausgabe des logischen Kamerageräts hängt vollständig von der HAL-Implementierung ab. Die Entscheidung, wie kombinierte 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 ebenfalls vollständig von der jeweiligen HAL-Implementierung ab.
  • Ab Android 10 kann HAL die Anzahl der Kameras reduzieren, die von einer App direkt geöffnet werden können, indem einige oder alle PHYSICAL_IDs in getCameraIdListnicht beworben werden. Der Aufruf von getPhysicalCameraCharacteristics muss dann die Merkmale der physischen Kamera zurückgeben.

Validierung

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

Diese drei ITS-Tests sind auf Multi-Kamera-Systeme ausgerichtet, um die korrekte Kombination von Bildern zu ermöglichen:

Die Tests für Szene 1 und Szene 4 werden mit dem ITS-in-a-box-Test aufbau ausgeführt. Der Test test_multi_camera_match bestätigt, dass die Helligkeit der Bildmitte übereinstimmt, wenn beide Kameras aktiviert sind. Der Test test_multi_camera_alignment bestätigt, dass die Kameraabstände, ‑ausrichtungen und ‑verzerrungsparameter korrekt geladen werden. Wenn das Multi-Kamera-System eine Kamera mit einem weiten Sichtfeld (> 90°) umfasst, ist die Version 2 der ITS-Box erforderlich.

Sensor_fusion ist ein zweiter Testaufbau, der wiederholte, vorgeschriebene Bewegungen des Smartphones ermöglicht und bestätigt, dass die Zeitstempel des Gyroskops und des Bildsensors übereinstimmen und dass die Multi-Kamera-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. Außerdem kann die 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-Kamera-Geräten voll ausschöpfen und gleichzeitig die App-Kompatibilität beibehalten möchten, sollten Sie bei der Implementierung eines logischen Multi-Kamera-Geräts diese Best Practices beachten:

  • (Android 10 oder höher) Blenden Sie physische Unterkameras in getCameraIdList aus. Dadurch wird die Anzahl der Kameras reduziert, die von Apps direkt geöffnet werden können, sodass keine komplexe Logik zur Kameraauswahl erforderlich ist.
  • (Android 11 oder höher) Implementieren Sie für ein logisches Multi-Kamera Gerät mit optischem Zoom 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 HAL das Koordinatensystem von ANDROID_SCALER_CROP_REGION,ANDROID_CONTROL_AE_REGIONS,ANDROID_CONTROL_AWB_REGIONS,ANDROID_CONTROL_AF_REGIONS,ANDROID_STATISTICS_FACE_RECTANGLESund ANDROID_STATISTICS_FACE_LANDMARKSanpassen, um das Sichtfeld nach dem Zoomen als aktives Sensorarray zu behandeln. Weitere Informationen zur Verwendung von ANDROID_SCALER_CROP_REGION in Kombination mit ANDROID_CONTROL_ZOOM_RATIO, finden Sie unter camera3_crop_reprocess#cropping.
  • Bei Multi-Kamera-Geräten mit physischen Kameras mit unterschiedlichen Funktionen muss das Gerät die Unterstützung für einen bestimmten Wert oder Bereich für ein Steuerelement nur dann bewerben, wenn der Wert oder Bereich vom gesamten Zoombereich unterstützt wird. Wenn die logische Kamera beispielsweise aus einer Ultraweitwinkel-, einer Weitwinkel- und einer Telekamera besteht, gehen Sie so vor:
    • Wenn sich die Größen der aktiven Arrays der physischen Kameras unterscheiden, muss die Kamera-HAL die Zuordnung von den 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 die Telekamera Autofokus unterstützen, die Ultraweitwinkelkamera jedoch einen festen Fokus hat, muss die logische Kamera die Autofokus-Unterstützung bewerben. 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 sie auf das Ultraweitwinkelobjektiv herauszoomt. Außerdem müssen die Autofokus-Zustandsmaschinen für die unterstützten AF-Modi wie erwartet funktionieren.
    • Wenn die Weitwinkel- und die Telekamera 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 4K mit 60 fps nicht in ihren unterstützten Streamkonfigurationen bewerben. So wird die Integrität der Funktionen der logischen Kamera gewährleistet und verhindert, dass die App das Problem hat, dass 4K mit 60 fps bei einem ANDROID_CONTROL_ZOOM_RATIO Wert von weniger als 1 nicht erreicht werden.
  • Unter Android 10 und höher muss eine logische Multi-Kamera keine Streamkombinationen unterstützen, die physische Streams enthalten. Wenn HAL eine Kombination mit physischen Streams unterstützt:
    • (Android 11 oder höher) Um Anwendungsfälle wie die Tiefenmessung mit Stereobildern und die Bewegungserkennung besser zu verarbeiten, muss das Sichtfeld der physischen Streamausgaben so groß wie möglich sein. Wenn ein physischer und ein logischer Stream jedoch von derselben physischen Kamera stammen, können Hardwarebeschränkungen dazu führen, dass das Sichtfeld des physischen Streams mit dem des logischen Streams übereinstimmt.
    • Um den durch mehrere physische Streams verursachten Speicherdruck zu verringern, müssen Apps discardFreeBuffers verwenden, um die kostenlosen Puffer freizugeben (Puffer, die vom Consumer freigegeben, aber noch nicht vom Producer aus der Warteschlange entfernt wurden), wenn ein physischer Stream voraussichtlich für einen bestimmten Zeitraum im Leerlauf ist.
    • Wenn physische Streams von verschiedenen physischen Kameras in der Regel nicht an dieselbe Anfrage angehängt werden, müssen Apps surface group verwenden, damit eine Pufferwarteschlange verwendet wird, um zwei App-seitige Oberflächen zu unterstützen. So wird der Speicherverbrauch reduziert.