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 contiene 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 di sensore, obiettivo e flash; le modalità di funzionamento 3A; il controllo dell'elaborazione da RAW a YUV e la generazione di statistiche. Ciò consente un controllo molto maggiore sull'output e sull'elaborazione dei risultati. Possono essere in corso più richieste contemporaneamente e l'invio di richieste non è bloccante. Inoltre, le richieste vengono sempre elaborate nell'ordine in cui vengono ricevute.

Figura 1. Modello di fotocamera

HAL e sottosistema della fotocamera

Il sottosistema della videocamera include le implementazioni per i componenti della pipeline della videocamera, come l'algoritmo 3A e i controlli di elaborazione. L'HAL della videocamera fornisce interfacce per implementare le tue versioni di questi componenti. Per mantenere la compatibilità cross-platform tra più produttori di dispositivi e fornitori di processori di segnali di immagine (ISP o sensori 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 astratto da consentire più algoritmi e ordini di operazioni diversi senza compromettere qualità, efficienza o compatibilità cross-device.

La pipeline della videocamera supporta anche i trigger che il framework dell'app può avviare per attivare funzionalità come la messa a fuoco automatica. Inoltre, invia notifiche al framework dell'app, avvisando le app di eventi come il 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 precedente non sono ben definiti nella release iniziale. La pipeline della videocamera si basa sulle seguenti ipotesi:

• L'output RAW Bayer non viene elaborato 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 sono in un ordine arbitrario.
• Sebbene vengano visualizzate più unità di ridimensionamento e ritaglio, tutte le unità di ridimensionamento condividono i controlli della regione di output (zoom digitale). Tuttavia, ogni unità può avere una risoluzione e un formato pixel di output diversi.

Riepilogo dell'utilizzo dell'API
Si tratta di un breve riepilogo dei passaggi per l'utilizzo dell'API Camera di Android. Consulta la sezione Sequenza di avvio e funzionamento prevista per una suddivisione dettagliata di questi passaggi, incluse le chiamate API.

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

Riepilogo operazione HAL

• Le richieste asincrone di acquisizioni provengono dal framework.
• Il dispositivo HAL deve elaborare le richieste in ordine. Per ogni richiesta, genera 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 di Fotocamera HAL

Sequenza di avvio e funzionamento prevista

Questa sezione contiene una spiegazione dettagliata dei passaggi previsti quando si utilizza l'API fotocamera. Consulta platform/hardware/interfaces/camera/ per le definizioni dell'interfaccia HIDL.

Enumerare, aprire i dispositivi di ripresa e creare una sessione attiva

1. Dopo l'inizializzazione, il framework inizia ad ascoltare i fornitori di fotocamere presenti che implementano l'interfaccia ICameraProvider. Se sono presenti questi fornitori, il framework tenterà di stabilire una connessione.
2. Il framework enumera i dispositivi videocamera tramite ICameraProvider::getCameraIdList().
3. Il framework crea una nuova 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 flussi di input/output al dispositivo HAL.
2. Il framework richiede impostazioni predefinite per alcuni casi d'uso con chiamate a ICameraDeviceSession::constructDefaultRequestSettings(). Ciò può verificarsi in qualsiasi momento dopo la creazione di ICameraDeviceSession da parte di ICameraDevice::open.
3. Il framework crea e invia la prima richiesta di acquisizione all'HAL con impostazioni basate su uno dei set di impostazioni predefinite e con almeno uno stream di output registrato in precedenza dal framework. Questi dati vengono inviati all'HAL con ICameraDeviceSession::processCaptureRequest(). L'HAL deve bloccare il ritorno di questa chiamata finché non è pronto per l'invio della richiesta successiva.
4. Il framework continua a inviare richieste e chiamate ICameraDeviceSession::constructDefaultRequestSettings() per ottenere buffer di 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), l'HAL chiama ICameraDeviceCallback::notify() con il messaggio SHUTTER, che include il numero di frame e il timestamp per l'inizio dell'esposizione. Questo callback di notifica non deve avvenire prima della prima chiamata processCaptureResult() per una richiesta, ma nessun risultato viene inviato a un'app per un'acquisizione finché non viene chiamato notify() per l'acquisizione.
6. Dopo un ritardo della pipeline, l'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. Possono essere in corso più richieste contemporaneamente, a seconda della profondità della pipeline del dispositivo HAL della videocamera.

Dopo un po' di tempo, si verificherà uno dei seguenti casi:

