Sottosistema HAL

Richieste

Il framework dell'app invia richieste per i risultati acquisiti al sottosistema della fotocamera. Una richiesta corrisponde a un insieme di risultati. Una richiesta include tutti e le informazioni di configurazione relative all'acquisizione e all'elaborazione di questi risultati. tra cui la risoluzione e il formato dei pixel, sensore manuale, obiettivo e il controllo del flash; Modalità operative 3A; Controllo di elaborazione da RAW a YUV; e la generazione delle statistiche. Ciò consente un maggiore controllo sui risultati. l'output e l'elaborazione. Più richieste possono essere in corso contemporaneamente e l'invio di richieste non blocca. Le richieste vengono sempre elaborate l'ordine in cui vengono ricevuti.

Figura 1. Modello di fotocamera

HAL e sottosistema delle videocamere

Il sottosistema delle videocamere include le implementazioni per i componenti della videocamera come l'algoritmo 3A e i controlli di elaborazione. La videocamera HAL fornisce le interfacce per implementare le versioni di questi componenti. A mantenere la compatibilità multipiattaforma tra più produttori di dispositivi e Fornitori di processori di segnali di immagine (ISP o sensori per videocamere), la pipeline delle fotocamere è virtuale e non corrisponde direttamente a un ISP reale. Tuttavia, è abbastanza simile alle pipeline di elaborazione reali per poter essere mappato l'hardware in modo efficiente. Inoltre, è sufficientemente astratto da consentire la diversi algoritmi e ordini di funzionamento senza compromettere qualità, efficienza o compatibilità cross-device.

La pipeline della videocamera supporta anche i trigger che possono essere avviati dal framework dell'app per attivare elementi come la messa a fuoco automatica. Inoltre, invia le notifiche al framework per app, notificando alle app eventi quali il blocco della messa a fuoco automatica o gli errori.

Figura 2. Pipeline della videocamera

Nota: alcuni blocchi di elaborazione delle immagini mostrati nello schema qui sopra non sono ben definite nella release iniziale. La pipeline della videocamera effettua quanto segue ipotesi:

• L'output RAW Bayer non subisce alcuna elaborazione all'interno dell'ISP.
• Le statistiche vengono generate in base ai dati non elaborati dei sensori.
• I vari blocchi di elaborazione che convertono i dati non elaborati dei sensori in YUV si trovano in una in un ordine arbitrario.
• Mentre sono visualizzate più unità di scala e di ritaglio, tutte le unità di scalabilità condividono controlli della regione di output (zoom digitale). Tuttavia, ogni unità può avere risoluzione dell'output e formato pixel.

Riepilogo dell'utilizzo dell'API
Questo è un breve riepilogo dei passaggi per utilizzare l'API Android Camera. Consulta le Sezione Sequenza di avvio e delle operazioni previste per un'analisi dettagliata di questi passaggi, incluse le chiamate API.

1. Ascolta e elenca i dispositivi della videocamera.
2. Apri il dispositivo e connetti i listener.
3. Configura gli output per il caso d'uso target (ad esempio, acquisisci, registrazione, e così via).
4. Crea richieste per il caso d'uso di destinazione.
5. Acquisisci/ripeti richieste e burst.
6. Ricevi metadati dei risultati e dati di immagini.
7. Quando cambi casi d'uso, torna al passaggio 3.

Riepilogo operazione HAL

• Le richieste asincrone per le acquisizioni provengono dal framework.
• Il dispositivo HAL deve elaborare le richieste in ordine. E per ogni richiesta, metadati dei risultati di output e uno o più buffer di immagini di output.
• In ordine di importanza per le richieste e i risultati e per gli stream a cui viene fatto riferimento richieste successive.
• I timestamp devono essere identici per tutti gli output di una determinata richiesta, potrebbe abbinarli, se necessario.
• Tutti gli stati e la configurazione dell'acquisizione (ad eccezione delle routine 3A) sono incapsulati nelle richieste e nei risultati.

Figura 3. Panoramica dell'HAL della fotocamera

Avvio e sequenza delle operazioni previste

Questa sezione contiene una spiegazione dettagliata dei passaggi previsti durante l'utilizzo l'API Camera. Vedi platform/hardware/interfaces/camera/ per l'interfaccia HIDL le tue definizioni.

Enumera, apri i dispositivi con videocamera e crea una sessione attiva

1. Dopo l'inizializzazione, il framework inizia ad ascoltare eventuali presenti fotocamere che implementano interfaccia di ICameraProvider. Se tale fornitore o sono presenti, il framework proverà a stabilire una connessione.
2. Il framework elenca i dispositivi con videocamera ICameraProvider::getCameraIdList().
3. Il framework crea un'istanza di un nuovo ICameraDevice richiamando il rispettivo ICameraProvider::getCameraDeviceInterface_VX_X().
4. Il framework chiama ICameraDevice::open() per creare un nuovo sessione di acquisizione attiva ICameraDeviceSession.

