Sous-système HAL

Demandes

La structure de l'application envoie des demandes de résultats capturés au sous-système de caméra. Une requête correspond à un ensemble de résultats. Une requête encapsule toutes les informations de configuration concernant la capture et le traitement de ces résultats. Cela inclut des éléments tels que la résolution et le format de pixel ; contrôle manuel du capteur, de l'objectif et du flash ; Modes de fonctionnement 3A ; Contrôle du traitement RAW à YUV ; et génération de statistiques. Cela permet un contrôle beaucoup plus important sur la sortie et le traitement des résultats. Plusieurs demandes peuvent être en cours en même temps et la soumission des demandes n’est pas bloquante. Et les demandes sont toujours traitées dans l’ordre de leur réception.

Figure 1. Modèle de caméra

Le sous-système HAL et caméra

Le sous-système de caméra comprend les implémentations des composants du pipeline de caméra tels que l'algorithme 3A et les contrôles de traitement. La caméra HAL fournit des interfaces vous permettant d'implémenter vos versions de ces composants. Pour maintenir la compatibilité multiplateforme entre plusieurs fabricants d'appareils et fournisseurs de processeurs de signal d'image (FAI ou capteur de caméra), le modèle de pipeline de caméra est virtuel et ne correspond directement à aucun FAI réel. Cependant, il est suffisamment similaire aux pipelines de traitement réels pour que vous puissiez le mapper efficacement à votre matériel. De plus, il est suffisamment abstrait pour permettre plusieurs algorithmes et ordres de fonctionnement différents sans compromettre la qualité, l'efficacité ou la compatibilité entre appareils.

Le pipeline de caméra prend également en charge les déclencheurs que le framework d'application peut lancer pour activer des éléments tels que la mise au point automatique. Il renvoie également des notifications au framework d'applications, informant les applications d'événements tels qu'un verrouillage de la mise au point automatique ou des erreurs.

Figure 2. Pipeline de caméra

Veuillez noter que certains blocs de traitement d'image présentés dans le diagramme ci-dessus ne sont pas bien définis dans la version initiale. Le pipeline de caméras fait les hypothèses suivantes :

• La sortie RAW Bayer ne subit aucun traitement au sein du FAI.
• Des statistiques sont générées sur la base des données brutes du capteur.
• Les différents blocs de traitement qui convertissent les données brutes du capteur en YUV sont dans un ordre arbitraire.
• Bien que plusieurs unités d'échelle et de recadrage soient affichées, toutes les unités de mise à l'échelle partagent les commandes de la région de sortie (zoom numérique). Cependant, chaque unité peut avoir une résolution de sortie et un format de pixel différents.

Résumé de l'utilisation de l'API
Ceci est un bref résumé des étapes d'utilisation de l'API de la caméra Android. Consultez la section Démarrage et séquence d’opérations attendue pour une description détaillée de ces étapes, y compris les appels d’API.

1. Écoutez et énumérez les appareils photo.
2. Ouvrez l'appareil et connectez les auditeurs.
3. Configurez les sorties pour le cas d'utilisation cible (comme la capture d'images fixes, l'enregistrement, etc.).
4. Créez des requêtes pour le cas d'utilisation cible.
5. Capturez/répétez les requêtes et les rafales.
6. Recevez les métadonnées des résultats et les données d’image.
7. Lorsque vous changez de cas d’utilisation, revenez à l’étape 3.

Résumé de l'opération HAL

• Les demandes asynchrones de captures proviennent du framework.
• L'appareil HAL doit traiter les demandes dans l'ordre. Et pour chaque requête, produisez des métadonnées de résultat de sortie et un ou plusieurs tampons d’image de sortie.
• Premier entré, premier sorti pour les requêtes et les résultats, ainsi que pour les flux référencés par les requêtes ultérieures.
• Les horodatages doivent être identiques pour toutes les sorties d'une requête donnée, afin que le framework puisse les faire correspondre si nécessaire.
• Toute la configuration et l'état de capture (à l'exception des routines 3A) sont encapsulés dans les requêtes et les résultats.

Figure 3. Présentation de la caméra HAL

Séquence de démarrage et de fonctionnement attendue

Cette section contient une explication détaillée des étapes attendues lors de l'utilisation de l'API de la caméra. Veuillez consulter platform/hardware/interfaces/camera/ pour les définitions des interfaces HIDL.

