HAL-Subsystem

Anfragen

Das App-Framework sendet Anfragen nach erfassten Ergebnissen an das Kamera-Subsystem. Eine Anfrage entspricht einem Ergebnissatz. Eine Anfrage fasst alle Konfigurationsinformationen zur Erfassung und Verarbeitung dieser Ergebnisse zusammen. Dazu gehören Dinge wie Auflösung und Pixelformat; manuelle Sensor-, Objektiv- und Blitzsteuerung; 3A-Betriebsarten; RAW-zu-YUV-Verarbeitungssteuerung; und Statistikerstellung. Dies ermöglicht eine wesentlich bessere Kontrolle über die Ausgabe und Verarbeitung der Ergebnisse. Es können mehrere Anfragen gleichzeitig im Umlauf sein und die Übermittlung von Anfragen erfolgt nicht blockierend. Und die Anfragen werden immer in der Reihenfolge ihres Eingangs bearbeitet.

Abbildung 1. Kameramodell

Das HAL- und Kamera-Subsystem

Das Kamera-Subsystem umfasst die Implementierungen für Komponenten in der Kamera-Pipeline wie den 3A-Algorithmus und Verarbeitungssteuerungen. Die Kamera-HAL bietet Schnittstellen für die Implementierung Ihrer Versionen dieser Komponenten. Um die plattformübergreifende Kompatibilität zwischen mehreren Geräteherstellern und Anbietern von Bildsignalprozessoren (ISP oder Kamerasensoren) aufrechtzuerhalten, ist das Kamera-Pipeline-Modell virtuell und entspricht nicht direkt einem realen ISP. Es ist jedoch echten Verarbeitungspipelines so ähnlich, dass Sie es effizient Ihrer Hardware zuordnen können. Darüber hinaus ist es abstrakt genug, um mehrere verschiedene Algorithmen und Betriebsreihenfolgen zu ermöglichen, ohne dass Qualität, Effizienz oder geräteübergreifende Kompatibilität beeinträchtigt werden.

Die Kamerapipeline unterstützt auch Auslöser, die das App-Framework initiieren kann, um Dinge wie den Autofokus zu aktivieren. Außerdem sendet es Benachrichtigungen zurück an das App-Framework und benachrichtigt Apps über Ereignisse wie eine Autofokus-Sperre oder Fehler.

Abbildung 2. Kamerapipeline

Bitte beachten Sie, dass einige im Diagramm oben gezeigte Bildverarbeitungsblöcke in der ersten Version nicht genau definiert sind. Die Kamerapipeline geht von folgenden Annahmen aus:

• Die RAW-Bayer-Ausgabe wird im ISP nicht verarbeitet.
• Statistiken werden basierend auf den rohen Sensordaten erstellt.
• Die verschiedenen Verarbeitungsblöcke, die rohe Sensordaten in YUV konvertieren, sind in willkürlicher Reihenfolge angeordnet.
• Während mehrere Skalierungs- und Zuschneideeinheiten angezeigt werden, teilen sich alle Skalierungseinheiten die Steuerelemente für den Ausgabebereich (Digitalzoom). Allerdings kann jede Einheit eine andere Ausgabeauflösung und ein anderes Pixelformat haben.

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

1. Hören Sie auf Kamerageräte und zählen Sie sie auf.
2. Gerät öffnen und Zuhörer verbinden.
3. Konfigurieren Sie Ausgaben für den Zielanwendungsfall (z. B. Standbildaufnahme, Aufzeichnung usw.).
4. Erstellen Sie eine oder mehrere Anfragen für den Zielanwendungsfall.
5. Anforderungen und Bursts erfassen/wiederholen.
6. Erhalten Sie Ergebnismetadaten und Bilddaten.
7. Wenn Sie den Anwendungsfall wechseln, kehren Sie zu Schritt 3 zurück.

Zusammenfassung der HAL-Operation

• Asynchrone Anforderungen für Erfassungen kommen vom Framework.
• Das HAL-Gerät muss die Anfragen in der richtigen Reihenfolge verarbeiten. Und erzeugen Sie für jede Anfrage Ausgabeergebnismetadaten und einen oder mehrere Ausgabebildpuffer.
• First-In, First-Out für Anfragen und Ergebnisse sowie für Streams, auf die von nachfolgenden Anfragen verwiesen wird.
• 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 gesamte Erfassungsstatus (mit Ausnahme der 3A-Routinen) sind in den Anforderungen und Ergebnissen gekapselt.

Abbildung 3. Kamera-HAL-Übersicht

Start und erwartete Betriebssequenz

