Supporto multi-fotocamera

Android 9 ha introdotto il supporto API per dispositivi multi-camera attraverso un nuovo dispositivo fotocamera logica composto da due o più dispositivi fotocamera fisici che puntano nella stessa direzione. Il dispositivo della fotocamera logica viene esposto come un singolo CameraDevice/CaptureSession a un'app che consente l'interazione con le funzionalità multi-camera integrate in HAL. Le app possono facoltativamente accedere e controllare i flussi fisici, i metadati e i controlli della fotocamera sottostante.

Supporto multi-camera

Figura 1. Supporto multi-camera

In questo diagramma, i diversi ID della telecamera sono codificati a colori. L'app può eseguire lo streaming di buffer raw da ciascuna fotocamera fisica contemporaneamente. È anche possibile impostare controlli separati e ricevere metadati separati da diverse fotocamere fisiche.

Esempi e fonti

Dispositivi multi-camera devono essere pubblicizzati con la capacità multi-camera logico .

I clienti della fotocamera possono interrogare l'ID della telecamera dei dispositivi fisici una particolare fotocamera logica è fatta di chiamando getPhysicalCameraIds() . Gli ID restituiti come parte del risultato vengono quindi usati per controllare dispositivi fisici singolarmente attraverso setPhysicalCameraId() . I risultati di tali richieste individuali possono essere interrogati dal risultato completo invocando getPhysicalCameraResults() .

Le richieste di singole telecamere fisiche possono supportare solo un sottoinsieme limitato di parametri. Per ricevere un elenco dei parametri supportati, gli sviluppatori possono chiamare getAvailablePhysicalCameraRequestKeys() .

I flussi fisici della fotocamera sono supportati solo per le richieste di non rielaborazione e solo per i sensori monocromatici e Bayer.

Implementazione

Lista di controllo del supporto

Per aggiungere dispositivi logici multi-camera sul lato HAL:

Per i dispositivi con Android 9, i dispositivi con fotocamera devono supportare la sostituzione di un flusso logico YUV/RAW con flussi fisici della stessa dimensione (non si applica ai flussi RAW) e lo stesso formato da due fotocamere fisiche. Questo non si applica ai dispositivi con Android 10.

Per i dispositivi con Android 10 in cui la versione dispositivo HAL fotocamera è 3,5 o superiore, il dispositivo di telecamera deve supportare isStreamCombinationSupported per applicazioni per interrogare se una particolare combinazione corrente contenente flussi fisici è supportato.

Mappa di configurazione del flusso

Per una telecamera logico, le combinazioni flusso obbligatorie per il dispositivo telecamera di un certo livello hardware è lo stesso di quello che è richiesto in CameraDevice.createCaptureSession . Tutti i flussi nella mappa di configurazione dei flussi devono essere flussi logici.

Per un dispositivo con fotocamera logica che supporta la funzionalità RAW con sottocamere fisiche di dimensioni diverse, se un'app configura un flusso RAW logico, il dispositivo con fotocamera logica non deve passare a sottocamere fisiche con sensori di dimensioni diverse. Ciò garantisce che le app di acquisizione RAW esistenti non si rompano.

Per sfruttare lo zoom ottico implementato da HAL passando da una fotocamera secondaria fisica a un'altra durante l'acquisizione RAW, le app devono configurare flussi di fotocamere secondarie fisiche anziché un flusso RAW logico.

Combinazione di streaming garantita

Sia la telecamera logica e le sue sottostanti telecamere fisiche devono garantire le combinazioni flusso obbligatorie richieste per i loro livelli di dispositivo.

Un dispositivo fotocamera logica dovrebbe funzionare allo stesso modo di un dispositivo fotocamera fisico in base al livello e alle capacità dell'hardware. È consigliabile che il suo set di funzionalità sia un superset di quello delle singole fotocamere fisiche.