Énumérer, ouvrir les appareils photo et créer une session active

1. Après l'initialisation, le framework commence à écouter tous les fournisseurs de caméras actuels qui implémentent l'interface ICameraProvider . Si ce ou ces fournisseurs sont présents, le framework tentera d'établir une connexion.
2. Le framework énumère les appareils photo via ICameraProvider::getCameraIdList() .
3. Le framework instancie un nouveau ICameraDevice en appelant le ICameraProvider::getCameraDeviceInterface_VX_X() respectif.
4. Le framework appelle ICameraDevice::open() pour créer une nouvelle session de capture active ICameraDeviceSession.

Utiliser une session de caméra active

1. Le framework appelle ICameraDeviceSession::configureStreams() avec une liste de flux d'entrée/sortie vers le périphérique HAL.
2. Le framework demande des paramètres par défaut pour certains cas d'utilisation avec des appels à ICameraDeviceSession::constructDefaultRequestSettings() . Cela peut se produire à tout moment après la création de ICameraDeviceSession par ICameraDevice::open .
3. Le framework construit et envoie la première demande de capture au HAL avec des paramètres basés sur l'un des ensembles de paramètres par défaut, et avec au moins un flux de sortie qui a été enregistré précédemment par le framework. Ceci est envoyé au HAL avec ICameraDeviceSession::processCaptureRequest() . Le HAL doit bloquer le retour de cet appel jusqu'à ce qu'il soit prêt pour l'envoi de la prochaine requête.
4. Le framework continue de soumettre des requêtes et appelle ICameraDeviceSession::constructDefaultRequestSettings() pour obtenir des tampons de paramètres par défaut pour d'autres cas d'utilisation, si nécessaire.
5. Lorsque la capture d'une demande commence (le capteur commence à exposer pour la capture), le HAL appelle ICameraDeviceCallback::notify() avec le message SHUTTER, comprenant le numéro d'image et l'horodatage du début de l'exposition. Ce rappel de notification ne doit pas nécessairement se produire avant le premier appel processCaptureResult() pour une requête, mais aucun résultat n'est transmis à une application pour une capture avant l'appel notify() pour cette capture.
6. Après un certain délai de pipeline, HAL commence à renvoyer les captures terminées au framework avec ICameraDeviceCallback::processCaptureResult() . Celles-ci sont renvoyées dans le même ordre que celui dans lequel les demandes ont été soumises. Plusieurs requêtes peuvent être en cours en même temps, en fonction de la profondeur du pipeline du dispositif HAL de la caméra.

Après un certain temps, l'un des événements suivants se produira :

• Le framework peut cesser de soumettre de nouvelles requêtes, attendre la fin des captures existantes (tous les tampons remplis, tous les résultats renvoyés), puis appeler à nouveau ICameraDeviceSession::configureStreams() . Cela réinitialise le matériel et le pipeline de la caméra pour un nouvel ensemble de flux d'entrée/sortie. Certains flux peuvent être réutilisés à partir de la configuration précédente. Le cadre continue ensuite à partir de la première demande de capture vers le HAL, s'il reste au moins un flux de sortie enregistré. (Sinon, ICameraDeviceSession::configureStreams() est requis en premier.)
• Le framework peut appeler ICameraDeviceSession::close() pour mettre fin à la session de caméra. Cela peut être appelé à tout moment lorsqu'aucun autre appel du framework n'est actif, bien que l'appel puisse se bloquer jusqu'à ce que toutes les captures en vol soient terminées (tous les résultats renvoyés, tous les tampons remplis). Après le retour de l'appel close() , plus aucun appel à ICameraDeviceCallback n'est autorisé à partir du HAL. Une fois l’appel close() en cours, le framework ne peut appeler aucune autre fonction du périphérique HAL.
• En cas d'erreur ou d'un autre événement asynchrone, le HAL doit appeler ICameraDeviceCallback::notify() avec le message d'erreur/événement approprié. Après le retour d'une notification d'erreur fatale à l'échelle du périphérique, le HAL doit agir comme si close() avait été appelé dessus. Cependant, le HAL doit annuler ou terminer toutes les captures en attente avant d'appeler notify() , de sorte qu'une fois notify() appelé avec une erreur fatale, le framework ne recevra plus de rappels de l'appareil. Les méthodes autres que close() doivent renvoyer -ENODEV ou NULL après le retour de la méthode notify() après un message d'erreur fatale.

