Sottosistema HAL

Questa pagina descrive il sottosistema HAL, incluse le richieste, il sottosistema della videocamera, la sequenza di avvio e funzionamento, i livelli hardware e le interazioni.

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 sull'output e sull'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.

Modello di richiesta della videocamera

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. Il HAL della videocamera fornisce interfacce per implementare le 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, è sufficientemente simile alle pipeline di elaborazione reali da poterla mappare in modo efficiente all' hardware. Inoltre, è sufficientemente 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.

Livello di astrazione hardware della videocamera

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 non elaborati del sensore.
  • I vari blocchi di elaborazione che convertono i dati non elaborati del sensore 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à potrebbe 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 previsto.

  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 esempio acquisizione di immagini fisse o registrazione).
  4. Crea 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 del funzionamento dell'HAL

  • Le richieste asincrone di acquisizione provengono dal framework.
  • Il dispositivo HAL deve elaborare le richieste in ordine. Per ogni richiesta, deve produrre metadati dei risultati di output e uno o più buffer di immagini di output.
  • Le richieste e i risultati vengono gestiti in base all'ordine di arrivo, così come 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.
Panoramica di Fotocamera HAL

Figura 3. Panoramica dell'HAL della videocamera.

Sequenza di avvio e funzionamento previsto

Questa sezione contiene una spiegazione dettagliata dei passaggi previsti quando si utilizza l'API della videocamera. Per le definizioni dell'interfaccia HIDL, consulta il file 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 sono presenti uno o più provider, il framework tenta 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 all'HAL con impostazioni basate su uno degli insiemi di impostazioni predefinite e con almeno uno stream di output registrato in precedenza dal framework. Questa richiesta viene inviata al HAL con ICameraDeviceSession::processCaptureRequest. L'HAL deve bloccare la restituzione di questa chiamata finché non è pronto 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), l'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 quell'acquisizione.
  6. Dopo un certo ritardo della pipeline, l'HAL inizia a restituire le acquisizioni completate al framework con ICameraDeviceCallback::processCaptureResult. Questi risultati 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 verifica una delle seguenti situazioni:

  • Il framework smette di inviare nuove richieste, attende il completamento delle acquisizioni esistenti (tutti i buffer riempiti, tutti i risultati restituiti) e poi chiama ICameraDeviceSession::configureStreams di nuovo. 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 uno stream di output registrato. (In caso contrario, ICameraDeviceSession::configureStreams è necessario prima.)
  • Il framework può chiamare ICameraDeviceSession::close per terminare la sessione della videocamera. Questa chiamata può essere eseguita in qualsiasi momento quando 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, l'HAL non può più chiamare ICameraDeviceCallback. Una volta avviata la chiamata close il framework non può 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 aver restituito una notifica di errore irreversibile a livello di dispositivo, l'HAL deve comportarsi come se fosse stata chiamata la funzione close. Tuttavia, l'HAL deve annullare o completare tutte le acquisizioni in sospeso prima di chiamare notify, in modo che dopo notify sia chiamato 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.
Flusso delle operazioni della videocamera

Figura 4. Flusso operativo della videocamera.

Livelli hardware

I dispositivi della videocamera possono implementare diversi livelli hardware a seconda delle loro funzionalità. Per ulteriori informazioni, consulta la pagina 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 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 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) e 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 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 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), mentre su altri potrebbe essere equivalente alla modalità HIGH_QUALITY (la qualità migliore 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 in base alle esigenze. 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 dipende da 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

Questi fattori possono variare notevolmente tra diversi ISP e sensori, pertanto 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 richiesta più grande.
  • Qualsiasi richiesta può utilizzare uno o tutti gli stream di output attualmente configurati, pertanto 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.