Sottosistema HAL

Richieste

Il framework dell'app invia richieste di risultati acquisiti al sottosistema della fotocamera. 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 quali risoluzione e formato dei pixel; controllo manuale di sensore, obiettivo e flash; modalità di funzionamento 3A; controllo dell'elaborazione da RAW a YUV; generazione di statistiche. Ciò consente un maggiore controllo sull'output e sull'elaborazione dei risultati. È possibile inviare più richieste contemporaneamente e l'invio delle 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 fotocamera include le implementazioni per i componenti della pipeline della fotocamera, come l'algoritmo 3A e i controlli di elaborazione. L'HAL della videocamera fornisce le interfacce per implementare le tue versioni di questi componenti. Per mantenere la compatibilità multipiattaforma tra più produttori di dispositivi e fornitori di Image Signal Processor (ISP o sensore della fotocamera), il modello della pipeline della fotocamera è virtuale e non corrisponde direttamente a nessun ISP reale. Tuttavia, è abbastanza simile alle pipeline di elaborazione reali da poter essere mappata al tuo hardware in modo efficiente. Inoltre, è sufficientemente astratto da consentire più algoritmi e ordini di operazioni diversi senza compromettere la qualità, l'efficienza o la compatibilità tra dispositivi.

La pipeline della fotocamera supporta anche gli attivatori che il framework dell'app può avviare per attivare funzionalità come la messa a fuoco automatica. Inoltre, invia notifiche al framework dell'app, informando le app di eventi come un blocco dell'autofocus 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 fa le seguenti ipotesi:

• L'output RAW Bayer non viene elaborato all'interno dell'ISP.
• Le statistiche vengono generate in base ai dati non elaborati del sensore.
• I vari blocchi di elaborazione che convertono i dati non elaborati del sensore in YUV sono in un ordine произвольный.
• Sebbene vengano mostrate più unità di scala e ritaglio, tutte le unità di scala condividono i controlli della regione di output (zoom digitale). Tuttavia, ogni unità potrebbe avere una risoluzione di output e un formato pixel diversi.

Riepilogo dell'utilizzo dell'API
Questo è un breve riepilogo dei passaggi per utilizzare l'API Android Camera. Consulta la sezione relativa all'avvio e alla sequenza di operazioni prevista per un'analisi dettagliata di questi passaggi, incluse le chiamate API.

1. Rileva ed esegue l'enumerazione dei dispositivi di fotocamera.
2. Apri il dispositivo e connetti gli ascoltatori.
3. Configura le uscite per il caso d'uso target (ad esempio acquisizione di foto, registrazione e così via).
4. Crea una o più richieste per il caso d'uso target.
5. Acquisisci/ripeti richieste e burst.
6. Ricevere i metadati dei risultati e i dati delle immagini.
7. Quando cambi caso d'uso, torna al passaggio 3.

Riepilogo del funzionamento dell'HAL

• Le richieste asincrone per le 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.
• Primo arrivato, primo servito per richieste e risultati, nonché 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 dell'acquisizione (ad eccezione delle routine 3A) sono encapsulati nelle richieste e nei risultati.

Figura 3. Panoramica di Camera HAL

Avvio e sequenza di funzionamento prevista

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

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

1. Dopo l'inizializzazione, il framework inizia a cercare eventuali fornitori di videocamere presenti che implementano l'interfaccia ICameraProvider. Se sono presenti uno o più di questi fornitori, il framework tenterà di stabilire una connessione.
2. Il framework enumera i dispositivi della videocamera tramite ICameraProvider::getCameraIdList().
3. Il framework esegue l'inizializzazione 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 per il dispositivo HAL.
2. Il framework richiede impostazioni predefinite per alcuni casi d'uso con chiamate a ICameraDeviceSession::constructDefaultRequestSettings(). Questo 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. Questo viene inviato 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 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), l'HAL chiama ICameraDeviceCallback::notify() con il messaggio SHUTTER, che include il numero di fotogramma e il timestamp dell'inizio dell'esposizione. Questo callback di notifica non deve avvenire prima della prima chiamata di processCaptureResult() per una richiesta, ma nessun risultato viene inviato a un'app per un'acquisizione fino a dopo la chiamata di notify() per l'acquisizione.
6. Dopo un ritardo della pipeline, l'HAL inizia a restituire le acquisizioni completate al framework con ICameraDeviceCallback::processCaptureResult(). Vengono restituiti nell'ordine in cui sono state inviate le richieste. È possibile inviare più richieste contemporaneamente, a seconda della profondità della pipeline del dispositivo HAL della fotocamera.

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

