Sottosistema HAL

Richieste

Il framework dell'app invia richieste di risultati acquisiti al sottosistema della videocamera. Una richiesta corrisponde a un insieme di risultati. Una richiesta incapsula tutte le informazioni di configurazione relative all'acquisizione e all'elaborazione di questi risultati. Sono inclusi elementi come la risoluzione e il formato pixel, il controllo manuale del sensore, dell'obiettivo e del flash , le modalità operative 3A, il controllo dell'elaborazione da RAW a YUV e la generazione di statistiche. Ciò consente un controllo molto maggiore dell'output e dell'elaborazione dei risultati. È possibile avere più richieste in corso contemporaneamente e l'invio delle richieste non è bloccante. Inoltre, le richieste vengono sempre elaborate nell'ordine in cui vengono ricevute.

Figura 1. Modello della videocamera

HAL e sottosistema della videocamera

Il sottosistema della videocamera include le implementazioni dei componenti nella pipeline della videocamera , come l'algoritmo 3A e i controlli di elaborazione. La HAL della videocamera fornisce interfacce per implementare le tue versioni di questi componenti. Per mantenere la compatibilità multipiattaforma tra più produttori di dispositivi e fornitori di processore di immagine (ISP o sensore della videocamera), il modello della pipeline della videocamera è virtuale e non corrisponde direttamente a nessun ISP reale. Tuttavia, è abbastanza simile alle pipeline di elaborazione reali, quindi puoi mapparla in modo efficiente all'hardware. Inoltre, è abbastanza astratta da consentire più algoritmi e ordini di operazioni diversi senza compromettere la qualità, l'efficienza o la compatibilità tra dispositivi.

La pipeline della videocamera supporta anche i trigger che il framework dell'app può avviare per attivare elementi come la messa a fuoco automatica. Invia anche notifiche al framework dell'app, informando le app di eventi come un blocco della messa a fuoco automatica o errori.

Figura 2. Pipeline della videocamera

Tieni presente che alcuni blocchi di elaborazione delle immagini mostrati nel diagramma sopra non sono ben definiti nella release iniziale. La pipeline della videocamera parte dalle seguenti ipotesi:

• L'output RAW Bayer non viene elaborato all'interno dell'ISP.
• Le statistiche vengono generate in base ai dati del sensore non elaborati.
• I vari blocchi di elaborazione che convertono i dati del sensore non elaborati in YUV sono in un ordine arbitrario.
• Sebbene vengano mostrate più unità di scalatura e ritaglio, tutte le unità di scalatura condividono i controlli della regione di output (zoom digitale). Tuttavia, ogni unità può avere una risoluzione di output e un formato pixel diversi.

Riepilogo dell'utilizzo dell'API
Questo è un breve riepilogo dei passaggi per l'utilizzo dell'API della videocamera Android. Per una suddivisione dettagliata di questi passaggi, incluse le chiamate API, consulta la sezione Sequenza di avvio e funzionamento prevista.

1. Ascolta ed enumera i dispositivi della videocamera.
2. Apri il dispositivo e connetti i listener.
3. Configura gli output per il caso d'uso target (ad es. acquisizione di immagini fisse, registrazione, ecc.).
4. Crea una o più richieste per il caso d'uso target.
5. Acquisisci/ripeti richieste e burst.
6. Ricevi i metadati dei risultati e i dati delle immagini.
7. Quando cambi caso d'uso, torna al passaggio 3.

Riepilogo delle operazioni HAL

• Le richieste asincrone di acquisizione provengono dal framework.
• Il dispositivo HAL deve elaborare le richieste in ordine. Per ogni richiesta, genera i metadati dei risultati di output e uno o più buffer di immagini di output.
• FIFO (First-In, First-Out) per richieste e risultati e per gli stream a cui fanno riferimento le richieste successive.
• I timestamp devono essere identici per tutti gli output di una determinata richiesta, in modo che il framework possa abbinarli, se necessario.
• Tutta la configurazione e lo stato di acquisizione (ad eccezione delle routine 3A) sono incapsulati nelle richieste e nei risultati.

Figura 3. Panoramica della HAL della videocamera

Sequenza di avvio e funzionamento prevista

Questa sezione contiene una spiegazione dettagliata dei passaggi previsti quando si utilizza l'API della videocamera. Per le definizioni dell'interfaccia HIDL, consulta platform/hardware/interfaces/camera/

Enumerare, aprire i dispositivi della videocamera e creare una sessione attiva

