Diese Seite wurde von der Cloud Translation API übersetzt.

HAL-Subsystem

Anfragen

Das App-Framework sendet Anfragen an das Kamera-Subsystem. Eine Anfrage entspricht einem Ergebnissatz. Eine Anfrage enthält alle Konfigurationsinformationen zum Erfassen und Verarbeiten dieser Ergebnisse. Dazu gehören unter anderem Auflösung und Pixelformat, manuelle Sensor-, Objektiv- und Blitzsteuerung, 3A-Betriebsmodi, Steuerung der RAW-zu-YUV-Verarbeitung und Statistikerstellung. So haben Sie viel mehr Kontrolle über die Ausgabe und Verarbeitung der Ergebnisse. Es können mehrere Anfragen gleichzeitig gesendet werden und das Einreichen 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 Kamerapipeline, z. B. den 3A-Algorithmus und Verarbeitungssteuerungen. Die Kamera-HAL bietet Schnittstellen, über die Sie Ihre Versionen dieser Komponenten implementieren können. Um die plattformübergreifende Kompatibilität zwischen mehreren Geräteherstellern und Anbietern von Bildsignalprozessoren (ISP, oder Kamerasensoren) aufrechtzuerhalten, ist das Kamerapipeline-Modell virtuell und entspricht nicht direkt einem realen ISP. Sie ähnelt jedoch realen Verarbeitungspipelines so weit, dass Sie sie effizient auf Ihre Hardware abbilden können. Außerdem ist es abstrakt genug, um mehrere unterschiedliche Algorithmen und Befehlsfolgen zuzulassen, ohne die Qualität, Effizienz oder geräteübergreifende Kompatibilität zu beeinträchtigen.

Die Kamerapipeline unterstützt auch Trigger, die vom App-Framework initiiert werden können, um beispielsweise den Autofokus zu aktivieren. Außerdem sendet er Benachrichtigungen an das App-Framework zurück, um Apps über Ereignisse wie eine automatische Fokussperre oder Fehler zu informieren.

Abbildung 2: Kamerapipeline

Einige der im Diagramm oben dargestellten Blöcke für die Bildverarbeitung sind in der ersten Version nicht klar definiert. Bei der Kamerapipeline werden folgende Annahmen getroffen:

Die RAW-Bayer-Ausgabe wird im ISP nicht verarbeitet.
Statistiken werden anhand der Rohdaten der Sensoren generiert.
Die verschiedenen Verarbeitungsblöcke, die Rohsensordaten in YUV umwandeln, sind in einer beliebigen Reihenfolge angeordnet.
Es werden zwar mehrere Skalierungs- und Zuschneideeinheiten angezeigt, aber alle Skalierungseinheiten haben dieselben Steuerelemente für die Ausgaberegion (digitaler Zoom). Jede Einheit kann jedoch eine andere Ausgabeauflösung und ein anderes Pixelformat haben.

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

Kamerageräte suchen und auflisten
Öffnen Sie das Gerät und verbinden Sie die Zuhörer.
Konfigurieren Sie die Ausgabe für den gewünschten Anwendungsfall (z. B. Standbildaufnahme, Aufzeichnung usw.).
Erstellen Sie Anfragen für den Ziel-Use-Case.
Anfragen und Bursts erfassen/wiederholen
Sie erhalten Ergebnismetadaten und Bilddaten.
Wenn Sie den Anwendungsfall wechseln, kehren Sie zu Schritt 3 zurück.

HAL-Betrieb – Zusammenfassung

Asynchrone Anfragen für Aufnahmen stammen aus dem Framework.
Das HAL-Gerät muss Anfragen in der richtigen Reihenfolge verarbeiten. Außerdem müssen Sie für jede Anfrage Ausgabeergebnismetadaten und einen oder mehrere Ausgabebild-Buffer generieren.
„First-In, First-Out“ 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 das Framework sie bei Bedarf zusammenführen kann.
Die gesamte Erfassungskonfiguration und der Status (mit Ausnahme der 3A-Routinen) sind in den Anfragen und Ergebnissen gekapselt.

Abbildung 3: Kamera HAL – Übersicht

Start und erwartete Betriebsabfolge

In diesem Abschnitt wird ausführlich beschrieben, welche Schritte bei der Verwendung der Kamera-API erforderlich sind. Definitionen der HIDL-Schnittstellen finden Sie unter platform/hardware/interfaces/camera/.

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