Utilizzare una sessione di videocamera attiva

1. Il framework chiama ICameraDeviceSession::configureStreams() con un elenco di flussi di input/output al dispositivo HAL.
2. Il framework richiede le impostazioni predefinite per alcuni casi d'uso con chiamate a ICameraDeviceSession::constructDefaultRequestSettings(). Questa operazione può verificarsi in qualsiasi momento dopo che il ICameraDeviceSession creato da ICameraDevice::open.
3. Il framework crea e invia la prima richiesta di acquisizione all'HAL con impostazioni in base a uno degli insiemi di impostazioni predefinite e con almeno una flusso di output registrato in precedenza dal framework. Messaggio inviato all'HAL con ICameraDeviceSession::processCaptureRequest(). L'HAL deve bloccare il ritorno di questa chiamata finché non è pronta per quella successiva una richiesta di invio.
4. Il framework continua a inviare richieste e chiamate ICameraDeviceSession::constructDefaultRequestSettings() per ricevere buffer delle impostazioni predefinite per altri casi d'uso, se necessario.
5. Quando inizia l'acquisizione di una richiesta (il sensore inizia a esporre per acquisizioni), l'HAL chiama ICameraDeviceCallback::notify() con il messaggio SHUTTER, inclusi il numero di frame e il timestamp per l'inizio di esposizione. Il callback di notifica non deve essere eseguito prima del primo processCaptureResult() chiama per una richiesta, ma nessun risultato pubblicati in un'app per l'acquisizione notify() per l'acquisizione in questione.
6. Dopo un certo ritardo nella pipeline, l'HAL inizia a restituire le acquisizioni completate a il framework con ICameraDeviceCallback::processCaptureResult(). Questi vengono restituiti nello stesso ordine in cui sono state inviate le richieste. Più di uno le richieste possono essere in transito contemporaneamente, a seconda della profondità videocamera HAL.

Dopo un po' di tempo, si verificherà una delle seguenti situazioni:

• Il framework potrebbe interrompere l'invio di nuove richieste, attendi le acquisizioni esistenti da completare (tutti i buffer riempiti, tutti i risultati restituito) e quindi richiama ICameraDeviceSession::configureStreams() di nuovo. Questa operazione reimposta l'hardware e la pipeline della videocamera per un nuovo set di di input/output. Alcuni stream possono essere riutilizzati dalla precedente configurazione. Il framework prosegue poi dalla prima richiesta di acquisizione all'HAL, se almeno uno mentre lo stream di output registrato rimane. (In caso contrario, ICameraDeviceSession::configureStreams() è prima obbligatorio.)
• Il framework può chiamare ICameraDeviceSession::close() per terminare la sessione della videocamera. Questo può essere chiamato in qualsiasi momento, quando non ci sono altre chiamate dal framework siano attive, anche se la chiamata potrebbe bloccarsi finché acquisizioni in corso completate (tutti i risultati restituiti, tutti i buffer) riempita). Dopo il ritorno della chiamata a close(), non ci sono altre chiamate a Sono consentiti ICameraDeviceCallback dall'HAL. Una volta La chiamata close() è in corso, il framework non può chiamare nessun'altra Funzioni del dispositivo HAL.
• In caso di errore o di altro evento asincrono, l'HAL deve chiamare ICameraDeviceCallback::notify() con le credenziali messaggio di errore o evento. In seguito a una notifica di errore irreversibile a livello di dispositivo, l'HAL deve come se close() fosse stato chiamato. Tuttavia, l'HAL deve annulla o completa tutte le acquisizioni in sospeso prima di chiamare notify(), in modo che una volta notify() viene chiamato con un errore irreversibile, il framework non per ricevere ulteriori richiamate dal dispositivo. Metodi diversi da close() dovrebbe restituire -ENODEV o NULL dopo che il metodo notify() restituisce da un errore irreversibile .

Figura 4. Flusso operativo della videocamera

Livelli hardware

Le videocamere possono implementare diversi livelli hardware a seconda del loro le funzionalità di machine learning. Per ulteriori informazioni, vedi supportato.

Interazione tra la richiesta di acquisizione dell'app, il controllo 3A e la pipeline di elaborazione

