Compatibilité avec plusieurs caméras

Android 9 a introduit la prise en charge de l'API pour les appareils multi-caméras via un nouvel appareil photo logique composé de deux appareils photo physiques ou plus pointant dans la même direction. L'appareil photo logique est exposé en tant que CameraDevice/CaptureSession unique à une application, ce qui permet d'interagir avec les fonctionnalités multicaméras intégrées à HAL. Les applications peuvent éventuellement accéder aux flux, métadonnées et commandes de la caméra physique sous-jacente, et les contrôler.

Compatibilité avec plusieurs caméras

Figure 1 : Compatibilité avec plusieurs caméras

Dans ce schéma, différents ID de caméras sont associés à des couleurs. L'application peut diffuser les tampons bruts 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 multicaméras doivent être annoncés avec la fonctionnalité multicaméra logique.

Les clients de l'appareil photo peuvent interroger l'ID de l'appareil photo des appareils physiques dont est composé un appareil photo logique particulier en appelant getPhysicalCameraIds(). Les ID renvoyés dans le résultat sont ensuite utilisés pour contrôler individuellement les appareils physiques via setPhysicalCameraId(). Les résultats de ces demandes individuelles peuvent être interrogés à partir du résultat complet en appelant getPhysicalCameraResults().

Les requêtes individuelles de caméras physiques ne peuvent accepter qu'un sous-ensemble limité de paramètres. Pour obtenir la liste des paramètres acceptés, les développeurs peuvent appeler getAvailablePhysicalCameraRequestKeys().

Les flux de caméras physiques ne sont acceptés que pour les demandes sans retraitement et uniquement pour les capteurs monochromes et Bayer.

Implémentation

Check-list de l'assistance

Pour ajouter des appareils multicaméra logiques côté HAL :

