HAL-Subsystem

Anfragen

Das App-Framework sendet Anfragen für aufgenommene Ergebnisse an das Kamera-Subsystem. Eine Anfrage entspricht einem Satz von Ergebnissen. Eine Anfrage enthält alle Konfigurationsinformationen zum Erfassen und Verarbeiten dieser Ergebnisse. Dazu gehören unter anderem Auflösung und Pixelformat, manuelle Steuerung von Sensor, Objektiv und Blitz, 3A-Betriebsmodi, Steuerung der RAW-zu-YUV-Verarbeitung und Generierung von Statistiken. So haben Sie viel mehr Kontrolle über die Ausgabe und Verarbeitung der Ergebnisse. Es können mehrere Anfragen gleichzeitig ausgeführt werden. Das Senden von Anfragen ist nicht blockierend. Die Anfragen werden immer in der Reihenfolge ihres Eingangs bearbeitet.

Abbildung 1: Kameramodell

HAL und Kamera-Subsystem

Das Kamerasubsystem umfasst die Implementierungen für Komponenten in der Kamerapipeline, z. B. den 3A-Algorithmus und die Verarbeitungseinstellungen. Das Kamera-HAL bietet Schnittstellen, mit denen Sie Ihre Versionen dieser Komponenten implementieren können. Um die plattformübergreifende Kompatibilität zwischen mehreren Geräteherstellern und Anbietern von Bildsignalprozessoren (ISPs oder Kamerasensoren) aufrechtzuerhalten, ist das Kamerapipeline-Modell virtuell und entspricht nicht direkt einem realen ISP. Sie ähnelt jedoch echten Verarbeitungspipelines so weit, dass Sie sie effizient auf Ihre Hardware abstimmen können. Außerdem ist sie abstrakt genug, um mehrere verschiedene Algorithmen und Operationsreihenfolgen zu ermöglichen, ohne die Qualität, Effizienz oder geräteübergreifende Kompatibilität zu beeinträchtigen.

Die Kamerapipeline unterstützt auch Trigger, die das App-Framework auslösen kann, um Funktionen wie den Autofokus zu aktivieren. Außerdem werden Benachrichtigungen an das App-Framework zurückgesendet, um Apps über Ereignisse wie eine Autofokus-Sperre oder Fehler zu informieren.

Abbildung 2: Kamerapipe

Einige der oben im Diagramm dargestellten Bildverarbeitungsblöcke sind in der ersten Version noch nicht genau definiert. Die Kamerapipeline geht von folgenden Annahmen aus:

• Die RAW-Bayer-Ausgabe wird im ISP nicht verarbeitet.
• Statistiken werden auf Grundlage der Rohsensordaten generiert.
• Die verschiedenen Verarbeitungsblöcke, die Rohsensordaten in YUV konvertieren, sind in einer beliebigen Reihenfolge angeordnet.
• Es werden zwar mehrere Skalierungs- und Zuschneideeinheiten angezeigt, aber alle Skalierungseinheiten verwenden dieselben Steuerelemente für den Ausgabebereich (digitaler Zoom). Jede Einheit kann jedoch eine andere Ausgaberesolution und ein anderes Pixelformat haben.

Zusammenfassung der API-Nutzung
Dies ist eine kurze Zusammenfassung der Schritte zur Verwendung der Android Camera API. Im Abschnitt „Start und erwartete Betriebssequenz“ finden Sie eine detaillierte Aufschlüsselung dieser Schritte, einschließlich API-Aufrufen.

1. Kamerageräte erkennen und auflisten.
2. Öffne das Gerät und verbinde die Kopfhörer.
3. Konfigurieren Sie die Ausgaben für den Zielanwendungsfall (z. B. Standbildaufnahme, Aufzeichnung usw.).
4. Erstellen Sie Anfragen für den Zielanwendungsfall.
5. Anfragen und Bursts erfassen/wiederholen
6. Metadaten und Bilddaten für Ergebnisse empfangen.
7. Wenn Sie den Anwendungsfall wechseln, kehren Sie zu Schritt 3 zurück.

HAL-Vorgangszusammenfassung