Figure 4. Flux opérationnel de la caméra

Niveaux de matériel

Les caméras peuvent implémenter plusieurs niveaux matériels en fonction de leurs capacités. Pour plus d'informations, consultez le niveau de matériel pris en charge .

Interaction entre la demande de capture d'application, le contrôle 3A et le pipeline de traitement

En fonction des paramètres du bloc de contrôle 3A, le pipeline de la caméra ignore certains paramètres de la demande de capture de l'application et utilise à la place les valeurs fournies par les routines de contrôle 3A. Par exemple, lorsque l'exposition automatique est active, les paramètres de temps d'exposition, de durée d'image et de sensibilité du capteur sont contrôlés par l'algorithme de la plateforme 3A et toutes les valeurs spécifiées par l'application sont ignorées. Les valeurs choisies pour la trame par les routines 3A doivent être rapportées dans les métadonnées de sortie. Le tableau suivant décrit les différents modes du bloc de contrôle 3A et les propriétés contrôlées par ces modes. Voir le fichier platform/system/media/camera/docs/docs.html pour les définitions de ces propriétés.

Les commandes du bloc Traitement d'image de la figure 2 fonctionnent toutes selon un principe similaire, et généralement chaque bloc dispose de trois modes :

• OFF : ce bloc de traitement est désactivé. Les blocs de dématriçage, de correction des couleurs et de réglage de la courbe de tonalité ne peuvent pas être désactivés.
• RAPIDE : dans ce mode, le bloc de traitement ne peut pas ralentir la fréquence d'images de sortie par rapport au mode OFF, mais doit par ailleurs produire la meilleure qualité de sortie possible compte tenu de cette restriction. Généralement, cela serait utilisé pour les modes de prévisualisation ou d'enregistrement vidéo, ou pour la capture en rafale d'images fixes. Sur certains appareils, cela peut être équivalent au mode OFF (aucun traitement ne peut être effectué sans ralentir la fréquence d'images), et sur certains appareils, cela peut être équivalent au mode HIGH_QUALITY (la meilleure qualité ne ralentit toujours pas la fréquence d'images).
• HIGH_QUALITY : dans ce mode, le bloc de traitement doit produire le résultat de la meilleure qualité possible, en ralentissant la fréquence d'images de sortie si nécessaire. En règle générale, cela serait utilisé pour une capture d’images fixes de haute qualité. Certains blocs incluent un contrôle manuel qui peut être éventuellement sélectionné à la place de FAST ou HIGH_QUALITY. Par exemple, le bloc de correction des couleurs prend en charge une matrice de transformation des couleurs, tandis que l'ajustement de la courbe de tonalité prend en charge une courbe de mappage de tonalité globale arbitraire.

La fréquence d'images maximale pouvant être prise en charge par un sous-système de caméra dépend de nombreux facteurs :

• Résolutions demandées des flux d’images de sortie
• Disponibilité des modes de regroupement/saut sur l'imageur
• La bande passante de l'interface de l'imageur
• La bande passante des différents blocs de traitement du FAI

Étant donné que ces facteurs peuvent varier considérablement selon les différents FAI et capteurs, l'interface HAL de la caméra tente de résumer les restrictions de bande passante dans un modèle aussi simple que possible. Le modèle présenté présente les caractéristiques suivantes :

• Le capteur d'image est toujours configuré pour produire la plus petite résolution possible compte tenu des tailles de flux de sortie demandées par l'application. La plus petite résolution est définie comme étant au moins aussi grande que la plus grande taille de flux de sortie demandée.
• Étant donné que toute requête peut utiliser tout ou partie des flux de sortie actuellement configurés, le capteur et le FAI doivent être configurés pour prendre en charge la mise à l'échelle d'une seule capture sur tous les flux en même temps.
• Les flux JPEG agissent comme des flux YUV traités pour les requêtes pour lesquelles ils ne sont pas inclus ; dans les requêtes dans lesquelles ils sont directement référencés, ils agissent comme des flux JPEG.
• Le processeur JPEG peut fonctionner simultanément avec le reste du pipeline de caméras, mais ne peut pas traiter plus d'une capture à la fois.