Supporto della modalità multicamera

Android 9 ha introdotto il supporto API per i dispositivi multicamera tramite un nuovo dispositivo videocamera logica composto da due o più dispositivi videocamera fisici che puntano nella stessa direzione. Il dispositivo videocamera logica viene esposto come un singolo CameraDevice/CaptureSession a un'app, consentendo l'interazione con le funzionalità multicamera integrate nell'HAL. Le app possono facoltativamente accedere e controllare i flussi, i metadati e i controlli delle videocamere fisiche sottostanti.

Supporto multicamera

Figura 1. Supporto della modalità multicamera

In questo diagramma, i diversi ID videocamera sono codificati con colori diversi. L'app può eseguire lo streaming dei buffer non elaborati da ogni videocamera fisica contemporaneamente. È anche possibile impostare controlli separati e ricevere metadati separati da diverse videocamere fisiche.

Esempi e fonti

I dispositivi multicamera devono essere pubblicizzati con la funzionalità multicamera logica.

I client della videocamera possono eseguire una query sull'ID videocamera dei dispositivi fisici di cui è composta una determinata videocamera logica chiamando getPhysicalCameraIds(). Gli ID restituiti come parte del risultato vengono quindi utilizzati per controllare i singoli dispositivi fisici tramite setPhysicalCameraId(). I risultati di queste singole richieste possono essere interrogati dal risultato completo richiamando getPhysicalCameraResults().

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

I flussi delle videocamere fisiche sono supportati solo per le richieste di non rielaborazione e solo per i sensori monocromatici e Bayer.

Implementazione

Elenco di controllo del supporto

Per aggiungere dispositivi multicamera logici sul lato HAL:

Per i dispositivi che eseguono Android 9, i dispositivi videocamera devono supportare la sostituzione di un flusso logico YUV o RAW con flussi fisici della stessa dimensione (non si applica ai flussi RAW) e dello stesso formato da due videocamere fisiche. Questo non si applica ai dispositivi che eseguono Android 10.

Per i dispositivi che eseguono Android 10 in cui la versione del dispositivo HAL della videocamera è 3.5 o successiva, il dispositivo videocamera deve supportare isStreamCombinationSupported in modo che le app possano eseguire una query per verificare se è supportata una determinata combinazione di flussi contenente flussi fisici.

Mappa di configurazione dei flussi

Per una videocamera logica, le combinazioni di flussi obbligatorie per il dispositivo videocamera di un determinato livello hardware sono le stesse richieste in CameraDevice.createCaptureSession. Tutti i flussi nella mappa di configurazione dei flussi devono essere flussi logici.

Per un dispositivo videocamera logica che supporta la funzionalità RAW con videocamere secondarie fisiche di dimensioni diverse, se un'app configura un flusso RAW logico, il dispositivo videocamera logica non deve passare a videocamere secondarie fisiche con dimensioni del sensore diverse. In questo modo, le app di acquisizione RAW esistenti non vengono interrotte.

Per sfruttare lo zoom ottico implementato dall'HAL passando da una videocamera secondaria fisica all'altra durante l'acquisizione RAW, le app devono configurare i flussi delle videocamere secondarie fisiche anziché un flusso RAW logico.

Combinazione di flussi garantita

Sia la videocamera logica sia le videocamere fisiche sottostanti devono garantire le combinazioni di flussi obbligatorie richieste per i rispettivi livelli di dispositivo.

Un dispositivo videocamera logica deve funzionare allo stesso modo di un dispositivo videocamera fisica in base al livello e alle funzionalità hardware. Ti consigliamo che il suo set di funzionalità sia un superset di quello delle singole videocamere fisiche.

Sui dispositivi che eseguono Android 9, per ogni combinazione di flussi garantita, la videocamera logica deve supportare:

  • Sostituzione di un flusso logico YUV_420_888 o RAW con due flussi fisici della stessa dimensione e dello stesso formato, ciascuno da una videocamera fisica separata, a condizione che la dimensione e il formato siano supportati dalle videocamere fisiche.

  • Aggiunta di due flussi RAW, uno da ogni videocamera fisica, se la videocamera logica non pubblicizza la funzionalità RAW, ma le videocamere fisiche sottostanti sì. In genere, questo si verifica quando le videocamere fisiche hanno dimensioni del sensore diverse.

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

Considerazioni su prestazioni e consumo energetico

  • Prestazioni:

    • La configurazione e lo streaming dei flussi fisici potrebbero rallentare la frequenza di acquisizione della videocamera logica a causa di vincoli di risorse.
    • L'applicazione delle impostazioni della videocamera fisica potrebbe rallentare la frequenza di acquisizione se le videocamere sottostanti vengono impostate su frequenze fotogrammi diverse.

  • Consumo energetico:

    • L'ottimizzazione del consumo energetico dell'HAL continua a funzionare nel caso predefinito.
    • La configurazione o la richiesta di flussi fisici potrebbe sostituire l'ottimizzazione del consumo energetico interna dell'HAL e comportare un maggiore consumo energetico.

Personalizzazione

