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 tali risultati. Ciò include cose come la risoluzione e il formato pixel; sensore manuale, obiettivo e controllo flash; Modalità operative 3A; Controllo dell'elaborazione da RAW a YUV; e generazione di statistiche. Ciò consente un controllo molto maggiore sull'output e sull'elaborazione dei risultati. È possibile inviare più richieste contemporaneamente e l'invio delle richieste non è bloccante. E le richieste vengono sempre elaborate nell'ordine in cui vengono ricevute.

Figura 1. Modello di fotocamera

Il sottosistema HAL e fotocamera

Il sottosistema della fotocamera include le implementazioni per i componenti nella pipeline della fotocamera come l'algoritmo 3A e i controlli di elaborazione. L'HAL della fotocamera fornisce le interfacce per implementare le versioni di questi componenti. Per mantenere la compatibilità multipiattaforma tra più produttori di dispositivi e fornitori di processori di segnale di immagine (ISP o sensore della fotocamera), il modello di pipeline della fotocamera è virtuale e non corrisponde direttamente ad alcun ISP reale. Tuttavia, è abbastanza simile alle pipeline di elaborazione reali in modo da poterlo mappare in modo efficiente sul tuo hardware. Inoltre, è sufficientemente astratto da consentire molteplici algoritmi e ordini di funzionamento diversi senza compromettere la qualità, l'efficienza o la compatibilità tra dispositivi.

La pipeline della fotocamera supporta anche i trigger che il framework dell'app può avviare per attivare elementi come la messa a fuoco automatica. Inoltre, invia notifiche al framework dell'app, notificando alle app eventi come il blocco della messa a fuoco automatica o errori.

Figura 2. Conduttura della fotocamera

Tieni presente che alcuni blocchi di elaborazione delle immagini mostrati nel diagramma sopra non sono ben definiti nella versione iniziale. La pipeline della fotocamera parte dai seguenti presupposti:

• L'output RAW Bayer non viene sottoposto a elaborazione all'interno dell'ISP.
• Le statistiche vengono generate in base ai dati grezzi del sensore.
• I vari blocchi di elaborazione che convertono i dati grezzi del sensore in YUV sono in un ordine arbitrario.
• Mentre vengono visualizzate più unità di scala e ritaglio, tutte le unità di ridimensionamento condividono i controlli della regione di output (zoom digitale). Tuttavia, ciascuna unità può 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 della fotocamera Android. Consulta la sezione Avvio e sequenza operativa prevista per un'analisi dettagliata di questi passaggi, comprese le chiamate API.

1. Ascolta ed enumera i dispositivi della fotocamera.
2. Apri il dispositivo e connetti gli ascoltatori.
3. Configura gli output per il caso d'uso target (come acquisizione di immagini fisse, registrazione, ecc.).
4. Creare richieste per il caso d'uso di destinazione.
5. Cattura/ripeti richieste e burst.
6. Ricevi metadati dei risultati e dati di immagine.
7. Quando si cambia caso d'uso, tornare al passaggio 3.

Riepilogo delle operazioni HAL

• Le richieste asincrone di acquisizioni provengono dal framework.
• Il dispositivo HAL deve elaborare le richieste in ordine. E per ogni richiesta, produci metadati dei risultati di output e uno o più buffer di immagini di output.
• First-in, first-out per richieste e risultati e per i flussi 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 insieme se necessario.
• Tutta la configurazione e lo stato dell'acquisizione (ad eccezione delle routine 3A) sono incapsulati nelle richieste e nei risultati.

Figura 3. Panoramica dell'HAL della telecamera

Avvio e sequenza operativa prevista

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

Enumerazione, apertura dei dispositivi della fotocamera e creazione di una sessione attiva

1. Dopo l'inizializzazione, il framework inizia ad ascoltare eventuali fornitori di fotocamere presenti che implementano l'interfaccia ICameraProvider . Se tale o più fornitori sono presenti, il framework tenterà di stabilire una connessione.
2. Il framework enumera i dispositivi della fotocamera tramite ICameraProvider::getCameraIdList() .
3. Il framework istanzia 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.

Utilizzando una sessione attiva della fotocamera

