Diese Seite wurde von der Cloud Translation API übersetzt.

HAL-Subsystem

Anfragen

Das App-Framework fordert erfasste Ergebnisse an das Kamerasubsystem an. Eine Anfrage entspricht einer Gruppe von Ergebnissen. Eine Anfrage kapselt alle Konfigurationsinformationen zum Erfassen und Verarbeiten der Ergebnisse. Dazu gehören Dinge wie Auflösung und Pixelformat, manueller Sensor, Objektiv, und Blitzsteuerung; 3A-Betriebsmodi; Verarbeitungskontrolle von RAW zu YUV; und und Statistiken zu erstellen. So haben Sie viel mehr Kontrolle über die Ergebnisse.“ die Ausgabe und Verarbeitung. Es können mehrere Anfragen gleichzeitig aktiv sein. durch das Senden von Anträgen. Und die Anfragen werden immer in der Reihenfolge ihres Eingangs.

Abbildung 1: Kameramodell

HAL und Kamera-Subsystem

Das Kamerasubsystem umfasst die Implementierungen für Komponenten in der Kamera. wie den 3A-Algorithmus und Verarbeitungssteuerungen. Kamera-HAL stellt Schnittstellen zur Implementierung der Versionen dieser Komponenten zur Verfügung. Bis plattformübergreifende Kompatibilität zwischen verschiedenen Geräteherstellern und Anbieter von Bildsignalprozessoren (ISP oder Kamerasensoren), die Kamera-Pipeline Modell ist virtuell und entspricht keinem realen Internetanbieter. Allerdings realen Verarbeitungspipelines sehr ähnlich ist, sodass Sie sie Ihren effizient Hardware nutzen. Außerdem ist es abstrakt genug, um mehrere Algorithmen und Betriebsabläufe unterscheiden, Qualität, Effizienz oder geräteübergreifende Kompatibilität.

Die Kamera-Pipeline unterstützt auch Trigger, die das App-Framework initiieren kann zum Beispiel den Autofokus zu aktivieren. Außerdem werden Benachrichtigungen an den App-Framework und benachrichtigt Apps über Ereignisse wie eine Autofokus-Sperre oder Fehler.

Abbildung 2: Kamerapipeline

Einige im Diagramm gezeigte Bildverarbeitungsblöcke klar definiert sind. Die Kamerapipeline sorgt dafür, Annahmen:

Die RAW-Bayer-Ausgabe wird innerhalb des ISP nicht verarbeitet.
Die Statistiken werden auf Grundlage der Sensorrohdaten generiert.
Die verschiedenen Verarbeitungsblöcke, die Sensor-Rohdaten in YUV konvertieren, befinden sich in einem Reihenfolge ändern.
Es werden mehrere Skalierungs- und Zuschneideeinheiten angezeigt, alle Steuerelemente für den Ausgabebereich (digitaler Zoom) Jede Einheit kann jedoch unterschiedliche die Ausgabeauflösung und das Pixelformat.

Zusammenfassung der API-Nutzung
Dies ist eine kurze Zusammenfassung der Schritte zur Verwendung der Android Camera API. Weitere Informationen finden Sie in der Abschnitt „Start und erwartete Vorgangsabfolge“ für eine detaillierte Aufschlüsselung einschließlich API-Aufrufen.

Kamerageräte erkennen und auflisten.
Öffnen Sie das Gerät und verbinden Sie die Zuhörer.
Konfigurieren Sie die Ausgaben für den Zielanwendungsfall (z. B. Aufzeichnung, Aufzeichnung, usw.).
Erstellen Sie Anfragen für den Zielanwendungsfall.
Anfragen und Bursts erfassen/wiederholen
Metadaten zu Ergebnissen und Bilddaten abrufen.
Wenn Sie den Anwendungsfall wechseln, kehren Sie zu Schritt 3 zurück.

HAL-Vorgangszusammenfassung

Asynchrone Anfragen für Erfassungen stammen vom Framework.
Das HAL-Gerät muss die Anfragen der Reihe nach verarbeiten. Erstellen Sie für jede Anfrage Metadaten der Ausgabeergebnisse und ein oder mehrere Ausgabebildpuffer.
First-In-First-Out-Prinzip bei Anfragen und Ergebnissen sowie für Streams, auf die von nachfolgende Anfragen.
Zeitstempel müssen für alle Ausgaben einer bestimmten Anfrage identisch sein, sodass der Framework bei Bedarf zusammenpassen.
Die gesamte Erfassungskonfiguration und der gesamte -status (außer 3A-Routinen) sind in den Anfragen und Ergebnissen.

Abbildung 3: Kamera-HAL – Übersicht

Start und erwartete Vorgangssequenz

Dieser Abschnitt enthält eine detaillierte Erklärung der Schritte, die bei der Verwendung von die Camera API verwenden. Weitere Informationen finden Sie unter <ph type="x-smartling-placeholder"></ph> Plattform/Hardware/Schnittstellen/Kamera/ für HIDL-Schnittstelle Definitionen.

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