Nach der Initialisierung beginnt das Framework, auf vorhandene Kameraanbieter zu warten, die die ICameraProvider-Schnittstelle implementieren. Wenn ein solcher Anbieter vorhanden ist, versucht das Framework, eine Verbindung herzustellen.
Das Framework zählt die Kamerageräte über ICameraProvider::getCameraIdList() auf.
Das Framework erstellt eine neue ICameraDevice, indem es die entsprechende ICameraProvider::getCameraDeviceInterface_VX_X() aufruft.
Das Framework ruft ICameraDevice::open() auf, um eine neue aktive Aufnahmesitzung ICameraDeviceSession zu erstellen.

Aktive Kamerasitzung verwenden

Das Framework ruft ICameraDeviceSession::configureStreams() mit einer Liste von Eingabe-/Ausgabestreams zum HAL-Gerät auf.
Das Framework fordert für einige Anwendungsfälle Standardeinstellungen mit Aufrufen von ICameraDeviceSession::constructDefaultRequestSettings() an. Das kann jederzeit nach der Erstellung der ICameraDeviceSession durch ICameraDevice::open geschehen.
Das Framework erstellt und sendet die erste Aufnahmeanfrage an die HAL mit Einstellungen, die auf einem der Standardeinstellungen basieren, und mit mindestens einem Ausgabestream, der zuvor vom Framework registriert wurde. Dieser wird mit ICameraDeviceSession::processCaptureRequest() an die HAL gesendet. Der HAL muss die Rückgabe dieses Aufrufs blockieren, bis er für das Senden der nächsten Anfrage bereit ist.
Das Framework sendet weiterhin Anfragen und ruft ICameraDeviceSession::constructDefaultRequestSettings() auf, um bei Bedarf Standardeinstellungen für andere Anwendungsfälle abzurufen.
Wenn die Aufnahme einer Anfrage beginnt (der Sensor beginnt mit der Belichtung für die Aufnahme), ruft der HAL ICameraDeviceCallback::notify() mit der SHUTTER-Nachricht auf, einschließlich der Frame-Nummer und des Zeitstempels für den Beginn der Belichtung. Dieser 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.
Nach einer gewissen Pipelineverzögerung beginnt die HAL, abgeschlossene Aufnahmen mit ICameraDeviceCallback::processCaptureResult() an das Framework zurückzugeben. Sie werden in der Reihenfolge zurückgegeben, in der die Anfragen gesendet wurden. Je nach Pipelinetiefe des HAL-Geräts der Kamera können mehrere Anfragen gleichzeitig gesendet werden.

Nach einiger Zeit geschieht Folgendes:

Das Framework kann das Einreichen neuer Anfragen beenden, warten, bis die vorhandenen Erfassungen abgeschlossen sind (alle Puffer gefüllt, alle Ergebnisse zurückgegeben), und dann ICameraDeviceSession::configureStreams() noch einmal aufrufen. Dadurch werden die Kamerahardware und die Pipeline für neue Eingabe-/Ausgabestreams zurückgesetzt. Einige Streams können aus der vorherigen Konfiguration wiederverwendet werden. Das Framework fährt dann von der ersten Aufnahmeanfrage zur HAL fort, sofern mindestens ein registrierter Ausgabestream vorhanden ist. Andernfalls ist zuerst ICameraDeviceSession::configureStreams() erforderlich.
Das Framework ruft möglicherweise ICameraDeviceSession::close() auf, um die Kamerasitzung zu beenden. Dieser kann jederzeit aufgerufen werden, wenn keine anderen Aufrufe aus dem Framework aktiv sind. Der Aufruf kann jedoch blockiert werden, bis alle laufenden Erfassungen abgeschlossen sind (alle Ergebnisse zurückgegeben, alle Puffer gefüllt). Nachdem der close()-Aufruf zurückgegeben wurde, sind keine weiteren Aufrufe von ICameraDeviceCallback aus der HAL zulässig. Sobald der close()-Aufruf gestartet wurde, ruft das Framework möglicherweise keine anderen HAL-Gerätefunktionen auf.
Bei einem Fehler oder einem anderen asynchronen Ereignis muss die HAL ICameraDeviceCallback::notify() mit der entsprechenden Fehler-/Ereignismeldung aufrufen. Nach dem Zurückkehren von einer geräteweiten Fehlerbenachrichtigung sollte die HAL so reagieren, als wäre close() darauf aufgerufen worden. Die HAL muss jedoch alle ausstehenden Aufnahmen entweder abbrechen oder abschließen, bevor notify() aufgerufen wird. Andernfalls erhält das Framework nach dem Aufruf von notify() mit einem schwerwiegenden Fehler keine weiteren Rückrufe vom Gerät. Methoden, die nicht close() sind, sollten -ENODEV oder NULL zurückgeben, nachdem die Methode notify() eine fatale 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-Kontrolle 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 Werte, die von den 3A-Steuerroutinen bereitgestellt werden. Wenn beispielsweise die automatische Belichtung aktiviert ist, werden die Belichtungszeit, die Framedauer und die Empfindlichkeitsparameter 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	Verwaltete 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	Alle Funktionen sind aktiviert, einschließlich android.flash.firingPower, android.flash.firingTime und android.flash.mode.
	ON_ALWAYS_FLASH	Entspricht ON_AUTO_FLASH
	ON_AUTO_FLASH_RED_EYE	Entspricht ON_AUTO_FLASH