• Asynchrone Anfragen für Aufnahmen stammen aus dem Framework.
• HAL-Geräte müssen Anfragen in der Reihenfolge ihrer Eingabe verarbeiten. Für jede Anfrage werden Metadaten für das Ausgaberesultat und ein oder mehrere Ausgabebildpuffer erstellt.
• First-in-first-out-Prinzip für Anfragen und Ergebnisse sowie für Streams, auf die in nachfolgenden Anfragen verwiesen wird.
• Zeitstempel müssen für alle Ausgaben einer bestimmten Anfrage identisch sein, damit das Framework sie bei Bedarf zuordnen kann.
• Die gesamte Erfassungskonfiguration und der gesamte Erfassungsstatus (mit Ausnahme der 3A-Routinen) sind in den Anfragen und Ergebnissen enthalten.

Abbildung 3: Kamera HAL – Übersicht

Start und erwartete Betriebssequenz

In diesem Abschnitt werden die Schritte, die bei der Verwendung der Kamera-API erwartet werden, ausführlich beschrieben. Weitere Informationen zu HIDL-Schnittstellendefinitionen finden Sie unter platform/hardware/interfaces/camera/.

Kamerageräte auflisten, öffnen und eine aktive Sitzung erstellen

1. Nach der Initialisierung beginnt das Framework, auf alle vorhandenen Kameraanbieter zu warten, die die ICameraProvider-Schnittstelle implementieren. Wenn ein solcher Anbieter oder solche Anbieter vorhanden sind, versucht das Framework, eine Verbindung herzustellen.
2. Das Framework listet die Kamerageräte über ICameraProvider::getCameraIdList() auf.
3. Das Framework instanziiert ein neues ICameraDevice durch Aufrufen des entsprechenden ICameraProvider::getCameraDeviceInterface_VX_X().
4. Das Framework ruft ICameraDevice::open() auf, um eine neue aktive Aufnahmesitzung ICameraDeviceSession zu erstellen.

Aktive Kamerasitzung verwenden

1. Das Framework ruft ICameraDeviceSession::configureStreams() mit einer Liste von Ein-/Ausgabestreams für das HAL-Gerät auf.
2. Das Framework fordert mit Aufrufen von ICameraDeviceSession::constructDefaultRequestSettings() Standardeinstellungen für einige Anwendungsfälle an. Das kann jederzeit nach der Erstellung des ICameraDeviceSession durch ICameraDevice::open passieren.
3. Das Framework erstellt und sendet die erste Erfassungsanfrage an die HAL mit Einstellungen, die auf einem der Standardsätze basieren, und mit mindestens einem Ausgabestream, der zuvor vom Framework registriert wurde. Sie wird mit ICameraDeviceSession::processCaptureRequest() an die HAL gesendet. Das HAL muss die Rückgabe dieses Aufrufs blockieren, bis es bereit ist, die nächste Anfrage zu senden.
4. Das Framework sendet weiterhin Anfragen und ruft ICameraDeviceSession::constructDefaultRequestSettings() auf, um bei Bedarf Puffer für Standardeinstellungen für andere Anwendungsfälle abzurufen.
5. Wenn die Aufnahme einer Anfrage beginnt (der Sensor beginnt mit der Belichtung für die Aufnahme), ruft die HAL ICameraDeviceCallback::notify() mit der SHUTTER-Nachricht auf, einschließlich der Framenummer und des Zeitstempels für den Beginn der Belichtung. Dieser Benachrichtigungs-Callback muss nicht vor dem ersten processCaptureResult()-Aufruf für eine Anfrage erfolgen. Ergebnisse werden jedoch erst an eine App für eine Aufnahme gesendet, nachdem notify() für diese Aufnahme aufgerufen wurde.
6. Nach einer gewissen Pipeline-Verzögerung beginnt das HAL, abgeschlossene Aufnahmen mit ICameraDeviceCallback::processCaptureResult() an das Framework zurückzugeben. Sie werden in derselben Reihenfolge zurückgegeben, in der die Anfragen gesendet wurden. Je nach Pipeline-Tiefe des Kamera-HAL-Geräts können mehrere Anfragen gleichzeitig ausgeführt werden.

Nach einiger Zeit geschieht Folgendes:

• Das Framework kann die Übermittlung neuer Anfragen beenden, warten, bis die vorhandenen Aufnahmen abgeschlossen sind (alle Puffer gefüllt, alle Ergebnisse zurückgegeben), und dann ICameraDeviceSession::configureStreams() noch einmal aufrufen. Dadurch werden die Kamera-Hardware und die Pipeline für neue Ein-/Ausgabestreams zurückgesetzt. Einige Streams werden möglicherweise aus der vorherigen Konfiguration wiederverwendet. Das Framework setzt dann mit der ersten Erfassungsanfrage an den HAL fort, sofern mindestens ein registrierter Ausgabestream vorhanden ist. Andernfalls ist zuerst ICameraDeviceSession::configureStreams() erforderlich.
• Das Framework kann ICameraDeviceSession::close() aufrufen, um die Kamerasitzung zu beenden. Diese Funktion kann jederzeit aufgerufen werden, wenn keine anderen Aufrufe des Frameworks aktiv sind. Der Aufruf kann jedoch blockiert werden, bis alle laufenden Aufnahmen abgeschlossen sind (alle Ergebnisse zurückgegeben, alle Puffer gefüllt). Nachdem der close()-Aufruf zurückgegeben wurde, sind keine weiteren Aufrufe von ICameraDeviceCallback über die HAL zulässig. Sobald der close()-Aufruf läuft, darf das Framework keine anderen HAL-Gerätefunktionen aufrufen.
• Im Falle eines Fehlers oder eines anderen asynchronen Ereignisses muss die HAL ICameraDeviceCallback::notify() mit der entsprechenden Fehler-/Ereignismeldung aufrufen. Nachdem die HAL von einer schwerwiegenden geräteweiten Fehlermeldung zurückgekehrt ist, sollte sie sich so verhalten, als wäre close() aufgerufen worden. Das HAL muss jedoch alle ausstehenden Aufnahmen entweder abbrechen oder abschließen, bevor notify() aufgerufen wird. Wenn notify() mit einem schwerwiegenden Fehler aufgerufen wird, erhält das Framework keine weiteren Rückrufe vom Gerät. Andere Methoden als close() sollten -ENODEV oder NULL zurückgeben, nachdem die Methode notify() eine schwerwiegende Fehlermeldung zurückgegeben hat.

Abbildung 4: Ablauf der Kamera

Hardwareebenen

Kamerageräte können je nach ihren Funktionen mehrere Hardwareebenen implementieren. Weitere Informationen finden Sie unter Unterstützte Hardwareebene.

Interaktion zwischen der App-Aufnahmeanfrage, der 3A-Steuerung und der Verarbeitungspipeline

Je nach den Einstellungen im 3A-Steuerblock ignoriert die Kamerapipeline einige der Parameter in der Aufnahmeanfrage der App und verwendet stattdessen die von den 3A-Steuerroutinen bereitgestellten Werte. Wenn beispielsweise die automatische Belichtung aktiv ist, werden die Parameter für Belichtungszeit, Bilddauer und Empfindlichkeit des Sensors vom 3A-Algorithmus der Plattform gesteuert und alle von der App angegebenen Werte werden ignoriert. Die von den 3A-Routinen für den Frame ausgewählten Werte müssen in den Ausgabemetadaten angegeben werden. In der folgenden Tabelle werden die verschiedenen Modi des 3A-Steuerblocks und die Eigenschaften beschrieben, die von diesen Modi gesteuert werden. Definitionen dieser Eigenschaften finden Sie in der Datei platform/system/media/camera/docs/docs.html.

Parameter	Bundesland	Kontrollierte Properties
android.control.aeMode	AUS	Keine
	AN	android.sensor.exposureTime android.sensor.frameDuration android.sensor.sensitivity android.lens.aperture (falls unterstützt) android.lens.filterDensity (falls unterstützt)
	ON_AUTO_FLASH	Alles ist AN, plus android.flash.firingPower, android.flash.firingTime und android.flash.mode
	ON_ALWAYS_FLASH	Wie ON_AUTO_FLASH
	ON_AUTO_FLASH_RED_EYE	Wie ON_AUTO_FLASH
