Compatibilité avec plusieurs caméras

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

Compatibilité avec plusieurs caméras

Figure 1 : Compatibilité avec plusieurs caméras

Dans ce diagramme, les différents ID de caméra sont codés par couleur. L'application peut diffuser simultanément des tampons bruts de chaque caméra physique. 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éra doivent être annoncés avec la fonctionnalité multicaméra logique.

Les clients de la caméra peuvent interroger l'ID de caméra des appareils physiques dont une caméra logique particulière est composée 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 requêtes individuelles peuvent être interrogés à partir du résultat complet en appelant getPhysicalCameraResults().

Les requêtes de caméras physiques individuelles 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 compatibles qu'avec les requêtes de non-retraitement et uniquement avec les capteurs monochromes et Bayer.

Implémentation

Checklist d'assistance

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

Pour les appareils équipés d'Android 9, les appareils photo doivent être compatibles avec 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 provenant de deux caméras physiques. Cela ne s'applique pas aux appareils équipés d'Android 10.

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

Carte de configuration des flux

Pour une caméra logique, les combinaisons de flux obligatoires pour l'appareil photo 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 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 passer à des sous-caméras physiques de différentes tailles de capteur. Cela garantit que les applications de capture RAW existantes ne sont pas endommagées.

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 garantis

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 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 fonctionnalités. Il est recommandé d'utiliser un sur-ensemble de fonctionnalités par rapport à celles des caméras physiques individuelles.

Sur les appareils équipés d'Android 9, la caméra logique doit prendre en charge les éléments suivants pour chaque combinaison de flux garanti:

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

  • Ajouter deux flux bruts, un provenant de chaque appareil photo physique, si l'appareil photo logique n'annonce pas la fonctionnalité RAW, alors 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 au lieu d'un flux logique de la même taille et du 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 identique.

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

  • Performances :

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

  • Alimentation :

    • L'optimisation de l'alimentation de HAL continue de fonctionner par défaut.
    • La configuration ou la demande de flux physiques peut 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 de l'appareil photo logique dépend entièrement de l'implémentation du HAL. La décision concernant la manière dont les flux logiques fusionnés sont dérivés des caméras physiques est transparente pour le framework de l'application et de l'appareil photo Android.
  • Les demandes et résultats physiques individuels peuvent être acceptés. 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, le HAL peut réduire le nombre d'appareils photo pouvant être ouverts directement par une application en choisissant de ne pas diffuser certains ou tous les PHYSICAL_ID 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 qui ciblent 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 de la scène 1 et de la scène 4 sont exécutés avec la plate-forme de test ITS-in-a-box. Le test test_multi_camera_match affirme que la luminosité au centre des images correspond lorsque les deux appareils photo sont activés. 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 à champ de vision large (>90°), la version 2 de la boîte ITS est requise.

Sensor_fusion est un deuxième banc d'essai qui permet de répéter des mouvements de téléphone prescrits 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 de MYWAY Manufacturing (www.myway.tw, sales@myway.tw). De plus, la boîte ITS rev1 peut être achetée via West-Mark (www.west-mark.com, dgoodman@west-mark.com).

Bonnes pratiques

Pour profiter pleinement des fonctionnalités activées par la multicaméra tout en conservant la compatibilité des applications, suivez ces bonnes pratiques lors de l'implémentation d'un appareil multicaméra logique:

  • (Android 10 ou version ultérieure) Masquer les sous-caméras physiques dans getCameraIdList. Cela réduit le nombre d'appareils photo pouvant être ouverts directement par les applications, ce qui élimine la nécessité d'avoir une logique de sélection d'appareil photo 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 d'effectuer un zoom arrière et de conserver une meilleure précision. Dans ce cas, le 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 après zoom comme le tableau actif du capteur. Pour en savoir plus sur le fonctionnement de ANDROID_SCALER_CROP_REGION avec ANDROID_CONTROL_ZOOM_RATIO, consultez camera3_crop_reprocess#cropping.
  • Pour les appareils multicaméras avec des caméras physiques aux fonctionnalités différentes, assurez-vous que l'appareil ne déclare la prise en charge d'une certaine valeur ou plage pour une commande que si la plage de zoom complète est compatible avec la valeur ou la plage. Par exemple, si l'appareil photo logique est composé d'un appareil photo ultra grand angle, d'un appareil photo grand angle et d'un appareil à 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 sur 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 que, du point de vue de l'application, le système de coordonnées corresponde à la taille de la matrice active de la caméra logique.
    • Si les caméras grand angle et téléobjectif sont compatibles avec l'autofocus, mais que la caméra ultra grand angle est à mise au point fixe, assurez-vous que l'appareil photo logique annonce la compatibilité avec l'autofocus. Le HAL doit simuler une machine d'état de mise au point automatique pour l'appareil photo ultra grand angle de sorte que lorsque l'application effectue un zoom arrière sur l'objectif ultra grand angle, la mise au point fixe de la caméra physique sous-jacente est transparente pour l'application. De plus, les machines d'état de mise au point automatique pour les modes de mise au point automatique fonctionnent comme prévu.
    • Si les caméras grand-angle et téléobjectif sont compatibles avec la 4K à 60 images par seconde, et que la caméra ultra grand-angle n'est compatible qu'avec la 4K à 30 images par seconde ou le 1080p à 60 images par seconde, mais pas avec la 4K à 60 images par seconde, assurez-vous que la caméra logique n'annonce pas la 4K à 60 images par seconde dans ses configurations de flux compatibles. Cela garantit l'intégrité des fonctionnalités logiques de l'appareil photo, ce qui garantit que l'application ne rencontrera pas le problème de non-atteinte de la résolution 4K à 60 FPS pour une valeur ANDROID_CONTROL_ZOOM_RATIO inférieure à 1.
  • À partir d'Android 10, il n'est pas nécessaire de disposer d'une multicaméra logique pour accepter les combinaisons de flux incluant des flux physiques. Si le HAL accepte une combinaison avec des 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 du suivi des mouvements, faites en sorte que le champ de vision des sorties de flux physiques soit aussi grand que possible par le matériel. Toutefois, si un flux physique et un flux logique proviennent de la même caméra physique, les limitations matérielles peuvent forcer le champ de vision du flux physique à être identique à celui du flux logique.
    • Pour résoudre la pression de mémoire causée par plusieurs flux physiques, assurez-vous que les applications utilisent discardFreeBuffers pour désallouer 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 une période donnée.
    • 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 prendre en charge deux surfaces orientées vers l'application, ce qui réduit la consommation de mémoire.