Sous-système HAL

Cette page décrit le sous-système HAL, y compris les requêtes, le sous-système de caméras, 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 l'appareil photo. Une requête correspond à un ensemble de résultats. Une requête englobe 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 des pixels, 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 le traitement et la sortie des résultats. Plusieurs requêtes peuvent être en cours à la fois, et l'envoi de requêtes n'est pas bloquant. De plus, les demandes 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éras

Le sous-système de caméras inclut les implémentations des composants du pipeline de caméras, tels que l'algorithme 3A et les commandes de traitement. Le HAL de l'appareil photo 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 signal d'image (ISP, ou capteurs de caméras), le modèle de pipeline de caméras est virtuel et ne correspond directement à aucun ISP réel. Toutefois, 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-appareils.

Le pipeline de l'appareil photo est également compatible avec les déclencheurs que le framework de l'application peut lancer pour activer des fonctionnalités telles que l'autofocus. Il renvoie également des notifications au framework d'application pour informer les applications d'événements tels qu'un verrouillage de la mise au point automatique ou des erreurs.

Figure 2. Pipeline de l'appareil photo.

Notez que certains blocs de traitement d'images présentés dans le schéma ci-dessus ne sont pas bien définis dans la version initiale. Le pipeline de caméras repose sur les hypothèses suivantes :

• La sortie Bayer brute n'est pas traitée dans l'ISP.
• Les statistiques sont générées à partir des données brutes des capteurs.
• Les différents blocs de traitement qui convertissent les données brutes des capteurs 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écapitulatif de l'utilisation de l'API

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

1. Écoutez et énumérez les caméras.
2. Ouvrez l'appareil et connectez les écouteurs.
3. Configurez les sorties pour le cas d'utilisation cible (capture d'image fixe ou enregistrement, par exemple).
4. Créez des requêtes pour le cas d'utilisation cible.
5. Capturer/répéter les demandes 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écapitulatif de l'opération HAL

• Les requêtes asynchrones pour les captures proviennent du framework.
• Le périphérique HAL doit traiter les requêtes dans l'ordre. Pour chaque requête, générez 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 de l'HAL de l'appareil photo.

Séquence de démarrage et de fonctionnement attendue

Cette section contient une explication détaillée des étapes à suivre lors de l'utilisation de l'API Camera. Pour les définitions d'interface HIDL, consultez platform/hardware/interfaces/camera/.

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

1. Après l'initialisation, le framework commence à écouter les fournisseurs de caméras présents qui implémentent l'interface ICameraProvider. Si un ou plusieurs fournisseurs de ce type sont présents, le framework tente d'établir une connexion.
2. Le framework énumère les périphériques de caméras 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 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 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 l'ICameraDeviceSession par ICameraDevice::open.
3. Le framework construit et envoie la première requête 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. Cette information est envoyée au HAL avec ICameraDeviceSession::processCaptureRequest. Le HAL doit bloquer le retour de cet appel jusqu'à ce qu'il soit prêt à envoyer la prochaine requête.
4. Le framework continue d'envoyer des requêtes et d'appeler 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 de frame et le code temporel pour le début de l'exposition. Ce rappel de notification n'a pas besoin d'avoir lieu avant le premier appel processCaptureResult pour une requête, mais aucun résultat n'est transmis à 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 soumises. Plusieurs requêtes peuvent être en cours de traitement en même temps, en fonction de la profondeur du pipeline du périphérique HAL de l'appareil photo.

Au bout d'un certain temps, l'une des situations suivantes se produit :

• Le framework cesse 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 à 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 framework poursuit ensuite la première requête de capture vers le HAL, si au moins un flux de sortie enregistré est toujours disponible. (Sinon, ICameraDeviceSession::configureStreams est obligatoire en premier.)
• Le framework peut appeler ICameraDeviceSession::close pour mettre fin à la session de l'appareil photo. Cette méthode peut être appelée à 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 de la HAL. Une fois l'appel close en cours, le framework ne peut appeler aucune autre fonction de périphérique HAL.
• En cas d'erreur ou d'autre événement asynchrone, la 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, la HAL doit agir comme si close avait été appelé sur elle. Toutefois, la HAL doit annuler ou terminer toutes les captures en attente avant d'appeler notify, de sorte qu'après l'appel de notify avec une erreur fatale, le framework ne recevra plus d'autres rappels de l'appareil. Les méthodes autres que close doivent renvoyer -ENODEV ou NULL après que la méthode notify renvoie un message d'erreur fatal.

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 en savoir plus, consultez la page Niveau matériel compatible.

Interaction entre la requête 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 l'appareil photo ignore certains des paramètres de la requête de capture de l'application et utilise les valeurs fournies par les routines de contrôle 3A à la place. Par exemple, lorsque l'exposition automatique est active, les paramètres de temps d'exposition, de durée de frame 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 le frame par les routines 3A doivent être indiqué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. Consultez le fichier platform/system/media/camera/docs/docs.html pour obtenir la définition de ces propriétés.

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 pris en charge) et android.lens.filterDensity (si pris en charge).
	ON_AUTO_FLASH	Tous les avantages de 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	Aucun
	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	L'AE, la balance des blancs et l'AF sont désactivés.
	AUTO	Les paramètres individuels d'AE, de balance des blancs et d'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. 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 devrait sinon produire la meilleure qualité de sortie possible compte tenu de cette restriction. Il est généralement utilisé pour les modes d'aperçu ou d'enregistrement vidéo, ou pour la capture en rafale d'images fixes. Sur certains appareils, cela peut équivaloir au mode OFF (aucun traitement ne peut être effectué sans ralentir la fréquence d'images), et sur d'autres, cela peut équivaloir 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, cette option est utilisée pour capturer des images fixes de haute qualité. Certains blocs incluent une commande manuelle qui peut être sélectionnée à la place de FAST ou HIGH_QUALITY. Par exemple, le bloc de correction des couleurs accepte une matrice de transformation des couleurs, tandis que l'ajustement de la courbe de tonalité accepte 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éras dépend de nombreux facteurs :

• Résolutions demandées pour les flux d'images de sortie
• Disponibilité des modes de binning/désactivation sur le capteur
• Bande passante de l'interface de l'imageur
• Bande passante des différents blocs de traitement de l'ISP

Ces facteurs peuvent varier considérablement entre les différents FAI et capteurs. L'interface HAL de l'appareil photo 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 résolution la plus petite est définie comme étant au moins aussi grande que la taille du flux de sortie la plus grande 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 permettre 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 se comportent comme des flux JPEG.
• Le processeur JPEG peut s'exécuter simultanément au reste du pipeline de la caméra, mais ne peut pas traiter plusieurs captures à la fois.