Puoi personalizzare l'implementazione del dispositivo nei seguenti modi.

  • L'output unito del dispositivo videocamera logica dipende interamente dall'implementazione dell'HAL. La decisione su come i flussi logici uniti vengono derivati dalle videocamere fisiche è trasparente per l'app e il framework della videocamera Android.
  • Le singole richieste e i singoli risultati fisici possono essere supportati facoltativamente. Anche il set di parametri disponibili in queste richieste dipende interamente dall'implementazione HAL specifica.
  • A partire da Android 10, l'HAL può ridurre il numero di videocamere che possono essere aperte direttamente da un'app scegliendo di non pubblicizzare alcuni o tutti gli ID fisici in getCameraIdList. La chiamata a getPhysicalCameraCharacteristics deve quindi restituire le caratteristiche della videocamera fisica.

Convalida

I dispositivi multicamera logici devono superare il CTS della videocamera come qualsiasi altra videocamera normale. I test case destinati a questo tipo di dispositivo sono disponibili nel LogicalCameraDeviceTest modulo.

Questi tre test ITS sono destinati ai sistemi multicamera per facilitare la corretta unione delle immagini:

I test della scena 1 e della scena 4 vengono eseguiti con il banco di prova ITS-in-a-box. Il test test_multi_camera_match verifica che la luminosità del centro delle immagini corrisponda quando entrambe le videocamere sono attivate. Il test test_multi_camera_alignment verifica che i parametri di spaziatura, orientamento e distorsione della videocamera vengano caricati correttamente. Se il sistema multicamera include una videocamera con campo visivo ampio (>90o), è necessaria la versione rev2 della scatola ITS.

Sensor_fusion è un secondo banco di prova che consente di eseguire movimenti del telefono ripetuti e prescritti e verifica che i timestamp del giroscopio e del sensore di immagine corrispondano e che i fotogrammi multicamera siano sincronizzati.

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

Best practice

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

  • (Android 10 o versioni successive) Nascondi le videocamere secondarie fisiche da getCameraIdList. In questo modo, si riduce il numero di videocamere che possono essere aperte direttamente dalle app, eliminando la necessità di logiche di selezione della videocamera complesse.
  • (Android 11 o versioni successive) Per un dispositivo multicamera logico che supporta lo zoom ottico, implementa l'API ANDROID_CONTROL_ZOOM_RATIO e utilizza ANDROID_SCALER_CROP_REGION solo per il ritaglio delle proporzioni. ANDROID_CONTROL_ZOOM_RATIO consente al dispositivo di ridurre lo zoom e mantenere una precisione migliore. In questo caso, l'HAL deve regolare il sistema di coordinate di 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 visivo post-zoom come l'array attivo del sensore. Per ulteriori informazioni su come ANDROID_SCALER_CROP_REGION funziona con ANDROID_CONTROL_ZOOM_RATIO, consulta camera3_crop_reprocess#cropping.
  • Per i dispositivi multicamera con videocamere fisiche con funzionalità diverse, assicurati che il dispositivo pubblicizzi 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 videocamera logica è composta da una videocamera ultrawide, una wide e una teleobiettivo:
    • Se le dimensioni dell'array attivo delle videocamere fisiche sono diverse, l' HAL della videocamera deve eseguire il mapping dagli array attivi delle videocamere fisiche a quello attivo della videocamera logica per 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 in modo che, dal punto di vista dell'app, il sistema di coordinate sia la dimensione dell'array attivo della videocamera logica.
    • Se le videocamere wide e teleobiettivo supportano la messa a fuoco automatica, ma la videocamera ultrawide ha una messa a fuoco fissa, assicurati che la videocamera logica pubblicizzi il supporto della messa a fuoco automatica. L'HAL deve simulare una macchina a stati di messa a fuoco automatica per la videocamera ultrawide in modo che, quando l'app riduce lo zoom sull'obiettivo ultrawide, il fatto che la videocamera fisica sottostante abbia una messa a fuoco fissa sia trasparente per l'app e le macchine a stati di messa a fuoco automatica per le modalità di messa a fuoco automatica supportate funzionino come previsto.
    • Se le videocamere wide e teleobiettivo supportano 4K a 60 fps e la videocamera ultrawide supporta solo 4K a 30 fps o 1080p a 60 fps, ma non 4K a 60 fps, assicurati che la videocamera logica non pubblicizzi 4k a 60 fps nelle configurazioni di flussi supportate. In questo modo, si garantisce l' integrità delle funzionalità della videocamera logica, assicurando che l'app non riscontri il problema di non raggiungere 4k a 60 fps con un ANDROID_CONTROL_ZOOM_RATIO valore inferiore a 1.
  • In Android 10 e versioni successive, una videocamera multicamera logica non è obbligata a 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à da stereo e il rilevamento del movimento, rendi il campo visivo degli output dei flussi fisici il più ampio possibile in base all'hardware. Tuttavia, se un flusso fisico e un flusso logico provengono dalla stessa videocamera fisica, le limitazioni hardware potrebbero imporre che il campo visivo del flusso fisico sia uguale a quello del flusso logico.
    • Per risolvere il problema della pressione della memoria causata da più flussi fisici, assicurati che le app utilizzino discardFreeBuffers per deallocare i buffer liberi (buffer rilasciati dal consumer, ma non ancora rimossi dalla coda dal producer) se è previsto che un flusso fisico rimanga inattivo per un periodo di tempo.
    • Se i flussi fisici di videocamere fisiche diverse non vengono in genere collegati alla stessa richiesta, assicurati che le app utilizzino surface group in modo che una coda di buffer venga utilizzata per supportare due superfici rivolte all'app, riducendo il consumo di memoria.