Prise en charge de plusieurs caméras

Android 9 a introduit la prise en charge de l'API pour les périphériques multi-caméras via un nouveau périphérique de caméra logique composé de deux ou plusieurs périphériques de caméra physiques pointant dans la même direction. Le périphérique de caméra logique est exposé en tant que CameraDevice/CaptureSession unique à une application permettant une interaction avec les fonctionnalités multi-caméras intégrées à HAL. Les applications peuvent éventuellement accéder et contrôler les flux de caméras physiques sous-jacents, les métadonnées et les commandes.

Prise en charge de plusieurs caméras

Figure 1 . Prise en charge de plusieurs caméras

Dans ce schéma, les différents identifiants de caméra sont codés par couleur. L'application peut diffuser des tampons bruts à partir de chaque caméra physique en même temps. Il est également possible de définir des commandes distinctes et de recevoir des métadonnées distinctes de différentes caméras physiques.

Exemples et sources

Les appareils multi-caméras doivent être annoncés avec la capacité logique multi-caméra .

Les clients de caméra peuvent interroger l'ID de caméra des périphériques physiques dont une caméra logique particulière est constituée en appelant getPhysicalCameraIds() . Les ID renvoyés dans le cadre du résultat sont ensuite utilisés pour contrôler les périphériques physiques individuellement via setPhysicalCameraId() . Les résultats de ces demandes individuelles peuvent être interrogés à partir du résultat complet en getPhysicalCameraResults() .

Les demandes de caméras physiques individuelles peuvent ne prendre en charge qu'un sous-ensemble limité de paramètres. Pour recevoir une liste des paramètres pris en charge, les développeurs peuvent appeler getAvailablePhysicalCameraRequestKeys() .

Les flux de caméras physiques sont pris en charge uniquement pour les demandes sans retraitement et uniquement pour les capteurs monochromes et Bayer.

Mise en œuvre

Aide-mémoire

Pour ajouter des périphériques logiques multi-caméras côté HAL :

Pour les appareils exécutant Android 9, les appareils photo doivent prendre en charge le remplacement d'un flux YUV/RAW logique par des flux physiques de la même taille (ne s'applique pas aux flux RAW) et du même format à partir de deux caméras physiques. Cela ne s'applique pas aux appareils exécutant Android 10.

Pour les appareils exécutant Android 10 où la version de l'appareil photo HAL est 3.5 ou supérieure, l'appareil photo doit prendre en charge isStreamCombinationSupported pour que les applications demandent si une combinaison de flux particulière contenant des flux physiques est prise en charge.

Carte de configuration de flux

Pour une caméra logique, les combinaisons de flux obligatoires pour le périphérique de caméra d'un certain niveau matériel sont les mêmes que celles requises dans CameraDevice.createCaptureSession . Tous les flux de la mappe de configuration de flux doivent être des flux logiques.

Pour un appareil photo logique prenant en charge la capacité RAW avec des sous-caméras physiques de différentes tailles, si une application configure un flux RAW logique, l'appareil photo logique ne doit pas basculer vers des sous-caméras physiques avec des tailles de capteur différentes. Cela garantit que les applications de capture RAW existantes ne se cassent pas.

Pour tirer parti du zoom optique mis en œuvre par HAL en basculant entre les sous-caméras physiques lors de la capture RAW, les applications doivent configurer des flux de sous-caméra physiques au lieu d'un flux RAW logique.

Combinaison de flux garantie

La caméra logique et ses caméras physiques sous-jacentes doivent garantir les combinaisons de flux obligatoires requises pour leurs niveaux de périphérique.

Un appareil photo logique doit fonctionner de la même manière qu'un appareil photo physique en fonction de son niveau matériel et de ses capacités. Il est recommandé que son ensemble de fonctionnalités soit un sur-ensemble de celui des caméras physiques individuelles.

