Sous-système HAL

Cette page décrit le sous-système HAL, y compris les requêtes, le sous-système de caméra, la séquence de démarrage et de fonctionnement, les niveaux matériels et les interactions.

Requêtes

Le framework d'application envoie des requêtes pour les 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, le contrôle manuel du capteur, de l'objectif et du flash, les modes de fonctionnement 3A, le contrôle du traitement RAW vers YUV et la génération de statistiques. Cela permet de mieux contrôler la sortie et le traitement des résultats. Plusieurs requêtes peuvent être en cours en même temps, et l'envoi de requêtes n'est pas bloquant. De plus, les requêtes sont toujours traitées dans l'ordre dans lequel elles sont reçues.

Figure 1. Modèle de caméra.

HAL et sous-système de caméra

Le sous-système de caméra inclut les implémentations des composants du pipeline de caméra , tels que l'algorithme 3A et les commandes de traitement. Le HAL de la caméra fournit des interfaces pour implémenter vos versions de ces composants. Pour maintenir la compatibilité multiplate-forme entre plusieurs fabricants d'appareils et fournisseurs de processeurs de signaux d'image (ISP ou capteur de caméra), le modèle de pipeline de caméra est virtuel et ne correspond pas directement à un ISP 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 d'opération différents sans compromettre la qualité, l'efficacité ni la compatibilité inter-appareil.

Le pipeline de caméra est également compatible avec les déclencheurs que le framework d'application peut lancer pour activer des éléments tels que l'autofocus. Il renvoie également des notifications au framework d'application, informant les applications d'événements tels qu'un verrouillage de l'autofocus ou des erreurs.

Figure 2. Pipeline de caméra.

Notez 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éra repose sur les hypothèses suivantes :

• La sortie RAW Bayer ne subit aucun traitement dans l'ISP.
• Les statistiques sont générées à partir 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 de mise à l'é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). Toutefois, chaque unité peut avoir une résolution de sortie et un format de pixel différents.

Résumé de l'utilisation de l'API

Voici un bref résumé des étapes à suivre pour utiliser l'API de caméra Android. Pour obtenir une description détaillée de ces étapes, y compris les appels d'API, consultez la section Séquence de démarrage et de fonctionnement attendue.

1. Écoutez et énumérez les appareils photo.
2. Ouvrez l'appareil et connectez les écouteurs.
3. Configurez les sorties pour le cas d'utilisation cible (par exemple, la capture ou l'enregistrement d'images fixes).
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 de résultat et les données d'image.
7. Lorsque vous changez de cas d'utilisation, revenez à l'étape 3.

Résumé du fonctionnement du HAL

• Les requêtes asynchrones pour les captures proviennent du framework.
• L'appareil HAL doit traiter les requêtes dans l'ordre. Pour chaque requête, il doit produire des métadonnées de résultat de sortie et un ou plusieurs tampons d'image de sortie.
• Premier arrivé, premier servi pour les requêtes et les résultats, ainsi que pour les flux référencés par les requêtes suivantes.
• Les codes temporels doivent être identiques pour toutes les sorties d'une requête donnée, afin que le framework puisse les faire correspondre si nécessaire.
• Toutes les configurations et tous les états de capture (à l'exception des routines 3A) sont encapsulés dans les requêtes et les résultats.

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

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 caméra. Pour les définitions d'interface HIDL, consultez platform/hardware/interfaces/camera/.

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

1. Après l'initialisation, le framework commence à écouter tous les fournisseurs de caméras présents qui implémentent l' ICameraProvider interface. Si un ou plusieurs fournisseurs sont présents, le framework tente 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 l'appareil HAL.
2. Le framework demande les 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 requête de capture au HAL avec 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. Il est envoyé à la HAL avec ICameraDeviceSession::processCaptureRequest. Le HAL doit bloquer le retour de cet appel jusqu'à ce qu'il soit prêt à recevoir la requête suivante.
4. Le framework continue d'envoyer 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 requête commence (le capteur commence à s'exposer pour la capture), le HAL appelle ICameraDeviceCallback::notify avec le message SHUTTER, y compris le numéro d'image et le code temporel pour le début de l'exposition. Ce rappel de notification n'a pas besoin de se produire avant le premier processCaptureResult appel pour une requête, mais aucun résultat n'est envoyé à une application pour une capture tant que notify n'est pas appelé pour cette capture.
6. Après un certain délai de pipeline, le HAL commence à renvoyer les captures terminées au framework avec ICameraDeviceCallback::processCaptureResult. Elles sont renvoyées dans le même ordre que les requêtes ont été envoyées. Plusieurs requêtes peuvent être en cours en même temps, en fonction de la profondeur du pipeline de l' appareil HAL de la caméra.

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

