HAL-Subsystem

Auf dieser Seite werden das HAL-Subsystem, einschließlich Anfragen, das Kamera-Subsystem, die Start- und Betriebssequenz, Hardwareebenen und Interaktionen beschrieben.

Anfragen

Das App-Framework sendet Anfragen nach erfassten Ergebnissen an das Kamera-Subsystem. Eine Anfrage entspricht einem Satz von Ergebnissen. Eine Anfrage umfasst alle Konfigurationsinformationen zur Erfassung und Verarbeitung 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 Statistikerstellung. Dadurch haben Sie viel mehr Kontrolle über die Ausgabe und Verarbeitung der Ergebnisse. Es können mehrere Anfragen gleichzeitig ausgeführt werden und das Senden von Anfragen ist nicht blockierend. Die Anfragen werden immer in der Reihenfolge verarbeitet, in der sie eingehen.

Abbildung 1 : Kameramodell.

HAL- und Kamera-Subsystem

Das Kamera-Subsystem umfasst die Implementierungen für Komponenten in der Kamera Pipeline, z. B. den 3A-Algorithmus und die Verarbeitungssteuerung. Die 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 (Image Signal Processor, ISP oder Kamerasensor) aufrechtzuerhalten, ist das Kamerapipeline-Modell virtuell und entspricht nicht direkt einem realen ISP. Es ähnelt jedoch echten Verarbeitungspipelines, sodass Sie es effizient Ihrer Hardware zuordnen können. Außerdem ist es abstrakt genug, um mehrere verschiedene Algorithmen und Betriebsreihenfolgen 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 initiieren 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 : Kamerapipeline.

Einige in der Abbildung oben gezeigte Bildverarbeitungsblöcke sind in der ersten Version nicht genau definiert. Die Kamerapipeline geht von folgenden Annahmen aus:

• Die RAW-Bayer-Ausgabe wird im ISP nicht verarbeitet.
• Statistiken werden auf der Grundlage der Rohsensordaten erstellt.
• Die verschiedenen Verarbeitungsblöcke, die Rohsensordaten in YUV umwandeln, sind in einer beliebigen Reihenfolge angeordnet.
• Obwohl mehrere Skalierungs- und Zuschneideeinheiten angezeigt werden, verwenden alle Skalierungseinheiten die gleichen Steuerelemente für den Ausgabebereich (digitaler Zoom). Jede Einheit kann jedoch eine andere Ausgabeauflösung 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. Nach Kamerageräten suchen und diese auflisten.
2. Gerät öffnen und Listener verbinden.
3. Ausgaben für den Zielanwendungsfall konfigurieren (z. B. Standbildaufnahme oder Aufzeichnung).
4. Anfragen für den Zielanwendungsfall erstellen.
5. Anfragen und Serienaufnahmen erfassen/wiederholen.
6. Metadaten und Bilddaten des Ergebnisses empfangen.
7. Beim Wechsel des Anwendungsfalls zu Schritt 3 zurückkehren.

Zusammenfassung des HAL-Betriebs

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

Abbildung 3 : Übersicht über die Kamera-HAL.

Start- und erwartete Betriebssequenz

In diesem Abschnitt wird detailliert beschrieben, welche Schritte bei der Verwendung der Camera API erwartet werden. HIDL-Schnittstellendefinitionen finden Sie unter platform/hardware/interfaces/camera/.

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

