Prise en charge de plusieurs caméras

Android 9 a introduit la prise en charge de l'API pour les appareils multi-caméras via un nouveau périphérique de caméra logique composé de deux ou plusieurs caméras 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, les métadonnées et les contrôles des caméras physiques sous-jacentes.

Prise en charge multi-caméras

Figure 1 . Prise en charge multi-caméras

Dans ce diagramme, les différents identifiants de caméra sont codés par couleur. L'application peut diffuser simultanément les tampons bruts de chaque caméra physique. Il est également possible de définir des contrôles séparés et de recevoir des métadonnées distinctes provenant de différentes caméras physiques.

Exemples et sources

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

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

Les demandes de caméras physiques individuelles peuvent prendre en charge uniquement 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

Liste de contrôle d'assistance

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 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 fonctionnant sous Android 10.

Pour les appareils exécutant Android 10 sur lesquels la version de l'appareil HAL de la caméra est 3.5 ou supérieure, l'appareil photo doit prendre en charge isStreamCombinationSupported pour que les applications puissent demander si une combinaison de flux particulière 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 de flux doivent être des flux logiques.

Pour une caméra logique prenant en charge la fonctionnalité RAW avec des sous-caméras physiques de différentes tailles, si une application configure un flux RAW logique, la caméra 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 seront pas interrompues.

Pour tirer parti du zoom optique implémenté par HAL en basculant entre les sous-caméras physiques pendant 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 les caméras physiques sous-jacentes doivent garantir les combinaisons de flux obligatoires requises pour leurs niveaux de périphérique.

Une caméra logique doit fonctionner de la même manière qu’une caméra 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 fonctionnant sous Android 9, pour chaque combinaison de flux garantie, la caméra logique doit prendre en charge :

  • Remplacement d'un flux logique YUV_420_888 ou 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 pour 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.

  • Utiliser des 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 de trame des flux physique et logique sont les mêmes.

Considérations relatives aux performances et à la puissance

  • 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 des paramètres physiques de la caméra peut ralentir le taux de capture si les caméras sous-jacentes sont placées dans des fréquences d'images différentes.
  • 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 peuvent outrepasser l'optimisation de l'alimentation interne de HAL et entraîner une consommation d'énergie accrue.

Personnalisation

Vous pouvez personnaliser l’implémentation de votre appareil des manières suivantes.

  • La sortie fusionnée du dispositif de caméra logique dépend entièrement de l'implémentation de 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 spécifique de HAL.
  • À partir d'Android 10, HAL peut réduire le nombre de caméras pouvant être directement ouvertes par une application en choisissant de ne pas annoncer tout ou partie des PHYSICAL_ID dans getCameraIdList . L’appel de getPhysicalCameraCharacteristics doit alors renvoyer les caractéristiques de la caméra physique.

Validation

Les appareils logiques multi-caméras doivent passer le CTS de la caméra comme n’importe quelle autre caméra ordinaire. Les cas de tests 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 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 toutes 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 de test qui permet des mouvements répétés et prescrits du téléphone et affirme que les horodatages du gyroscope et du capteur d'image correspondent et que les images 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 profiter pleinement des fonctionnalités activées par le multi-caméra tout en conservant la compatibilité des applications, suivez ces bonnes pratiques lors de la mise en œuvre d'un périphérique multi-camé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 directement ouvertes par les applications, éliminant ainsi le besoin pour les applications d'avoir une logique de sélection de caméra complexe.
  • (Android 11 ou version ultérieure) Pour un appareil logique multi-caméras 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 de faire un zoom arrière et de maintenir 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 , ANDROID_STATISTICS_FACE_LANDMARKS pour traiter le champ post-ZOOM de Sensor ACTIVE. Pour plus d'informations sur la façon dont ANDROID_SCALER_CROP_REGION fonctionne avec ANDROID_CONTROL_ZOOM_RATIO , consultez camera3_crop_reprocess#cropping .
  • Pour les appareils multi-caméras dotés de caméras physiques dotées de 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 l'ensemble de 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 grand-angle et d'un téléobjectif, procédez comme suit :
    • Si les tailles de réseau actif des caméras physiques sont différentes, le HAL de caméra doit effectuer le mappage des réseaux actifs de caméras physiques vers le réseau actif de 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 pour que depuis l'application Dans cette perspective, le système de coordonnées correspond à la taille du réseau 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 a une 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 à états 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 ait une mise au point fixe soit transparent pour l'application, et les machines à états de mise au point automatique pour les modes AF pris en charge. fonctionne comme prévu.
    • Si les caméras grand angle et téléobjectif prennent en charge le 4K à 60 ips et que la caméra ultra-large ne prend en charge que le 4K à 30 ips ou 1080p à 60 ips, mais pas le 4K à 60 ips, assurez-vous que la caméra 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 ips avec 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 incluant des flux physiques. Si le HAL prend en charge une combinaison avec des flux physiques :
    • (Android 11 ou version ultérieure) Pour mieux gérer les cas d'utilisation tels que la profondeur de la stéréo et le suivi de mouvement, rendez le champ de vision des sorties de flux physiques aussi large que possible par le matériel. Toutefois, 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 identique à celui du flux logique.
    • Pour résoudre la pression de la mémoire provoqué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 devrait être inactif pendant un certain temps. de 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 tampon soit utilisée pour sauvegarder deux surfaces orientées vers les applications, réduisant ainsi la consommation de mémoire.