• 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 vengono reimpostati l'hardware e la pipeline della videocamera per un nuovo insieme di flussi di input/output. Alcuni stream potrebbero essere riutilizzati dalla configurazione precedente. Il framework continua quindi dalla prima richiesta di acquisizione all'HAL, se rimane almeno uno stream di output registrato. (In caso contrario, ICameraDeviceSession::configureStreams() è obbligatorio.)
• Il framework potrebbe chiamare ICameraDeviceSession::close() per terminare la sessione della videocamera. Può essere chiamato in qualsiasi momento quando non sono attive altre chiamate dal framework, anche se la chiamata potrebbe bloccarsi finché non sono state completate tutte le acquisizioni in corso (tutti i risultati restituiti, tutti i buffer riempiti). Dopo la restituzione della chiamata close(), non sono consentite altre chiamate a ICameraDeviceCallback dall'HAL. Una volta avviata la chiamata close(), il framework potrebbe non chiamare altre funzioni del dispositivo HAL.
• In caso di errore o altro evento asincrono, l'HAL deve chiamare ICameraDeviceCallback::notify() con il messaggio di errore/evento appropriato. Dopo essere tornato da una notifica di errore irreversibile a livello di dispositivo, l'HAL deve comportarsi come se fosse stato chiamato close(). Tuttavia, l'HAL deve annullare o completare tutte le acquisizioni in sospeso prima di chiamare notify(), in modo che una volta chiamato notify() 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 metodo notify() restituisce un messaggio di errore irreversibile.

Figura 4. Flusso operativo della videocamera

Livelli di hardware

I dispositivi di videocamera possono implementare diversi livelli hardware a seconda delle loro funzionalità. Per ulteriori informazioni, vedi livello 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 fotocamera ignora alcuni dei parametri nella richiesta di acquisizione dell'app e utilizza i valori forniti dalle routine di controllo 3A. 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à. Consulta il file 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 supportato)
	ON_AUTO_FLASH	Tutto è ON, più android.flash.firingPower, android.flash.firingTime e android.flash.mode
	ON_ALWAYS_FLASH	Same as ON_AUTO_FLASH
	ON_AUTO_FLASH_RED_EYE	Same as ON_AUTO_FLASH
android.control.awbMode	OFF	Nessuno
	WHITE_BALANCE_*	android.colorCorrection.transform. Regolazioni specifiche della piattaforma se android.colorCorrection.mode è FAST o HIGH_QUALITY.
android.control.afMode	OFF	Nessuno
	FOCUS_MODE_*	android.lens.focusDistance
android.control.videoStabilization	OFF	Nessuno
	ON	Può regolare android.scaler.cropRegion per implementare la stabilizzazione video
android.control.mode	OFF	AE, AWB e AF sono disattivati
	AUTO	Vengono utilizzate le impostazioni individuali di AE, AWB e AF
	SCENE_MODE_*	Può ignorare tutti i parametri elencati sopra. I controlli 3A individuali sono disattivati.

I controlli nel blocco Elaborazione immagine della Figura 2 funzionano 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.
• VELOCE: in questa modalità, il blocco di elaborazione potrebbe non rallentare la frequenza dei fotogrammi di output rispetto alla modalità OFF, ma dovrebbe comunque produrre l'output di migliore qualità possibile data questa limitazione. In genere, questa impostazione viene utilizzata per le modalità di anteprima o registrazione video oppure per l'acquisizione a raffica di immagini fisse. Su alcuni dispositivi, questa modalità potrebbe essere equivalente alla modalità OFF (non è possibile eseguire l'elaborazione senza rallentare la frequenza dei fotogrammi), mentre su alcuni dispositivi potrebbe essere equivalente alla modalità HIGH_QUALITY (la migliore qualità non rallenta comunque la frequenza dei fotogrammi).
• HIGH_QUALITY: in questa modalità, il blocco di elaborazione deve produrre il risultato di migliore qualità possibile, rallentando la frequenza dei frame di output in base alle necessità. In genere, viene utilizzato per l'acquisizione di immagini fisse di alta qualità. Alcuni blocchi includono un controllo manuale che può essere selezionato facoltativamente al posto di 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 della tonalità globale arbitraria.

Il frame rate massimo supportato da un sottosistema della videocamera dipende da molti fattori:

• Risoluzioni richieste dei flussi 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 di larghezza di banda in un modello il più semplice possibile. Il modello presentato ha le seguenti caratteristiche:

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