Sui dispositivi con Android 9, per ogni combinazione di streaming garantita, la fotocamera logica deve supportare:

  • Sostituzione di un flusso logico YUV_420_888 o raw con due flussi fisici della stessa dimensione e formato, ciascuno da una fotocamera fisica separata, dato che le dimensioni e il formato sono supportati dalle fotocamere fisiche.

  • Aggiunta di due flussi raw, uno da ciascuna fotocamera fisica, se la fotocamera logica non pubblicizza la capacità RAW, ma le fotocamere fisiche sottostanti lo fanno. Questo di solito si verifica quando le fotocamere fisiche hanno sensori di dimensioni diverse.

  • Utilizzo di flussi fisici al posto di un flusso logico della stessa dimensione e formato. Questo non deve rallentare la frequenza dei fotogrammi dell'acquisizione quando la durata minima dei fotogrammi dei flussi fisici e logici è la stessa.

Considerazioni su prestazioni e potenza

  • Prestazione:

    • La configurazione e lo streaming di flussi fisici può rallentare la velocità di acquisizione della telecamera logica a causa di vincoli di risorse.
    • L'applicazione delle impostazioni della fotocamera fisica potrebbe rallentare la velocità di acquisizione se le fotocamere sottostanti vengono impostate con frame rate diversi.
  • Potenza:

    • L'ottimizzazione della potenza di HAL continua a funzionare nel caso predefinito.
    • La configurazione o la richiesta di flussi fisici può ignorare l'ottimizzazione dell'alimentazione interna di HAL e comportare un maggiore consumo di energia.

personalizzazione

Puoi personalizzare l'implementazione del tuo dispositivo nei seguenti modi.

  • L'uscita fusa del dispositivo della fotocamera logica dipende interamente dall'implementazione HAL. La decisione su come derivare i flussi logici fusi dalle fotocamere fisiche è trasparente per l'app e il framework della fotocamera Android.
  • Richieste fisiche individuali e risultati possono essere facoltativamente supportati. L'insieme dei parametri disponibili in tali richieste è inoltre interamente dipendente dall'implementazione specifica di HAL.
  • Da Android 10, l'HAL può ridurre il numero di telecamere che possono essere aperti direttamente da un app eleggendo non pubblicizzare alcuni o tutti i PHYSICAL_IDs in getCameraIdList . Calling getPhysicalCameraCharacteristics devono quindi tornare le caratteristiche della fotocamera fisica.

Convalida

I dispositivi logici multi-camera devono superare il CTS della telecamera come qualsiasi altra telecamera normale. I test che colpiscono questo tipo di dispositivo possono essere trovati nel LogicalCameraDeviceTest modulo.

Questi tre test ITS prendono di mira i sistemi multi-camera per facilitare la corretta fusione delle immagini:

I test scena 1 e scena 4 eseguite con l' ITS-in-a-box banco di prova. Il test_multi_camera_match prova afferma che la luminosità del centro delle immagini corrispondenti quando le due telecamere sono entrambi attivati. Il test_multi_camera_alignment prova afferma che spaziature telecamera, orientamenti e parametri di distorsione vengono caricati correttamente. Se il sistema multi-camera include una telecamera Wide FoV (>90o), è necessaria la versione rev2 della scatola ITS.

Sensor_fusion è un secondo banco di prova che consente ripetute, movimento telefono previsto e afferma che i timestamp giroscopio e sensori immagine corrispondano e che i telai multi-camera sono sincronizzati.

Tutte le scatole sono disponibili attraverso AcuSpec, Inc. ( www.acuspecinc.com , fred@acuspecinc.com) e MYWAY Manufacturing ( www.myway.tw , sales@myway.tw). Inoltre, la REV1 sua scatola può essere acquistato attraverso West-Mark ( www.west-mark.com , dgoodman@west-mark.com).

Migliori pratiche