1. Nach der Initialisierung sucht das Framework nach allen vorhandenen Kameraanbietern, die die ICameraProvider Schnittstelle implementieren. Wenn ein oder mehrere 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 Aufruf 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 Eingabe-/Ausgabestreams für das HAL-Gerät auf.
2. Das Framework fordert Standardeinstellungen für einige Anwendungsfälle mit Aufrufen von ICameraDeviceSession::constructDefaultRequestSettings an. Dies kann jederzeit erfolgen, nachdem die ICameraDeviceSession von ICameraDevice::open erstellt wurde.
3. Das Framework erstellt die erste Aufnahme-Anfrage und sendet sie an die HAL. Die Einstellungen basieren auf einem der Standardsätze und enthalten mindestens einen Ausgabestream, der zuvor vom Framework registriert wurde. Sie wird an die HAL mit ICameraDeviceSession::processCaptureRequest gesendet. Die HAL muss die Rückgabe dieses Aufrufs blockieren, bis sie bereit ist, die nächste Anfrage zu empfangen.
4. Das Framework sendet weiterhin Anfragen und ruft ICameraDeviceSession::constructDefaultRequestSettings auf, um Standardeinstellungspuffer für andere Anwendungsfälle abzurufen.
5. Wenn die Aufnahme einer Anfrage beginnt (der Sensor wird für die Aufnahme freigelegt), ruft die HAL ICameraDeviceCallback::notify mit der Nachricht SHUTTER auf, einschließlich der Frame-Nummer 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 gesendet, nachdem notify für diese Aufnahme aufgerufen wurde.
6. Nach einer gewissen Pipeline-Verzögerung beginnt die HAL, abgeschlossene Aufnahmen an das Framework mit ICameraDeviceCallback::processCaptureResult zurückzugeben. Diese 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 tritt einer der folgenden Fälle ein:

• Das Framework sendet keine neuen Anfragen mehr, wartet, bis die vorhandenen Aufnahmen abgeschlossen sind (alle Puffer gefüllt, alle Ergebnisse zurückgegeben), und ruft dann ICameraDeviceSession::configureStreams noch einmal auf. Dadurch werden die Kamera-Hardware und die Pipeline für einen neuen Satz von Eingabe-/Ausgabestreams zurückgesetzt. Einige Streams können aus der vorherigen Konfiguration wiederverwendet werden. Das Framework fährt dann mit der ersten Aufnahme-Anfrage an die HAL fort, wenn mindestens ein registrierter Ausgabestream vorhanden ist. Andernfalls ist zuerst ICameraDeviceSession::configureStreams erforderlich.
• Das Framework kann ICameraDeviceSession::close aufrufen, um die Kamerasitzung zu beenden. Dieser Aufruf kann jederzeit erfolgen, wenn keine anderen Aufrufe vom Framework aktiv sind. Der Aufruf wird jedoch möglicherweise blockiert, 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 von der HAL zulässig. Sobald der close Aufruf ausgeführt wird, kann 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-/Ereignisnachricht aufrufen. Nach der Rückgabe von einer schwerwiegenden geräteweiten Fehlermeldung sollte sich die HAL so verhalten, als ob close aufgerufen worden wäre. Die HAL muss jedoch alle ausstehenden Aufnahmen abbrechen oder abschließen, bevor sie notify aufruft, damit das Framework nach dem Aufruf von notify mit einem schwerwiegenden Fehler keine weiteren Callbacks vom Gerät erhält. Andere Methoden als close sollten -ENODEV oder NULL zurückgeben, nachdem die notify-Methode eine schwerwiegende Fehlermeldung zurückgegeben hat.

Abbildung 4 : Operativer Ablauf der Kamera.

Hardwareebenen

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

Interaktion zwischen der Aufnahme-Anfrage der App, der 3A-Steuerung und der Verarbeitungspipeline

Je nach den Einstellungen im 3A-Steuerungsblock ignoriert die Kamerapipeline einige der Parameter in der Aufnahme-Anfrage der App und verwendet stattdessen die von den 3A-Steuerungsroutinen bereitgestellten Werte. Wenn beispielsweise die automatische Belichtung aktiv ist, werden die Parameter für Belichtungszeit, Framedauer und Empfindlichkeit des Sensors vom 3A-Algorithmus der Plattform gesteuert und alle von der App angegebenen Werte werden ignoriert. Die für den Frame von den 3A-Routinen ausgewählten Werte müssen in den Ausgabemetadaten angegeben werden. In der folgenden Tabelle werden die verschiedenen Modi des 3A-Steuerungsblocks 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	Status	Gesteuerte Eigenschaften
android.control.aeMode	OFF	Keine.
	ON	android.sensor.exposureTime, android.sensor.frameDuration, android.sensor.sensitivity, android.lens.aperture (if supported), and android.lens.filterDensity (if supported).
	ON_AUTO_FLASH	Alles ist ON plus android.flash.firingPower, android.flash.firingTime und android.flash.mode.
	ON_ALWAYS_FLASH	Gleich wie ON_AUTO_FLASH.
	ON_AUTO_FLASH_RED_EYE	Gleich wie ON_AUTO_FLASH.
