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.
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.
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“.
- Hören Sie auf Kamerageräte und zählen Sie sie auf.
- Gerät öffnen und Zuhörer verbinden.
- Konfigurieren Sie Ausgaben für den Zielanwendungsfall (z. B. Standbildaufnahme, Aufzeichnung usw.).
- Erstellen Sie eine oder mehrere Anfragen für den Zielanwendungsfall.
- Anforderungen und Bursts erfassen/wiederholen.
- Erhalten Sie Ergebnismetadaten und Bilddaten.
- 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.
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
- 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. - Das Framework zählt die Kamerageräte über
ICameraProvider::getCameraIdList()
auf. - Das Framework instanziiert ein neues
ICameraDevice
, indem es das entsprechendeICameraProvider::getCameraDeviceInterface_VX_X()
aufruft. - Das Framework ruft
ICameraDevice::open()
auf, um eine neue aktive Aufnahmesitzung ICameraDeviceSession zu erstellen.
Verwendung einer aktiven Kamerasitzung
- 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. Dies kann jederzeit nach der Erstellung derICameraDeviceSession
durchICameraDevice::open
auftreten. - 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. - Das Framework sendet weiterhin Anfragen und ruft
ICameraDeviceSession::constructDefaultRequestSettings()
auf, um bei Bedarf Standardeinstellungspuffer für andere Anwendungsfälle abzurufen. - 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 AufrufprocessCaptureResult()
für eine Anforderung erfolgen, es werden jedoch keine Ergebnisse für eine Erfassung an eine Anwendung übermittelt, bisnotify()
für diese Erfassung aufgerufen wurde. - 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 zuerstICameraDeviceSession::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 desclose()
Aufrufs sind keine weiteren Aufrufe vonICameraDeviceCallback
von der HAL zulässig. Sobald der Aufrufclose()
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 obclose()
für sie aufgerufen worden wäre. Allerdings muss die HAL vor dem Aufrufnotify()
alle ausstehenden Erfassungen entweder abbrechen oder abschließen, sodass das Framework nach dem Aufrufnotify()
mit einem schwerwiegenden Fehler keine weiteren Rückrufe vom Gerät erhält. Methoden außerclose()
sollten -ENODEV oder NULL zurückgeben, nachdem dienotify()
Methode eine schwerwiegende Fehlermeldung zurückgibt.
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“ .
Parameter | Zustand | Eigenschaften kontrolliert |
---|---|---|
android.control.aeMode | AUS | Keiner |
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 | Identisch mit ON_AUTO_FLASH | |
ON_AUTO_FLASH_RED_EYE | Identisch mit ON_AUTO_FLASH | |
android.control.awbMode | AUS | Keiner |
WEISSABGLEICH_* | android.colorCorrection.transform. Plattformspezifische Anpassungen, wenn android.colorCorrection.mode FAST oder HIGH_QUALITY ist. | |
android.control.afMode | AUS | Keiner |
FOKUS MODUS_* | android.lens.focusDistance | |
android.control.videoStabilization | AUS | Keiner |
AN | Kann android.scaler.cropRegion anpassen, 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 | |
SZENENMODUS_* | Kann alle oben aufgeführten Parameter überschreiben. Einzelne 3A-Steuerungen sind deaktiviert. |
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.