1. Dopo l'inizializzazione, il framework inizia ad ascoltare eventuali provider di videocamere presenti che implementano l'interfaccia ICameraProvider. Se è presente uno o più provider, il framework tenterà di stabilire una connessione.
2. Il framework enumera i dispositivi della videocamera tramite ICameraProvider::getCameraIdList().
3. Il framework crea un'istanza di un nuovo ICameraDevice chiamando il rispettivo ICameraProvider::getCameraDeviceInterface_VX_X().
4. Il framework chiama ICameraDevice::open() per creare una nuova sessione di acquisizione attiva ICameraDeviceSession.

Utilizzare una sessione della videocamera attiva

1. Il framework chiama ICameraDeviceSession::configureStreams() con un elenco di stream 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ò essere eseguita in qualsiasi momento dopo la creazione di ICameraDeviceSession da parte di ICameraDevice::open.
3. Il framework crea e invia la prima richiesta di acquisizione alla HAL con impostazioni basate su uno degli insiemi di impostazioni predefinite e con almeno uno stream di output registrato in precedenza dal framework. Viene inviato alla HAL con ICameraDeviceSession::processCaptureRequest(). La HAL deve bloccare la restituzione di questa chiamata finché non è pronta per l'invio della richiesta successiva.
4. Il framework continua a inviare richieste e chiama ICameraDeviceSession::constructDefaultRequestSettings() per ottenere i buffer delle impostazioni predefinite per altri casi d'uso, se necessario.
5. Quando inizia l'acquisizione di una richiesta (il sensore inizia l'esposizione per l' acquisizione), la HAL chiama ICameraDeviceCallback::notify() con il messaggio SHUTTER, incluso il numero di frame e il timestamp per l'inizio dell'esposizione. Questo callback di notifica non deve necessariamente avvenire prima della prima processCaptureResult() chiamata per una richiesta, ma nessun risultato viene inviato a un'app per un'acquisizione fino a quando non viene chiamata notify() per l'acquisizione.
6. Dopo un certo ritardo della pipeline, la HAL inizia a restituire le acquisizioni completate al framework con ICameraDeviceCallback::processCaptureResult(). Questi vengono restituiti nello stesso ordine in cui sono state inviate le richieste. È possibile avere più richieste in corso contemporaneamente, a seconda della profondità della pipeline del dispositivo HAL della videocamera.

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

• Il framework potrebbe interrompere l'invio di nuove richieste, attendere il completamento delle acquisizioni esistenti (tutti i buffer riempiti, tutti i risultati restituiti) e poi chiamare di nuovo.ICameraDeviceSession::configureStreams() In questo modo, l'hardware e la pipeline della videocamera vengono reimpostati per un nuovo insieme di stream di input/output. Alcuni stream potrebbero essere riutilizzati dalla configurazione precedente. Il framework continua quindi dalla prima richiesta di acquisizione alla HAL, se rimane almeno uno stream di output registrato. (In caso contrario, ICameraDeviceSession::configureStreams() è necessario prima.)
• Il framework potrebbe chiamare ICameraDeviceSession::close() per terminare la sessione della videocamera. Questa chiamata può essere eseguita in qualsiasi momento in cui non sono attive altre chiamate dal framework, anche se la chiamata potrebbe essere bloccata finché non vengono completate tutte le acquisizioni in corso (tutti i risultati restituiti, tutti i buffer riempiti). Dopo la restituzione della chiamata close(), la HAL non può più chiamare ICameraDeviceCallback. Una volta avviata la close() chiamata, il framework non può chiamare altre funzioni del dispositivo HAL.
• In caso di errore o altro evento asincrono, la HAL deve chiamare ICameraDeviceCallback::notify() con il messaggio di errore/evento appropriato. Dopo aver restituito una notifica di errore irreversibile a livello di dispositivo, la HAL deve comportarsi come se fosse stata chiamata close(). Tuttavia, la HAL deve annullare o completare tutte le acquisizioni in sospeso prima di chiamare notify(), in modo che, una volta notify() chiamata con un errore irreversibile, il framework non riceva ulteriori callback dal dispositivo. I metodi diversi da close() devono restituire -ENODEV o NULL dopo che il notify() metodo restituisce un messaggio di errore irreversibile.

Figura 4. Flusso operativo della videocamera

Livelli di hardware