android.control.awbMode	AUS	Keine
	WHITE_BALANCE_*	android.colorCorrection.transform. Plattformspezifische Anpassungen, wenn android.colorCorrection.mode „FAST“ oder „HIGH_QUALITY“ ist.
android.control.afMode	AUS	Keine
	FOCUS_MODE_*	android.lens.focusDistance
android.control.videoStabilization	AUS	Keine
	AN	android.scaler.cropRegion kann angepasst werden, um die Videostabilisierung zu implementieren
android.control.mode	AUS	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. Die einzelnen 3A-Steuerungen 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 die Demosaikierung, Farbkorrektur und Tonwertkurve können nicht deaktiviert werden.
SCHNELL: In diesem Modus verlangsamt der Verarbeitungsblock die Ausgabeframerate im Vergleich zum Modus „AUS“ möglicherweise nicht. Unter Berücksichtigung dieser Einschränkung sollte er jedoch die bestmögliche Ausgabequalität liefern. Normalerweise wird dies für die Vorschau oder die Videoaufzeichnung oder für die Serienaufnahme von Standbildern verwendet. Auf einigen Geräten entspricht dies dem Modus „AUS“ (ohne Verlangsamung der Framerate kann keine Verarbeitung erfolgen) und auf einigen Geräten dem Modus „HIGH_QUALITY“ (die Framerate wird bei der besten Qualität nicht verlangsamt).
HIGH_QUALITY: In diesem Modus sollte der Verarbeitungsblock das bestmögliche Ergebnis in Bezug auf die Qualität liefern und die Ausgabeframerate bei Bedarf verlangsamen. Normalerweise wird diese Einstellung für die Aufnahme hochwertiger Standbilder verwendet. Einige Blöcke enthalten eine manuelle Steuerung, die anstelle von „SCHNELL“ oder „HOHE_QUALITÄT“ ausgewählt werden kann. Der Block „Farbkorrektur“ unterstützt beispielsweise eine Farbtransformationsmatrix, während die Tonkurve eine beliebige globale Tonmapping-Kurve unterstützt.

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

Angeforderte Auflösungen von Ausgabebildstreams
Verfügbarkeit von Bin-/Überspringungsmodi auf dem Bildsensor
Die Bandbreite der Bilderfassungsschnittstelle
Die Bandbreite der verschiedenen Verarbeitungsblöcke des Internetanbieters

Da diese Faktoren zwischen verschiedenen Internetanbietern und Sensoren stark variieren können, werden die Bandbreiteneinschränkungen in der HAL-Schnittstelle der Kamera in einem möglichst einfachen Modell abstrahiert. Das vorgestellte Modell hat folgende Merkmale:

Der Bildsensor ist immer so konfiguriert, dass die kleinstmögliche Auflösung ausgegeben wird, die den angeforderten Ausgabestreamgrößen der App entspricht. Die kleinste Auflösung muss mindestens so groß wie die größte angeforderte Ausgabestreamgröße sein.
Da für jede Anfrage beliebige oder alle derzeit konfigurierten Ausgabestreams verwendet werden können, müssen der Sensor und der Internetanbieter so konfiguriert sein, dass eine einzelne Aufnahme gleichzeitig auf alle Streams skaliert werden kann.
JPEG-Streams verhalten sich bei Anfragen, in denen sie nicht enthalten sind, wie verarbeitete YUV-Streams. Bei Anfragen, in denen sie direkt referenziert werden, verhalten sie sich wie JPEG-Streams.
Der JPEG-Prozessor kann parallel zur restlichen Kamerapipeline ausgeführt werden, aber nicht mehr als eine Aufnahme gleichzeitig verarbeiten.