• Il framework potrebbe interrompere l'invio di nuove richieste, attendere il completamento delle acquisizioni esistenti (tutti i buffer sono stati riempiti, tutti i risultati sono stati restituiti) e 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 possono essere riutilizzati dalla configurazione precedente. Il framework continua quindi dalla prima richiesta di acquisizione all'HAL, se rimane almeno un stream di output registrato. In caso contrario, ICameraDeviceSession::configureStreams() è obbligatorio prima.
• Il framework potrebbe chiamare ICameraDeviceSession::close() per terminare la sessione della videocamera. Questo metodo può essere chiamato in qualsiasi momento quando non sono attive altre chiamate dall'ambito, anche se la chiamata potrebbe bloccarsi fino al completamento di tutte le acquisizioni in corso (tutti i risultati restituiti, tutti i buffer riempiti). Dopo il ritorno della chiamata a close(), non sono consentite altre chiamate a ICameraDeviceCallback dall'HAL. Una volta avviata la chiamataclose(), il framework potrebbe non chiamare altre funzioni del dispositivo HAL.
• In caso di errore o di 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 dovrebbe comportarsi come se fosse stata chiamata close(). Tuttavia, l'HAL deve cancellare o completare tutte le acquisizioni in sospeso prima di chiamare notify(), in modo che, una volta chiamato notify() con un errore fatale, il framework non riceva ulteriori callback dal dispositivo. I metodi diversi da close() devono restituire -ENODEV o NULL dopo che il metodo notify() viene restituito da un messaggio di errore fatale.

Figura 4. Flusso operativo della videocamera

Livelli hardware

I dispositivi con videocamera possono implementare diversi livelli di hardware a seconda delle loro funzionalità. Per ulteriori informazioni, consulta il 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 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 fotogramma 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 è attivo, oltre ad 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
	WHITE_BALANCE_*	android.colorCorrection.transform. Aggiustamenti specifici 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 impostazioni AE, AWB e AF individuali
	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 funzionano tutti su 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 aggiustamento della curva di tonalità non possono essere disattivati.
• VELOCE: in questa modalità, il blocco di elaborazione potrebbe non rallentare la frequenza frame di output rispetto alla modalità OFF, ma in caso contrario dovrebbe produrre l'output di qualità migliore possibile in base a questa limitazione. In genere, viene utilizzato per le modalità di anteprima o registrazione video o per l'acquisizione in sequenza per le immagini fisse. Su alcuni dispositivi, potrebbe essere equivalente alla modalità OFF (non è possibile eseguire alcuna elaborazione senza rallentare la frequenza frame) e su alcuni dispositivi potrebbe essere equivalente alla modalità HIGH_QUALITY (la qualità migliore non rallenta ancora la frequenza frame).
• HIGH_QUALITY: in questa modalità, il blocco di elaborazione deve produrre il risultato di qualità migliore possibile, rallentando la frequenza frame in uscita in base alle esigenze. In genere, viene utilizzata per acquisire foto di alta qualità. Alcuni blocchi includono un controllo manuale che può essere selezionato facoltativamente anziché VELOCE o ALTA_QUALITÀ. 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 frame massima supportata da un sottosistema della videocamera è una funzione di molti fattori:

• Risoluzioni richieste degli stream di immagini di output
• Disponibilità di modalità di raggruppamento/salto sull'imager
• La larghezza di banda dell'interfaccia dell'imager
• La larghezza di banda dei vari blocchi di elaborazione dell'ISP

Poiché questi fattori possono variare notevolmente tra diversi ISP e sensori, l'interfaccia HAL della fotocamera 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 produrre la risoluzione minima possibile in base alle dimensioni dello stream di output richieste dall'app. La risoluzione minima è definita come almeno uguale alle dimensioni dello stream di output più grande richiesto.
• Poiché qualsiasi richiesta può utilizzare uno o tutti gli stream di output attualmente configurati, il sensore e l'ISP devono essere configurati per supportare la scalabilità di una singola acquisizione su tutti gli stream contemporaneamente.
• Gli stream JPEG si comportano come stream YUV elaborati per le richieste per le quali non sono inclusi; nelle richieste a cui fanno riferimento direttamente, si comportano come stream JPEG.
• L'elaborazione JPEG può essere eseguita contemporaneamente al resto della pipeline della fotocamera, ma non può elaborare più di una foto alla volta.