I dispositivi della videocamera possono implementare diversi livelli di hardware a seconda delle loro funzionalità. Per ulteriori informazioni, consulta livello di hardware 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 alcuni dei parametri nella richiesta di acquisizione dell'app e utilizza i valori forniti dalle routine di controllo 3A invece. Ad esempio, quando l'esposizione automatica è attiva, i parametri di tempo di esposizione, durata del frame e sensibilità del sensore sono controllati dall'algoritmo 3A della piattaforma e tutti i valori specificati dall'app vengono ignorati. I valori scelti per il frame dalle routine 3A devono essere riportati nei metadati di output. La tabella seguente descrive le diverse modalità del blocco di controllo 3A e le proprietà controllate da queste modalità. Per le definizioni di queste proprietà, consulta il file platform/system/media/camera/docs/docs.html.

Parametro	Stato	Proprietà controllate
android.control.aeMode	OFF	Nessuna
	ON	android.sensor.exposureTime android.sensor.frameDuration android.sensor.sensitivity android.lens.aperture (se supportato) android.lens.filterDensity (se supportato)
	ON_AUTO_FLASH	Tutto è ON, 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	Nessuna
	WHITE_BALANCE_*	android.colorCorrection.transform. Regolazioni specifiche della piattaforma se android.colorCorrection.mode è FAST o HIGH_QUALITY.
android.control.afMode	OFF	Nessuna
	FOCUS_MODE_*	android.lens.focusDistance
android.control.videoStabilization	OFF	Nessuna
	ON	Può regolare android.scaler.cropRegion per implementare la stabilizzazione dei video
android.control.mode	OFF	AE, AWB e AF sono disattivati
	AUTO	Vengono utilizzate le singole impostazioni AE, AWB e AF
	SCENE_MODE_*	Può sostituire tutti i parametri elencati sopra. I singoli controlli 3A sono disattivati.

I controlli nel blocco di elaborazione delle immagini nella Figura 2 operano tutti secondo un principio simile e in genere ogni blocco ha tre modalità:

• OFF: questo blocco di elaborazione è disattivato. I blocchi di demosaicizzazione, correzione del colore e regolazione della curva di tonalità non possono essere disattivati.
• FAST: in questa modalità, il blocco di elaborazione potrebbe non rallentare la frequenza frame di output rispetto alla modalità OFF, ma dovrebbe comunque produrre l'output di migliore qualità possibile, data questa limitazione. In genere, questa modalità viene utilizzata per anteprima o registrazione video oppure per l'acquisizione di burst per le immagini fisse. Su alcuni dispositivi, questa modalità potrebbe essere equivalente alla modalità OFF (non è possibile eseguire l'elaborazione senza rallentare la frequenza fotogrammi) e su alcuni dispositivi potrebbe essere equivalente alla modalità HIGH_QUALITY (la migliore qualità non rallenta comunque la frequenza fotogrammi).
• HIGH_QUALITY: in questa modalità, il blocco di elaborazione deve produrre il risultato di migliore qualità possibile, rallentando la frequenza fotogrammi di output, se necessario. In genere, questa modalità viene utilizzata per l'acquisizione di immagini fisse di alta qualità. Alcuni blocchi includono un controllo manuale che può essere selezionato facoltativamente anziché FAST o HIGH_QUALITY. Ad esempio, il blocco di correzione del colore supporta una matrice di trasformazione del colore, mentre la regolazione della curva di tonalità supporta una curva di mappatura tonale globale arbitraria.

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

• Risoluzioni richieste degli stream di immagini di output
• Disponibilità delle modalità di binning/skipping sull'imager
• 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, l' interfaccia HAL della videocamera tenta di astrarre le limitazioni della larghezza di banda in un modello il più semplice possibile. Il modello presentato ha le seguenti caratteristiche:

• Il sensore di immagine è sempre configurato per generare l'output della risoluzione più piccola possibile in base alle dimensioni dello stream di output richieste dall'app. La risoluzione più piccola è definita come almeno grande quanto la dimensione dello stream di output più grande richiesta.
• Poiché qualsiasi richiesta può utilizzare tutti o alcuni degli stream di output attualmente configurati, il sensore e l'ISP devono essere configurati per supportare la scalabilità di una singola acquisizione a tutti gli stream contemporaneamente.
• Gli stream JPEG si comportano come stream YUV elaborati per le richieste in cui non sono inclusi; nelle richieste in cui vengono referenziati direttamente, si comportano come stream JPEG.
• Il processore JPEG può essere eseguito contemporaneamente al resto della pipeline della videocamera, ma non può elaborare più di un'acquisizione alla volta.