Nach der Initialisierung beginnt das Framework, Kamera-Anbietern, die die ICameraProvider-Schnittstelle. Wenn ein solcher Dienstleister oder Anbieter vorhanden sind, versucht das Framework, eine Verbindung herzustellen.
Das Framework listet die Kamerageräte über ICameraProvider::getCameraIdList()
Das Framework instanziiert eine neue ICameraDevice, indem die entsprechende ICameraProvider::getCameraDeviceInterface_VX_X().
Das Framework ruft ICameraDevice::open() auf, um ein neues aktive Aufnahmesitzung „ICameraDeviceSession“.

Aktive Kamerasitzung verwenden

Das Framework ruft ICameraDeviceSession::configureStreams() auf. mit einer Liste von Eingabe-/Ausgabestreams zum HAL-Gerät.
Das Framework fordert Standardeinstellungen für einige Anwendungsfälle mit ICameraDeviceSession::constructDefaultRequestSettings()-Aufrufe Dies kann jederzeit passieren, nachdem ICameraDeviceSession erstellt von ICameraDevice::open.
Das Framework erstellt und sendet die erste Erfassungsanfrage an den HAL mit -Einstellungen basierend auf einer Gruppe von Standardeinstellungen und mindestens einer Ausgabestream, der zuvor vom Framework registriert wurde. Dies wurde gesendet mit ICameraDeviceSession::processCaptureRequest() an den HAL. Der HAL muss die Rückgabe dieses Aufrufs blockieren, bis er für den nächsten zu senden.
Das Framework sendet weiterhin Anfragen und Aufrufe. Noch ICameraDeviceSession::constructDefaultRequestSettings() Puffer für andere Anwendungsfälle bei Bedarf.
Wenn die Erfassung einer Anfrage beginnt (Sensor beginnt die Erfassung Erfassung), ruft der HAL ICameraDeviceCallback::notify() auf mit die SHUTTER-Nachricht einschließlich Frame-Nummer und Zeitstempel für Start der Schallbelastung. Dieser Benachrichtigungs-Callback muss nicht vor dem ersten processCaptureResult()-Aufruf für eine Anfrage, aber es werden keine Ergebnisse gefunden werden bis nach dem Eintreffen notify() für diese Erfassung wird aufgerufen.
Nach einer gewissen Pipelineverzögerung beginnt der HAL, abgeschlossene Erfassungen an die das Framework mit ICameraDeviceCallback::processCaptureResult(). Sie werden in derselben Reihenfolge zurückgegeben, in der die Anfragen gesendet wurden. Mehrere Anfragen gleichzeitig aktiv sein können, abhängig von der Pipelinetiefe der Kamera-HAL-Gerät.

Nach einiger Zeit geschieht Folgendes:

Das Framework sendet möglicherweise keine neuen Anfragen mehr. Warten Sie auf die vorhandenen Erfassungen abzuschließen (alle Puffer gefüllt, alle Ergebnisse zurückgegeben) und rufen Sie dann ICameraDeviceSession::configureStreams() auf noch einmal. Dadurch werden Kamerahardware und -pipeline zurückgesetzt. Eingabe-/Ausgabestreams. Einige Streams können aus den vorherigen Konfiguration. Das Framework fährt mit der ersten Erfassungsanfrage fort. an den HAL, wenn mindestens eine bleibt der registrierte Ausgabestream erhalten. (Andernfalls ICameraDeviceSession::configureStreams() ist zuerst erforderlich.)
Das Framework kann ICameraDeviceSession::close() aufrufen. um die Kamerasitzung zu beenden. Diese Funktion kann jederzeit aufgerufen werden, wenn keine anderen Anrufe aus dem Framework aktiv sind, auch wenn der Anruf möglicherweise blockiert wird, bis alle In-Flight-Aufnahmen sind abgeschlossen (alle Ergebnisse wurden zurückgegeben, alle Zwischenspeicher) ausgefüllt). Nach Rückgabe des close()-Aufrufs sind keine Aufrufe mehr für ICameraDeviceCallback werden vom HAL zugelassen. Sobald die close()-Aufruf läuft, das Framework darf keine anderen aufrufen HAL-Gerätefunktionen
Im Falle eines Fehlers oder eines anderen asynchronen Ereignisses muss der HAL ICameraDeviceCallback::notify() durch den entsprechenden Fehler-/Ereignismeldung. Nach der Rückgabe einer schwerwiegenden geräteweiten Fehlerbenachrichtigung sollte der HAL so handeln, als wäre close() dafür aufgerufen worden. Der HAL muss jedoch entweder abbrechen oder alle ausstehenden Aufnahmen abschließen, bevor Sie notify() anrufen, damit einmal notify() mit einem schwerwiegenden Fehler aufgerufen wird, weitere Rückrufe vom Gerät empfangen. Weitere Methoden close() sollte Folgendes zurückgeben: -ENODEV oder NULL, nachdem die notify()-Methode von einem schwerwiegenden Fehlermeldung erhalten.

Abbildung 4: Kamerabetrieb