Dieser Abschnitt enthält eine detaillierte Erläuterung der Schritte, die bei der Verwendung der Kamera-API zu erwarten sind. Die HIDL-Schnittstellendefinitionen finden Sie unter platform/hardware/interfaces/camera/ .

Aufzählen, Kamerageräte ö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 oder mehrere solche Anbieter vorhanden sind, versucht das Framework, eine Verbindung herzustellen.
2. Das Framework zählt die Kamerageräte über ICameraProvider::getCameraIdList() auf.
3. Das Framework instanziiert ein neues ICameraDevice , indem es das entsprechende ICameraProvider::getCameraDeviceInterface_VX_X() aufruft.
4. Das Framework ruft ICameraDevice::open() auf, um eine neue aktive Aufnahmesitzung ICameraDeviceSession zu erstellen.

Verwendung einer aktiven Kamerasitzung

1. Das Framework ruft ICameraDeviceSession::configureStreams() mit einer Liste von Eingabe-/Ausgabestreams zum HAL-Gerät auf.
2. Das Framework fordert für einige Anwendungsfälle Standardeinstellungen mit Aufrufen von ICameraDeviceSession::constructDefaultRequestSettings() an. Dies kann jederzeit nach der Erstellung der ICameraDeviceSession durch ICameraDevice::open auftreten.
3. Das Framework erstellt und sendet die erste Erfassungsanforderung an die HAL mit Einstellungen, die auf einem der Standardeinstellungssätze basieren, und mit mindestens einem Ausgabestream, der zuvor vom Framework registriert wurde. Dies wird mit ICameraDeviceSession::processCaptureRequest() an die HAL gesendet. Der HAL muss die Rückkehr dieses Aufrufs blockieren, bis er für das Senden der nächsten Anfrage bereit ist.
4. Das Framework sendet weiterhin Anfragen und ruft ICameraDeviceSession::constructDefaultRequestSettings() auf, um bei Bedarf Standardeinstellungspuffer 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 Bildnummer und des Zeitstempels für den Beginn der Aufnahme. Dieser Benachrichtigungsrückruf muss nicht vor dem ersten Aufruf processCaptureResult() für eine Anforderung erfolgen, es werden jedoch keine Ergebnisse für eine Erfassung an eine Anwendung übermittelt, bis notify() für diese Erfassung aufgerufen wurde.
6. Nach einer gewissen Pipeline-Verzögerung beginnt die HAL mit der Rückgabe abgeschlossener Erfassungen an das Framework mit ICameraDeviceCallback::processCaptureResult() . Diese werden in derselben Reihenfolge zurückgegeben, in der die Anfragen eingereicht wurden. Abhängig von der Pipeline-Tiefe des Kamera-HAL-Geräts können mehrere Anforderungen gleichzeitig ausgeführt werden.

Nach einiger Zeit wird eines der folgenden Ereignisse auftreten:

• Das Framework stoppt möglicherweise die Übermittlung neuer Anforderungen, wartet, bis die vorhandenen Erfassungen abgeschlossen sind (alle Puffer gefüllt, alle Ergebnisse zurückgegeben) und ruft dann ICameraDeviceSession::configureStreams() erneut auf. Dadurch werden die Kamerahardware 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 von der ersten Erfassungsanforderung bis zum HAL fort, wenn mindestens ein registrierter Ausgabestream übrig bleibt. (Andernfalls ist zuerst ICameraDeviceSession::configureStreams() erforderlich.)
• Das Framework kann ICameraDeviceSession::close() aufrufen, um die Kamerasitzung zu beenden. Dies kann jederzeit aufgerufen werden, wenn keine anderen Aufrufe vom Framework aktiv sind, obwohl der Aufruf blockieren kann, bis alle laufenden Erfassungen abgeschlossen sind (alle Ergebnisse zurückgegeben, alle Puffer gefüllt). Nach der Rückkehr des close() Aufrufs sind keine weiteren Aufrufe von ICameraDeviceCallback von der HAL zulässig. Sobald der Aufruf close() ausgeführt wird, ruft das Framework möglicherweise keine anderen HAL-Gerätefunktionen mehr auf.
• Im Falle eines Fehlers oder eines anderen asynchronen Ereignisses muss die HAL ICameraDeviceCallback::notify() mit der entsprechenden Fehler-/Ereignismeldung aufrufen. Nach der Rückkehr von einer schwerwiegenden geräteweiten Fehlerbenachrichtigung sollte sich die HAL so verhalten, als ob close() für sie aufgerufen worden wäre. Allerdings muss die HAL vor dem Aufruf notify() alle ausstehenden Erfassungen entweder abbrechen oder abschließen, sodass das Framework nach dem Aufruf notify() mit einem schwerwiegenden Fehler keine weiteren Rückrufe vom Gerät erhält. Methoden außer close() sollten -ENODEV oder NULL zurückgeben, nachdem die notify() Methode eine schwerwiegende Fehlermeldung zurückgibt.