android.control.awbMode	OFF	Keine.
	WHITE_BALANCE_*	android.colorCorrection.transform. Plattformspezifische Anpassungen, wenn android.colorCorrection.mode FAST oder HIGH_QUALITY ist.
android.control.afMode	OFF	Keine
	FOCUS_MODE_*	android.lens.focusDistance
android.control.videoStabilization	OFF	Keine.
	ON	android.scaler.cropRegion kann angepasst werden, um die Videostabilisierung zu implementieren.
android.control.mode	OFF	AE, AWB und AF sind deaktiviert.
	AUTO	Es werden individuelle AE-, AWB- und AF-Einstellungen verwendet.
	SCENE_MODE_*	Kann alle oben aufgeführten Parameter überschreiben. Individuelle 3A-Steuerelemente sind deaktiviert.

Die Steuerelemente im Bildverarbeitungsblock in Abbildung 2 funktionieren alle nach einem ähnlichen Prinzip und jeder Block hat drei Modi:

• OFF: Dieser Verarbeitungsblock ist deaktiviert. Die Blöcke für Demosaicing, Farbkorrektur und Tonkurvenanpassung können nicht deaktiviert werden.
• FAST: In diesem Modus verlangsamt der Verarbeitungsblock die Ausgabebildrate im Vergleich zum Modus OFF möglicherweise nicht, sollte aber ansonsten die bestmögliche Ausgabequalität erzielen. Dieser Modus wird in der Regel für die Vorschau oder Videoaufzeichnung oder für Serienaufnahmen von Standbildern verwendet. Auf einigen Geräten entspricht dieser Modus möglicherweise dem Modus OFF (ohne Verlangsamung der Bildrate ist keine Verarbeitung möglich) und auf einigen Geräten dem Modus HIGH_QUALITY (beste Qualität verlangsamt die Bildrate nicht).
• HIGH_QUALITY: In diesem Modus sollte der Verarbeitungsblock das bestmögliche Ergebnis erzielen und die Ausgabebildrate bei Bedarf verlangsamen. Dieser Modus wird in der Regel für hochwertige Standbildaufnahmen verwendet. Einige Blöcke enthalten ein manuelles Steuerelement, das optional anstelle von FAST oder HIGH_QUALITY ausgewählt werden kann. Der Farbkorrekturblock unterstützt beispielsweise eine Farb Transformationsmatrix, während die Tonkurvenanpassung eine beliebige globale Tonzuordnungskurve unterstützt.

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

• Angefragte Auflösungen der Ausgabebildstreams
• Verfügbarkeit von Binning-/Skipping-Modi auf dem Imager
• Bandbreite der Imager-Schnittstelle
• Bandbreite der verschiedenen ISP-Verarbeitungsblöcke

Diese Faktoren können je nach ISP und Sensor stark variieren. Daher versucht die Kamera-HAL-Schnittstelle, die Bandbreitenbeschränkungen in einem möglichst einfachen Modell zu abstrahieren. Das vorgestellte Modell hat folgende Merkmale:

• Der Bildsensor ist immer so konfiguriert, dass er die kleinstmögliche Auflösung ausgibt, die für die angefragten Ausgabestreamgrößen der App erforderlich ist. Die kleinste Auflösung muss mindestens so groß sein wie die größte angefragte Ausgabestreamgröße.
• Jede Anfrage kann einen oder alle derzeit konfigurierten Ausgabestreams verwenden, daher müssen Sensor und ISP so konfiguriert werden, dass sie eine einzelne Aufnahme gleichzeitig auf alle Streams skalieren können.
• 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 gleichzeitig mit dem Rest der Kamerapipeline ausgeführt werden, kann aber nicht mehr als eine Aufnahme gleichzeitig verarbeiten.