Sur les appareils exécutant Android 9, pour chaque combinaison de flux garantie, la caméra logique doit prendre en charge :

  • Remplacement d'un YUV_420_888 logique ou flux brut par deux flux physiques de même taille et format, chacun provenant d'une caméra physique distincte, étant donné que la taille et le format sont pris en charge par les caméras physiques.

  • Ajout de deux flux bruts, un provenant de chaque caméra physique, si la caméra logique n'annonce pas la capacité RAW, mais que les caméras physiques sous-jacentes le font. Cela se produit généralement lorsque les caméras physiques ont des tailles de capteur différentes.

  • Utilisation de flux physiques à la place d'un flux logique de même taille et format. Cela ne doit pas ralentir la fréquence d'images de la capture lorsque les durées minimales d'images des flux physiques et logiques sont identiques.

Considérations relatives aux performances et à l'alimentation

  • Performance:

    • La configuration et la diffusion de flux physiques peuvent ralentir le taux de capture de la caméra logique en raison de contraintes de ressources.
    • L'application de paramètres de caméra physiques peut ralentir le taux de capture si les caméras sous-jacentes sont placées dans des fréquences d'images différentes.

  • Du pouvoir:

    • L'optimisation de la puissance de HAL continue de fonctionner dans le cas par défaut.
    • La configuration ou la demande de flux physiques peut annuler l'optimisation de l'alimentation interne de HAL et entraîner une plus grande consommation d'énergie.

Personnalisation

Vous pouvez personnaliser la mise en œuvre de votre appareil des manières suivantes.

  • La sortie fusionnée du périphérique de caméra logique dépend entièrement de l'implémentation HAL. La décision sur la manière dont les flux logiques fusionnés sont dérivés des caméras physiques est transparente pour l'application et le cadre de caméra Android.
  • Les demandes physiques individuelles et les résultats peuvent être éventuellement pris en charge. L'ensemble des paramètres disponibles dans de telles requêtes dépend également entièrement de l'implémentation HAL spécifique.
  • À partir d'Android 10, la HAL peut réduire le nombre de caméras pouvant être ouvertes directement par une application en choisissant de ne pas annoncer tout ou partie des PHYSICAL_ID dans getCameraIdList . L'appel getPhysicalCameraCharacteristics doit alors renvoyer les caractéristiques de la caméra physique.

Validation

Les appareils multi-caméras logiques doivent passer le CTS de la caméra comme n'importe quelle autre caméra standard. Les cas de test qui ciblent ce type de périphérique se trouvent dans le module LogicalCameraDeviceTest .

Ces trois tests ITS ciblent les systèmes multi-caméras pour faciliter la bonne fusion des images :

Les tests de la scène 1 et de la scène 4 sont exécutés avec le banc d'essai ITS-in-a-box . Le test test_multi_camera_match affirme que la luminosité du centre des images correspond lorsque les deux caméras sont toutes les deux activées. Le test test_multi_camera_alignment affirme que les espacements, les orientations et les paramètres de distorsion des caméras sont correctement chargés. Si le système multi-caméras comprend une caméra Wide FoV (>90o), la version rev2 du boîtier ITS est requise.

Sensor_fusion est un deuxième banc d'essai qui permet des mouvements de téléphone répétés et prescrits et affirme que les horodatages du gyroscope et du capteur d'image correspondent et que les trames multi-caméras sont synchronisées.

Toutes les boîtes sont disponibles via AcuSpec, Inc. ( www.acuspecinc.com , fred@acuspecinc.com) et MYWAY Manufacturing ( www.myway.tw , sales@myway.tw). De plus, la boîte rev1 ITS peut être achetée via West-Mark ( www.west-mark.com , dgoodman@west-mark.com).

Les meilleures pratiques