A seconda delle impostazioni nel blocco di controllo 3A, la pipeline della videocamera ignora dei parametri nella richiesta di acquisizione dell'app, usando i valori sono invece fornite dalle routine di controllo 3A. Ad esempio, quando l'esposizione automatica è attiva, il tempo di esposizione, la durata fotogramma e i parametri di sensibilità del sono controllati dall'algoritmo della piattaforma 3A e da qualsiasi valore specificato dall'app vengono ignorati. I valori scelti per il frame dalle routine 3A devono essere segnalati nei metadati di output. Nella tabella seguente vengono descritte le diverse modalità di Il blocco di controllo 3A e le proprietà controllate da queste modalità. Consulta platform/system/media/camera/docs/docs.html per le definizioni di queste proprietà.

Parametro	Stato	Proprietà controllate
android.control.aeMode	OFF	Nessuno
	ON	android.sensor.exposureTime android.sensor.frameDuration android.sensor.sensitivity android.lens.aperture (se supportato) android.lens.filterDensity (se supportata)
	ON_AUTO_FLASH	Tutto è acceso, più android.flash.firingPower, android.flash.firingTime e android.flash.mode
	ON_ALWAYS_FLASH	Uguale a ON_AUTO_FLASH
	ON_AUTO_FLASH_RED_EYE	Uguale a ON_AUTO_FLASH
android.control.awbMode	OFF	Nessuno
	SALDO_BIANCO_*	android.colorCorrection.transform. Regolazioni specifiche della piattaforma se android.colorCorrection.mode è FAST o HIGH_QUALITY.
android.control.afMode	OFF	Nessuno
	MODALITÀ_FOCUS_*	android.lens.focusDistance
android.control.videoStabilizzazione	OFF	Nessuno
	ON	Puoi modificare la proprietà android.scaler.cropRegion per implementare la stabilizzazione video
android.control.mode	OFF	AE, AWB e AF sono disattivati
	AUTO	Vengono utilizzate le singole impostazioni AE, AWB e AF
	MODALITÀ_DI_SCENA_*	Può sostituire tutti i parametri elencati sopra. I controlli 3A individuali sono disattivati.

I controlli nel blocco Elaborazione delle immagini nella Figura 2 operano tutti su una principio simile e in genere ciascun blocco ha tre modalità:

• OFF: questo blocco di elaborazione è disabilitato. Il demosaicizzazione, la correzione del colore e I blocchi di regolazione della curva dei toni non possono essere disabilitati.
• VELOCE: in questa modalità, il blocco di elaborazione potrebbe non rallentare il frame di output. media rispetto alla modalità OFF, ma in caso contrario dovrebbe produrre la qualità migliore come output può data questa restrizione. In genere, viene utilizzato modalità di anteprima, registrazione video o raffica per le immagini statiche. Su alcune potrebbe essere equivalente alla modalità OFF (non è possibile eseguire alcuna elaborazione senza rallentando la frequenza fotogrammi) e, su alcuni dispositivi, questo potrebbe essere equivalente a Modalità HIGH_QUALITY (la qualità migliore comunque non rallenta la frequenza fotogrammi).
• HIGH_QUALITY: in questa modalità, il blocco di elaborazione dovrebbe produrre la di qualità più elevata possibile, diminuendo in base alle esigenze la frequenza fotogrammi di output. In genere, questa opzione viene utilizzata per scatti di alta qualità. Alcuni blocchi includono un controllo manuale che può essere selezionato facoltativamente al posto di FAST ALTA_QUALITÀ. Ad esempio, il blocco di correzione del colore supporta un colore di trasformazione, mentre la regolazione della curva di tono supporta un modello globale arbitrario di mappatura tonale.

La frequenza fotogrammi massima che può essere supportata da un sottosistema di una fotocamera è una funzione di molti fattori:

• Risoluzioni richieste dei flussi di immagini di output
• Disponibilità delle modalità di binning/salto nell'immagine
• La larghezza di banda dell'interfaccia dell'imager
• La larghezza di banda dei vari blocchi di elaborazione ISP

Poiché questi fattori possono variare notevolmente tra diversi ISP e sensori, il dell'interfaccia HAL della videocamera tenta di astrarre le restrizioni della larghezza di banda in un il più possibile. Il modello presentato ha le seguenti caratteristiche:

• Il sensore fotografico è sempre configurato per generare la risoluzione più bassa possibile date le dimensioni degli stream di output richieste dall'app. Il più piccolo di risoluzione dei problemi è definita come grande almeno quanto la più grande richiesta la dimensione del flusso di output.
• Poiché ogni richiesta può utilizzare uno o tutti i flussi di output attualmente configurati, sensore e ISP devono essere configurati in modo da supportare la scalabilità di una singola acquisizione tutti gli stream contemporaneamente.
• Gli stream JPEG agiscono come flussi YUV elaborati per le richieste per cui vengono non inclusi; nelle richieste in cui vi viene fatto riferimento direttamente, Stream JPEG.
• Il processore JPEG può essere eseguito contemporaneamente al resto della pipeline della fotocamera, non può elaborare più di un'acquisizione alla volta.