Per sfruttare appieno le funzionalità abilitate dalla multi-camera mantenendo la compatibilità delle app, segui queste best practice quando implementi un dispositivo logico multi-camera:

  • (Android 10 o superiore) Nascondere sotto-telecamere fisici da getCameraIdList . Ciò riduce il numero di telecamere che possono essere aperte direttamente dalle app, eliminando la necessità per le app di avere una logica di selezione della telecamera complessa.
  • (Android 11 o superiore) Per un dispositivo multi-camera logico sostenere zoom ottico, implementano ANDROID_CONTROL_ZOOM_RATIO API, e l'uso ANDROID_SCALER_CROP_REGION per proporzioni ritaglio soltanto. ANDROID_CONTROL_ZOOM_RATIO consente al dispositivo per diminuire e mantenere una migliore precisione. In questo caso, l'HAL deve regolare il sistema di coordinate ANDROID_SCALER_CROP_REGION , ANDROID_CONTROL_AE_REGIONS , ANDROID_CONTROL_AWB_REGIONS , ANDROID_CONTROL_AF_REGIONS , ANDROID_STATISTICS_FACE_RECTANGLES e ANDROID_STATISTICS_FACE_LANDMARKS per trattare il campo post-zoom di vista come matrice attiva sensore. Per ulteriori informazioni su come ANDROID_SCALER_CROP_REGION collabora con ANDROID_CONTROL_ZOOM_RATIO , vedi camera3_crop_reprocess#cropping .
  • Per i dispositivi multicamera con fotocamere fisiche con capacità diverse, assicurati che il dispositivo annunci il supporto per un determinato valore o intervallo per un controllo solo se l'intero intervallo di zoom supporta il valore o l'intervallo. Ad esempio, se la fotocamera logica è composta da una fotocamera ultrawide, grandangolare e teleobiettivo, procedi come segue:
    • Se le dimensioni di matrice attivi delle telecamere fisiche sono differenti, l'HAL telecamera deve fare la mappatura da array attivi delle telecamere fisici alla telecamera matrice attiva logico ANDROID_SCALER_CROP_REGION , ANDROID_CONTROL_AE_REGIONS , ANDROID_CONTROL_AWB_REGIONS , ANDROID_CONTROL_AF_REGIONS , ANDROID_STATISTICS_FACE_RECTANGLES e ANDROID_STATISTICS_FACE_LANDMARKS affinché da dell'app prospettiva, il sistema di coordinate è la dimensione dell'array attivo della telecamera logica.
    • Se le fotocamere grandangolari e teleobiettivo supportano l'autofocus, ma la fotocamera ultrawide è a fuoco fisso, assicurati che la fotocamera logica pubblicizzi il supporto dell'autofocus. L'HAL deve simulare una macchina a stati di messa a fuoco automatica per la fotocamera ultrawide in modo che quando l'app esegue lo zoom indietro sull'obiettivo ultrawide, il fatto che la fotocamera fisica sottostante sia a fuoco fisso è trasparente per l'app e le macchine a stati di messa a fuoco automatica per le modalità AF supportate funzionare come previsto.
    • Se le fotocamere grandangolari e teleobiettivo supportano 4K a 60 fps e la fotocamera ultrawide supporta solo 4K a 30 fps o 1080p a 60 fps, ma non 4K a 60 fps, assicurati che la fotocamera logica non pubblicizzi 4K a 60 fps in le sue configurazioni di flusso supportate. Ciò garantisce l'integrità delle capacità logici delle telecamere, assicurando che l'applicazione non funzionerà in questione di non raggiungere 4k @ 60 fps alla ANDROID_CONTROL_ZOOM_RATIO valore inferiore a 1.
  • A partire da Android 10, non è necessaria una multicamera logica per supportare le combinazioni di flussi che includono flussi fisici. Se l'HAL supporta una combinazione con flussi fisici:
    • (Android 11 o versioni successive) Per gestire meglio i casi d'uso come la profondità dallo stereo e il tracciamento del movimento, rendere il campo visivo degli output del flusso fisico il più ampio possibile per l'hardware. Tuttavia, se un flusso fisico e un flusso logico provengono dalla stessa telecamera fisica, le limitazioni hardware potrebbero imporre che il campo visivo del flusso fisico sia lo stesso del flusso logico.
    • Per affrontare la pressione di memoria causata da più flussi fisici, assicurarsi che le applicazioni utilizzano discardFreeBuffers deallocare i buffer liberi (buffer che vengono rilasciati dal consumatore, ma non ancora rimosse dalla coda per il produttore) se un flusso fisico dovrebbe essere inattivo per un periodo di tempo.
    • Se i flussi fisici da diverse telecamere fisici non sono tipicamente collegati alla stessa richiesta, assicurarsi app utilizzano surface group in modo che un buffer coda viene utilizzato per eseguire due superfici app-rivestimento, riducendo il consumo di memoria.