Abbildung 4. Betriebsablauf der Kamera

Hardware-Ebenen

Kamerageräte können je nach Leistungsfähigkeit mehrere Hardwarestufen implementieren. Weitere Informationen finden Sie unter Unterstützte Hardwarestufe .

Interaktion zwischen der Anwendungserfassungsanforderung, der 3A-Steuerung und der Verarbeitungspipeline

Abhängig von den Einstellungen im 3A-Steuerblock ignoriert die Kamerapipeline einige Parameter in der Erfassungsanforderung der Anwendung und verwendet stattdessen die von den 3A-Steuerroutinen bereitgestellten Werte. Wenn beispielsweise die automatische Belichtung aktiv ist, werden Belichtungszeit, Bilddauer und Empfindlichkeitsparameter des Sensors durch den Plattform-3A-Algorithmus 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. Die folgende Tabelle beschreibt die verschiedenen Modi des 3A-Steuerblocks und die Eigenschaften, die von diesen Modi gesteuert werden. Definitionen dieser Eigenschaften finden Sie in der Datei „platform/system/media/camera/docs/docs.html“ .

Die Steuerelemente im Bildverarbeitungsblock in Abbildung 2 funktionieren alle nach einem ähnlichen Prinzip und im Allgemeinen verfügt jeder Block über drei Modi:

• AUS: Dieser Verarbeitungsblock ist deaktiviert. Die Blöcke Demosaic, Farbkorrektur und Tonkurvenanpassung können nicht deaktiviert werden.
• SCHNELL: In diesem Modus verlangsamt der Verarbeitungsblock möglicherweise nicht die Ausgabebildrate im Vergleich zum AUS-Modus, sollte aber ansonsten aufgrund dieser Einschränkung die bestmögliche Ausgabequalität erzeugen. Typischerweise wird dies für Vorschau- oder Videoaufzeichnungsmodi oder für die Serienaufnahme von Standbildern verwendet. Auf einigen Geräten entspricht dies möglicherweise dem AUS-Modus (es kann keine Verarbeitung durchgeführt werden, ohne die Bildrate zu verlangsamen), und auf einigen Geräten entspricht dies möglicherweise dem HIGH_QUALITY-Modus (die beste Qualität führt immer noch nicht zu einer Verlangsamung der Bildrate).
• HOHE QUALITÄT: In diesem Modus sollte der Verarbeitungsblock das bestmögliche Qualitätsergebnis liefern und die Ausgabebildrate nach Bedarf verlangsamen. Normalerweise wird dies für qualitativ hochwertige Standbildaufnahmen verwendet. Einige Blöcke beinhalten eine manuelle Steuerung, die optional anstelle von FAST oder HIGH_QUALITY ausgewählt werden kann. Beispielsweise unterstützt der Farbkorrekturblock eine Farbtransformationsmatrix, während die Tonkurvenanpassung eine beliebige globale Tonwertzuordnungskurve unterstützt.

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

• Gewünschte Auflösungen der Ausgabebildströme
• Verfügbarkeit von Binning-/Skipping-Modi auf dem Imager
• Die 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 HAL-Schnittstelle der Kamera, die Bandbreitenbeschränkungen in ein möglichst einfaches Modell zu abstrahieren. Das vorgestellte Modell weist folgende Eigenschaften auf:

• Der Bildsensor ist immer so konfiguriert, dass er angesichts der von der Anwendung angeforderten Ausgabestreamgrößen die kleinstmögliche Auflösung ausgibt. Die kleinste Auflösung ist definiert als mindestens so groß wie die größte angeforderte Ausgabestreamgröße.
• Da jede Anfrage einen oder alle aktuell konfigurierten Ausgabestreams verwenden kann, müssen der Sensor und der ISP so konfiguriert sein, dass sie die gleichzeitige Skalierung einer einzelnen Erfassung auf alle Streams unterstützen.
• JPEG-Streams verhalten sich für Anfragen, in denen sie nicht enthalten sind, wie verarbeitete YUV-Streams. In Anfragen, in denen direkt auf sie verwiesen wird, fungieren sie als JPEG-Streams.
• Der JPEG-Prozessor kann gleichzeitig mit dem Rest der Kamera-Pipeline ausgeführt werden, kann jedoch nicht mehr als eine Aufnahme gleichzeitig verarbeiten.