android.control.awbMode	AUS	Keine
	WHITE_BALANCE_*	android.colorCorrection.transform. Plattformspezifische Anpassungen, wenn android.colorCorrection.mode auf FAST oder HIGH_QUALITY festgelegt ist.
android.control.afMode	AUS	Keine
	FOCUS_MODE_*	android.lens.focusDistance
android.control.videoStabilization	AUS	Keine
	AN	android.scaler.cropRegion anpassen, um die Videostabilisierung zu implementieren
android.control.mode	AUS	AE, AWB und AF sind deaktiviert
	AUTO	Es werden individuelle Einstellungen für AE, AWB und AF verwendet.
	SCENE_MODE_*	Kann alle oben aufgeführten Parameter überschreiben. Die einzelnen 3A-Steuerelemente sind deaktiviert.

Die Steuerelemente im Block „Bildverarbeitung“ in Abbildung 2 funktionieren alle nach einem ähnlichen Prinzip. Im Allgemeinen hat jeder Block drei Modi:

• AUS: Dieser Verarbeitungsblock ist deaktiviert. Die Blöcke für Demosaicing, Farbkorrektur und Anpassung der Tonwertkurve können nicht deaktiviert werden.
• SCHNELL: In diesem Modus darf der Verarbeitungsblock die Ausgaberate für Frames im Vergleich zum OFF-Modus nicht verlangsamen, sollte aber ansonsten die bestmögliche Ausgabequalität erzielen. Dies wird in der Regel für Vorschau- oder Videoaufnahmemodi oder für Serienaufnahmen von Standbildern verwendet. Auf einigen Geräten entspricht dies möglicherweise dem OFF-Modus (ohne Verarbeitung, um die Framerate nicht zu verlangsamen), auf anderen Geräten dem HIGH_QUALITY-Modus (beste Qualität, ohne die Framerate zu verlangsamen).
• HIGH_QUALITY: In diesem Modus sollte der Verarbeitungsblock das bestmögliche Ergebnis liefern und die Ausgabebildrate bei Bedarf verlangsamen. Normalerweise wird diese Einstellung für hochwertige Standbilder verwendet. Einige Blöcke enthalten eine manuelle Steuerung, die optional anstelle von FAST oder HIGH_QUALITY ausgewählt werden kann. Der Farbkorrekturblock unterstützt beispielsweise eine Farbtransformationsmatrix, während die Anpassung der Tonwertkurve eine beliebige globale Tonwertzuordnungskurve unterstützt.

Die maximale Bildrate, die von einem Kamerasubsystem unterstützt werden kann, hängt von vielen Faktoren ab:

• Angefragte Auflösungen von Ausgabebildstreams
• Verfügbarkeit von Binning-/Überspringungsmodi auf dem Bildsensor
• Bandbreite der Imager-Schnittstelle
• Die Bandbreite der verschiedenen ISP-Verarbeitungsblöcke

Da diese Faktoren zwischen verschiedenen ISPs und Sensoren stark variieren können, versucht die Kamera-HAL-Schnittstelle, die Bandbreitenbeschränkungen in einem möglichst einfachen Modell zu abstrahieren. Das vorgestellte Modell hat die folgenden Merkmale:

• Der Bildsensor ist immer so konfiguriert, dass er die kleinste Auflösung ausgibt, die bei den angeforderten Ausgabestreamgrößen der App möglich ist. Die kleinste Auflösung muss mindestens so groß sein wie die größte angeforderte Ausgabestreamgröße.
• Da für jede Anfrage einer oder alle der derzeit konfigurierten Ausgabestreams verwendet werden können, müssen der Sensor und der ISP so konfiguriert sein, dass sie die gleichzeitige Skalierung einer einzelnen Aufnahme auf alle Streams unterstützen.
• JPEG-Streams verhalten sich wie verarbeitete YUV-Streams für Anfragen, in denen sie nicht enthalten sind. In Anfragen, in denen direkt auf sie verwiesen wird, verhalten sie sich wie JPEG-Streams.
• Der JPEG-Prozessor kann parallel zum Rest der Kamerapipeline ausgeführt werden, kann aber jeweils nur einen Capture verarbeiten.