• Le framework arrête d'envoyer de nouvelles requêtes, attend que les captures existantes soient terminées (tous les tampons remplis, tous les résultats renvoyés), puis appelle ICameraDeviceSession::configureStreams à nouveau. 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 configuration. Le framework continue ensuite à partir de la première requête 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 être bloqué jusqu'à ce que toutes les captures en cours soient terminées (tous les résultats renvoyés, tous les tampons remplis). Une fois l'appel close renvoyé, aucun autre appel à ICameraDeviceCallback n'est autorisé à partir du HAL. Une fois l'appel close en cours, le framework ne peut pas appeler d'autres fonctions d'appareil HAL.
• En cas d'erreur ou d'autre événement asynchrone, le HAL doit appeler ICameraDeviceCallback::notify avec le message d'erreur/d'événement approprié. Après être revenu d'une notification d'erreur fatale à l'échelle de l'appareil, le HAL doit agir comme si close avait été appelé. Toutefois, le HAL doit annuler ou terminer toutes les captures en cours avant d'appeler notify, de sorte qu'après notify est appelé avec une erreur fatale, le framework ne reçoive plus de rappels de l'appareil. Les méthodes autres que close doivent renvoyer -ENODEV ou NULL après que la méthode notify a renvoyé un message d'erreur fatale.

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

Niveaux matériels

Les appareils photo peuvent implémenter plusieurs niveaux matériels en fonction de leurs capacités. Pour en savoir plus, consultez supported hardware level.

Interaction entre la requête de capture de l'application, la commande 3A et le pipeline de traitement

En fonction des paramètres du bloc de commande 3A, le pipeline de caméra ignore certains paramètres de la requête de capture de l'application et utilise à la place les valeurs fournies par les routines de commande 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 3A de la plate-forme, et toutes les valeurs spécifiées par l'application sont ignorées. Les valeurs choisies pour l'image par les routines 3A doivent être signalées dans les métadonnées de sortie. Le tableau suivant décrit les différents modes du bloc de commande 3A et les propriétés contrôlées par ces modes. Pour obtenir les définitions de ces propriétés, consultez le fichier platform/system/media/camera/docs/docs.html.

Paramètre	État	Propriétés contrôlées
android.control.aeMode	OFF	Aucune.
	ON	android.sensor.exposureTime, android.sensor.frameDuration, android.sensor.sensitivity, android.lens.aperture (si compatible) et android.lens.filterDensity (si compatible).
	ON_AUTO_FLASH	Tout est ON, plus android.flash.firingPower, android.flash.firingTime, et android.flash.mode.
	ON_ALWAYS_FLASH	Identique à ON_AUTO_FLASH.
	ON_AUTO_FLASH_RED_EYE	Identique à ON_AUTO_FLASH.
android.control.awbMode	OFF	Aucune.
	WHITE_BALANCE_*	android.colorCorrection.transform. Ajustements spécifiques à la plate-forme si android.colorCorrection.mode est FAST ou HIGH_QUALITY.
android.control.afMode	OFF	Aucune
	FOCUS_MODE_*	android.lens.focusDistance
android.control.videoStabilization	OFF	Aucune.
	ON	Peut ajuster android.scaler.cropRegion pour implémenter la stabilisation vidéo.
android.control.mode	OFF	AE, AWB et AF sont désactivés.
	AUTO	Les paramètres individuels AE, AWB et AF sont utilisés.
	SCENE_MODE_*	Peut remplacer tous les paramètres listés ci-dessus. Les commandes 3A individuelles sont désactivées.

Les commandes du bloc de traitement d'image de la figure 2 fonctionnent toutes selon un principe similaire, et chaque bloc comporte trois modes :

• OFF : ce bloc de traitement est désactivé. Les blocs de dématriçage, de correction des couleurs et d'ajustement de la courbe de tonalité ne peuvent pas être désactivés.
• FAST : dans ce mode, le bloc de traitement peut ne pas ralentir la fréquence d'images de sortie par rapport au mode OFF, mais doit sinon produire la meilleure qualité de sortie possible compte tenu de cette restriction. En règle générale, ce mode est utilisé pour les aperçu 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 pas la fréquence d'images).
• HIGH_QUALITY : dans ce mode, le bloc de traitement doit produire le meilleur résultat possible, en ralentissant la fréquence d'images de sortie si nécessaire. En règle générale, ce mode est utilisé pour la capture d'images fixes de haute qualité. Certains blocs incluent une commande manuelle qui peut être sélectionnée en option au lieu de FAST ou HIGH_QUALITY. Par exemple, le bloc de correction des couleurs est compatible avec une matrice de transformation des couleurs, tandis que l'ajustement de la courbe de tonalité est compatible avec une courbe de mappage de tonalité globale arbitraire.

La fréquence d'images maximale pouvant être acceptée 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 binning/saut sur l'imageur
• Bande passante de l'interface de l'imageur
• Bande passante des différents blocs de traitement ISP

Ces facteurs peuvent varier considérablement entre différents ISP et capteurs. L'interface HAL de la caméra tente donc d'abstraire 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 générer la plus petite résolution possible en fonction 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.
• Toute requête peut utiliser tout ou partie des flux de sortie actuellement configurés, Le capteur et l'ISP doivent donc ê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 se comportent 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 s'exécuter simultanément au reste du pipeline de caméra, mais ne peut traiter qu'une seule capture à la fois.