1. Il framework chiama ICameraDeviceSession::configureStreams() con un elenco di flussi di input/output sul 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 ICameraDevice::open .
3. Il framework costruisce e invia la prima richiesta di acquisizione all'HAL con impostazioni basate su uno dei set di impostazioni predefinite e con almeno un flusso di output registrato in precedenza dal framework. Questo viene inviato all'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 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 l'acquisizione), l'HAL chiama ICameraDeviceCallback::notify() con il messaggio SHUTTER, incluso il numero di fotogramma 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 consegnato a un'applicazione per un'acquisizione finché non viene chiamato 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 vengono restituiti nello stesso ordine in cui sono state presentate le richieste. Possono essere in esecuzione 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 riempiti, tutti i risultati restituiti) e quindi chiamare nuovamente ICameraDeviceSession::configureStreams() . Ciò reimposta l'hardware della fotocamera e la pipeline per un nuovo set di flussi di input/output. Alcuni flussi potrebbero essere riutilizzati dalla configurazione precedente. Il framework continua quindi dalla prima richiesta di acquisizione all'HAL, se rimane almeno un flusso di output registrato. (Altrimenti, è necessario prima ICameraDeviceSession::configureStreams() .)
• Il framework può chiamare ICameraDeviceSession::close() per terminare la sessione della fotocamera. Questo può essere chiamato in qualsiasi momento quando non sono attive altre chiamate dal framework, sebbene la chiamata possa bloccarsi fino al completamento di tutte le acquisizioni in volo (tutti i risultati restituiti, tutti i buffer riempiti). Dopo la restituzione della chiamata close() , non sono consentite più 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 il ritorno da una notifica di errore irreversibile a livello di dispositivo, l'HAL dovrebbe comportarsi come se su di esso 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 che notify() viene chiamato con un errore irreversibile, il framework non riceverà ulteriori callback dal dispositivo. I metodi oltre a close() dovrebbero restituire -ENODEV o NULL dopo che il metodo notify() ritorna da un messaggio di errore irreversibile.

Figura 4. Flusso operativo della telecamera

Livelli hardware

I dispositivi fotocamera possono implementare diversi livelli hardware a seconda delle loro capacità. Per ulteriori informazioni, vedere livello hardware supportato .

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

A seconda delle impostazioni nel blocco di controllo 3A, la pipeline della fotocamera ignora alcuni parametri nella richiesta di acquisizione dell'applicazione e utilizza invece i valori forniti dalle routine di controllo 3A. Ad esempio, quando l'esposizione automatica è attiva, il tempo di esposizione, la durata del fotogramma e i parametri di sensibilità del sensore sono controllati dall'algoritmo della piattaforma 3A e qualsiasi valore specificato dall'app viene ignorato. 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à.

I controlli nel blocco Elaborazione immagine nella Figura 2 funzionano tutti secondo un principio simile e generalmente ciascun blocco ha tre modalità:

• OFF: questo blocco di elaborazione è disabilitato. I blocchi demosaico, correzione del colore e regolazione della curva dei toni non possono essere disabilitati.
• VELOCE: in questa modalità, il blocco di elaborazione potrebbe non rallentare il frame rate di output rispetto alla modalità OFF, ma dovrebbe altrimenti produrre l'output della migliore qualità possibile data tale restrizione. In genere, viene utilizzato per le modalità di anteprima o di registrazione video o per l'acquisizione a raffica di immagini fisse. Su alcuni dispositivi, ciò potrebbe essere equivalente alla modalità OFF (non è possibile eseguire alcuna elaborazione senza rallentare la frequenza dei fotogrammi) e 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 dovrebbe produrre il miglior risultato di qualità possibile, rallentando il frame rate di output secondo necessità. In genere, questo verrebbe utilizzato per l'acquisizione di immagini fisse di alta qualità. Alcuni blocchi includono un controllo manuale che può essere opzionalmente selezionato 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 dei toni supporta una curva di mappatura dei toni globale arbitraria.

Il frame rate massimo che può essere supportato da un sottosistema di telecamera è una funzione di molti fattori:

• Risoluzioni richieste dei flussi di immagini di output
• Disponibilità di modalità binning/skipping 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 cerca di astrarre le restrizioni della larghezza di banda nel modello più semplice possibile. Il modello presentato ha le seguenti caratteristiche:

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