Pour tirer pleinement parti des fonctionnalités activées par le multi-caméra tout en maintenant la compatibilité des applications, suivez ces meilleures pratiques lors de la mise en œuvre d'un appareil multi-caméra logique :

  • (Android 10 ou supérieur) Masquez les sous-caméras physiques de getCameraIdList . Cela réduit le nombre de caméras pouvant être directement ouvertes par les applications, éliminant ainsi la nécessité pour les applications d'avoir une logique de sélection de caméra complexe.
  • (Android 11 ou supérieur) Pour un appareil multi-caméras logique prenant en charge le zoom optique, implémentez l'API ANDROID_CONTROL_ZOOM_RATIO et utilisez ANDROID_SCALER_CROP_REGION pour le recadrage des proportions uniquement. ANDROID_CONTROL_ZOOM_RATIO permet à l'appareil d'effectuer un zoom arrière et de maintenir une meilleure précision. Dans ce cas, HAL doit ajuster le système de coordonnées de ANDROID_SCALER_CROP_REGION , ANDROID_CONTROL_AE_REGIONS , ANDROID_CONTROL_AWB_REGIONS , ANDROID_CONTROL_AF_REGIONS , ANDROID_STATISTICS_FACE_RECTANGLES et ANDROID_STATISTICS_FACE_LANDMARKS pour traiter le champ de vision post-zoom comme le tableau actif du capteur. Pour plus d'informations sur la façon dont ANDROID_SCALER_CROP_REGION fonctionne avec ANDROID_CONTROL_ZOOM_RATIO , voir camera3_crop_reprocess#cropping .
  • Pour les appareils multi-caméras avec des caméras physiques qui ont des capacités différentes, assurez-vous que l'appareil annonce la prise en charge d'une certaine valeur ou plage pour un contrôle uniquement si toute la plage de zoom prend en charge la valeur ou la plage. Par exemple, si la caméra logique est composée d'une caméra ultra-large, d'une caméra large et d'un téléobjectif, procédez comme suit :
    • Si les tailles de matrice active des caméras physiques sont différentes, la caméra HAL doit effectuer le mappage des matrices actives des caméras physiques vers la matrice active de la caméra logique pour ANDROID_SCALER_CROP_REGION , ANDROID_CONTROL_AE_REGIONS , ANDROID_CONTROL_AWB_REGIONS , ANDROID_CONTROL_AF_REGIONS , ANDROID_STATISTICS_FACE_RECTANGLES et ANDROID_STATISTICS_FACE_LANDMARKS afin qu'à partir de l'application perspective, le système de coordonnées est la taille du tableau actif de la caméra logique.
    • Si les caméras grand angle et téléobjectif prennent en charge la mise au point automatique, mais que la caméra ultra large est à mise au point fixe, assurez-vous que la caméra logique annonce la prise en charge de la mise au point automatique. Le HAL doit simuler une machine d'état de mise au point automatique pour la caméra ultra large afin que lorsque l'application effectue un zoom arrière sur l'objectif ultra large, le fait que la caméra physique sous-jacente est à mise au point fixe est transparent pour l'application, et les machines d'état de mise au point automatique pour les modes AF pris en charge travailler comme prévu.
    • Si les appareils photo grand angle et téléobjectif prennent en charge 4K à 60 ips et que l'appareil photo ultra large ne prend en charge que 4K à 30 ips ou 1080p à 60 ips, mais pas 4K à 60 ips, assurez-vous que l'appareil photo logique n'annonce pas 4k à 60 ips dans ses configurations de flux prises en charge. Cela garantit l'intégrité des capacités logiques de la caméra, garantissant que l'application ne rencontrera pas le problème de ne pas atteindre 4k @ 60 fps à une valeur ANDROID_CONTROL_ZOOM_RATIO inférieure à 1.
  • À partir d'Android 10, une multi-caméra logique n'est pas nécessaire pour prendre en charge les combinaisons de flux qui incluent des flux physiques. Si HAL prend en charge une combinaison avec des flux physiques :
    • (Android 11 ou supérieur) Pour mieux gérer les cas d'utilisation tels que la profondeur de la stéréo et le suivi de mouvement, élargissez le champ de vision des sorties de flux physiques autant que possible par le matériel. Cependant, si un flux physique et un flux logique proviennent de la même caméra physique, des limitations matérielles peuvent forcer le champ de vision du flux physique à être le même que celui du flux logique.
    • Pour faire face à la pression de la mémoire causée par plusieurs flux physiques, assurez-vous que les applications utilisentdiscardFreeBuffers pour discardFreeBuffers les tampons libres (tampons qui sont libérés par le consommateur, mais pas encore retirés de la file d'attente par le producteur) si un flux physique est censé être inactif pendant une période de temps.
    • Si les flux physiques de différentes caméras physiques ne sont généralement pas associés à la même requête, assurez-vous que les applications utilisent surface group afin qu'une file d'attente de tampon soit utilisée pour sauvegarder deux surfaces faisant face à l'application, ce qui réduit la consommation de mémoire.