Pour les appareils exécutant Android 9, les appareils photo doivent permettre de remplacer un flux logique YUV/RAW par des flux physiques de même taille (ne s'applique pas aux flux RAW) et de même format provenant de deux caméras physiques. Cela ne s'applique pas aux appareils exécutant Android 10.

Pour les appareils équipés d'Android 10 et dont la version de l'appareil HAL de l'appareil photo est 3.5 ou supérieure, l'appareil photo doit être compatible avec isStreamCombinationSupported pour que les applications puissent déterminer si une combinaison de flux spécifique contenant des flux physiques est prise en charge.

Carte de configuration du 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 carte de configuration des flux doivent être des flux logiques.

Pour un appareil photo logique compatible avec la fonctionnalité RAW et doté de sous-caméras physiques de différentes tailles, si une application configure un flux RAW logique, l'appareil photo logique ne doit pas passer à des sous-caméras physiques avec des tailles de capteur différentes. Cela garantit que les applications de capture RAW existantes ne sont pas interrompues.

Pour profiter du zoom optique implémenté par HAL en basculant entre les sous-caméras physiques lors de la capture RAW, les applications doivent configurer des flux de sous-caméras 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 d'appareil.

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

Sur les appareils équipés d'Android 9, pour chaque combinaison de flux garantie, la caméra logique doit être compatible avec :

  • Remplacer un flux logique YUV_420_888 ou brut par deux flux physiques de même taille et de même format, chacun provenant d'une caméra physique distincte, à condition que la taille et le format soient compatibles avec les caméras physiques.

  • Ajout de deux flux bruts, un pour chaque caméra physique, si la caméra logique n'annonce pas de 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.

  • Utiliser des flux physiques à la place d'un flux logique de même taille et de même format. Cela ne doit pas ralentir la fréquence d'images de la capture lorsque la durée minimale des images des flux physiques et logiques est la même.

Considérations sur les performances et la consommation d'énergie

  • Performances :

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

  • Alimentation :

    • L'optimisation de la consommation d'énergie du HAL continue de fonctionner par défaut.
    • La configuration ou la demande de flux physiques peuvent remplacer l'optimisation de l'alimentation interne de HAL et entraîner une consommation d'énergie plus importante.

Personnalisation

Vous pouvez personnaliser l'implémentation de votre appareil de différentes manières.

  • La sortie fusionnée du périphérique de caméras logiques dépend entièrement de l'implémentation HAL. La décision concernant la façon dont les flux logiques fusionnés sont dérivés des caméras physiques est transparente pour l'application et le framework de caméras Android.
  • Les demandes et les résultats physiques individuels peuvent être pris en charge de manière facultative. L'ensemble des paramètres disponibles dans ces 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 d'appareils photo pouvant être ouverts directement par une application en choisissant de ne pas annoncer certains ou tous les PHYSICAL_IDs dans getCameraIdList. L'appel de getPhysicalCameraCharacteristics doit ensuite renvoyer les caractéristiques de la caméra physique.

Validation

Les appareils multicaméra logiques doivent passer le CTS de la caméra comme n'importe quelle autre caméra standard. Les cas de test ciblant ce type d'appareil se trouvent dans le module LogicalCameraDeviceTest.

Ces trois tests ITS ciblent les systèmes multicaméras pour faciliter la fusion correcte des images :

Les tests des scènes 1 et 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 activées. Le test test_multi_camera_alignment affirme que les espacements, les orientations et les paramètres de distorsion de la caméra sont correctement chargés. Si le système multicaméra inclut une caméra à grand angle de vue (> 90°), la version 2 de la box ITS est requise.

Sensor_fusion est un deuxième banc d'essai qui permet un mouvement de téléphone répété et prescrit, et affirme que les codes temporels du gyroscope et du capteur d'image correspondent et que les images multicaméras sont synchronisées.

Toutes les boîtes sont disponibles auprès d'AcuSpec, Inc. (www.acuspecinc.com, fred@acuspecinc.com) et MYWAY Manufacturing (www.myway.tw, sales@myway.tw). De plus, le boîtier ITS rev1 peut être acheté auprès de West-Mark (www.west-mark.com, dgoodman@west-mark.com).

Bonnes pratiques

Pour profiter pleinement des fonctionnalités offertes par la multicaméra tout en maintenant la compatibilité de l'application, suivez ces bonnes pratiques lorsque vous implémentez un appareil multicaméra logique :

  • (Android 10 ou version ultérieure) Masquez les sous-caméras physiques de getCameraIdList. Cela réduit le nombre de caméras pouvant être ouvertes directement par les applications, ce qui évite aux applications d'avoir une logique de sélection de caméras complexe.
  • (Android 11 ou version ultérieure) Pour un appareil multicaméra logique compatible avec le zoom optique, implémentez l'API ANDROID_CONTROL_ZOOM_RATIO et utilisez ANDROID_SCALER_CROP_REGION uniquement pour le recadrage du format. ANDROID_CONTROL_ZOOM_RATIO permet à l'appareil de faire un zoom arrière et de conserver une meilleure précision. Dans ce cas, la 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 en savoir plus sur la façon dont ANDROID_SCALER_CROP_REGION fonctionne avec ANDROID_CONTROL_ZOOM_RATIO, consultez camera3_crop_reprocess#cropping.
  • Pour les appareils multicaméras dotés de caméras physiques aux capacités différentes, assurez-vous que l'appareil annonce la prise en charge d'une certaine valeur ou plage pour une commande 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 grand-angle, d'une caméra grand-angle et d'un téléobjectif, procédez comme suit :
    • Si les tailles de matrice active des caméras physiques sont différentes, le HAL de la caméra doit mapper les matrices actives des caméras physiques à 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. Ainsi, du point de vue de l'application, le système de coordonnées correspond à la taille de la matrice active de la caméra logique.
    • Si les caméras grand angle et téléobjectif prennent en charge l'autofocus, mais que la caméra ultra grand angle est à mise au point fixe, assurez-vous que la caméra logique annonce la prise en charge de l'autofocus. Le HAL doit simuler une machine à états d'autofocus pour l'appareil photo ultra grand-angle afin que, lorsque l'application effectue un zoom arrière sur l'objectif ultra grand-angle, le fait que l'appareil photo physique sous-jacent soit à mise au point fixe soit transparent pour l'application, et que les machines à états d'autofocus pour les modes AF compatibles fonctionnent comme prévu.
    • Si les caméras grand-angle et téléobjectif sont compatibles avec la résolution 4K à 60 fps, et que la caméra ultra grand-angle n'est compatible qu'avec la résolution 4K à 30 fps ou 1080p à 60 fps, mais pas avec la résolution 4K à 60 fps, assurez-vous que la caméra logique n'annonce pas la résolution 4K à 60 fps dans ses configurations de flux compatibles. Cela garantit l'intégrité des fonctionnalités de la caméra logique, en veillant à ce que l'application ne rencontre pas le problème de ne pas atteindre 4k à 60 fps avec une valeur ANDROID_CONTROL_ZOOM_RATIO inférieure à 1.
  • À partir d'Android 10, une multicaméra logique n'est pas requise pour prendre en charge les combinaisons de flux incluant des flux physiques. Si la HAL est compatible avec une combinaison de flux physiques :
    • (Android 11 ou version ultérieure) Pour mieux gérer les cas d'utilisation tels que la profondeur à partir de la stéréo et le suivi du mouvement, définissez le champ de vision des sorties de flux physiques sur la valeur la plus grande possible que le matériel peut atteindre. Toutefois, si un flux physique et un flux logique proviennent de la même caméra physique, des limites matérielles peuvent forcer le champ de vision du flux physique à être identique à celui du flux logique.
    • Pour faire face à la pression de mémoire causée par plusieurs flux physiques, assurez-vous que les applications utilisent discardFreeBuffers pour libérer les tampons libres (tampons 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 un certain temps.
    • Si les flux physiques provenant 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 mémoire tampon soit utilisée pour prendre en charge deux surfaces orientées application, ce qui réduit la consommation de mémoire.