Hardwarestufen

Kamerageräte können je nach Funktionen. Weitere Informationen finden Sie unter <ph type="x-smartling-placeholder"></ph> unterstützte Hardwareebene.

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

Abhängig von den Einstellungen im 3A-Steuerblock ignoriert die Kamerapipeline einige der Parameter in der Erfassungsanfrage der App an und verwendet die Werte 3A-Steuerungsroutinen bereitgestellt werden. Wenn zum Beispiel die automatische Belichtung aktiv sind, die Parameter für Belichtungszeit, Framedauer und Empfindlichkeit des werden vom Plattform-3A-Algorithmus gesteuert und alle App-spezifischen Werte werden ignoriert. Die von den 3A-Routinen für den Frame ausgewählten Werte müssen gemeldet werden in den Ausgabemetadaten. In der folgenden Tabelle werden die verschiedenen Modi des 3Ein Steuerelementblock und die Eigenschaften, die von diesen Modi gesteuert werden. Weitere Informationen finden Sie unter die platform/system/media/camera/docs/docs.html zur Definition dieser Eigenschaften hinzu.

Parameter	Bundesland	Über Properties verwaltet
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)
	AUTOMATISCHER_FLASH	Alles ist aktiviert sowie android.flash.firingPower, android.flash.firingTime und android.flash.mode
	AN_IMMER_BLITZ	Wie bei ON_AUTO_FLASH
	AUTOMATISCHES_Blitzlicht	Wie bei ON_AUTO_FLASH
android.control.awbMode	AUS	Keine
	WHITE_GUTHABEN_*	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	Individuelle Einstellungen für AE, AWB und AF werden verwendet
	SZENE_MODE_*	Kann alle oben aufgeführten Parameter überschreiben. Einzelne 3A-Steuerungen sind deaktiviert.

Die Steuerelemente im Bildverarbeitungsblock in Abbildung 2 ähnlich. Im Allgemeinen hat jeder Block drei Modi:

AUS: Dieser Verarbeitungsblock ist deaktiviert. Die Demosaic-, Farbkorrektur- und Blocks zur Anpassung der Tonkurve können nicht deaktiviert werden.
SCHNELL: In diesem Modus darf der Verarbeitungsblock den Ausgabeframe nicht verlangsamen. im Vergleich zum AUS-Modus, sollte aber ansonsten die beste Qualität erzeugen. gibt, die es mit dieser Einschränkung herausfinden kann. Üblicherweise wird dies für im Vorschau- oder Videoaufzeichnungsmodus oder bei Standbildern eine Serienaufnahme hinzu. Auf einigen kann dies dem Modus "Aus" entsprechen. Eine Verarbeitung ist ohne verlangsamt. Auf einigen Geräten entspricht dies dem HIGH_QUALITY-Modus. Bei bester Qualität wird die Framerate dennoch nicht verlangsamt.
HIGH_QUALITY: In diesem Modus sollte der Verarbeitungsblock das beste Ergebnis liefern. und die Framerate für die Ausgabe entsprechend verlangsamen. Dies wird normalerweise für Aufnahmen in hoher Qualität verwendet. Einige Blöcke eine manuelle Steuerung enthalten, die optional anstelle von SCHNELL oder HIGH_QUALITY sein. Der Farbkorrekturblock unterstützt beispielsweise Transformationsmatrix, während die Anpassung der Tonwertkurve eine beliebige globale Tone Mapping-Kurve.

Die maximale Framerate, die von einem Kamerasubsystem unterstützt wird, ist eine Funktion vielen Faktoren zu berücksichtigen:

Angeforderte Auflösungen von Ausgabebildstreams
Verfügbarkeit von Binning-/Überspringen-Modi im Imager
Die Bandbreite der Imager-Schnittstelle
Die Bandbreite der Verarbeitungsblöcke verschiedener Internetanbieter

Da diese Faktoren je nach Internetanbieter und Sensoren stark variieren können, Kamera-HAL-Schnittstelle versucht, die Bandbreitenbeschränkungen wie möglich zu verwenden. Das vorgestellte Modell hat die folgenden Eigenschaften:

Der Bildsensor ist immer so konfiguriert, dass er die niedrigste Auflösung ausgibt. aufgrund der von der App angeforderten Größe des Ausgabestreams möglich. Die kleinste Auflösung ist definiert als mindestens so groß wie die größte Größe des Ausgabestreams.
Da jede Anfrage einen oder alle aktuell konfigurierten Ausgabestreams verwenden kann, Sensor und Internetanbieter müssen so konfiguriert sein, dass eine einzelne Erfassung auf gleichzeitig streamen.
JPEG-Streams verhalten sich wie verarbeitete YUV-Streams für Anfragen, für die sie nicht inbegriffen; in Ersuchen, in denen direkt auf sie verwiesen wird, JPEG-Streams
Der JPEG-Prozessor kann gleichzeitig mit dem Rest der Kamerapipeline ausgeführt werden, kann jeweils nur eine Aufnahme verarbeiten.