Sous-système HAL

Demandes

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 un contrôle beaucoup plus précis du traitement et des résultats. Plusieurs requêtes peuvent être en cours de traitement à la fois, et l'envoi de requêtes n'est pas bloquant. Les demandes sont toujours traitées dans l'ordre dans lequel elles sont reçues.

Figure 1 : Modèle d'appareil photo

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 vous permettre d'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é multi-appareils.

Le pipeline de l'appareil photo est également compatible avec les déclencheurs que le framework d'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 la caméra

Veuillez noter que certains blocs de traitement d'images présentés dans le diagramme 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 RAW 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 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
Il s'agit d'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, enregistrement, etc.).
4. Créez une ou plusieurs 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ésumé 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. Veuillez consulter platform/hardware/interfaces/camera/ pour obtenir les définitions de l'interface HIDL.

Énumérer et ouvrir des caméras, 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 tentera 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 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 à 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. Cet appel 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 celui dans lequel les requêtes ont été envoyées. Plusieurs requêtes peuvent être en cours de traitement à la fois, en fonction de la profondeur du pipeline du périphérique HAL de la caméra.

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

• Le framework peut arrêter d'envoyer de nouvelles requêtes, attendre que les captures existantes soient terminées (tous les tampons remplis, tous les résultats renvoyés), puis appeler 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. Le framework poursuit ensuite la première requête de capture vers le HAL, si au moins un flux de sortie enregistré est conservé. (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é, la HAL n'est plus autorisée à appeler ICameraDeviceCallback. Une fois l'appel close() en cours, le framework ne peut pas appeler d'autres fonctions 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'une fois que notify() est appelé avec une erreur fatale, le framework ne reçoit plus de 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 requis.

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	DÉSACTIVÉ	Aucun
	ACTIVÉ	android.sensor.exposureTime android.sensor.frameDuration android.sensor.sensitivity android.lens.aperture (si pris en charge) android.lens.filterDensity (si pris en charge)
	ON_AUTO_FLASH	Tout est activé, 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	DÉSACTIVÉ	Aucun
	WHITE_BALANCE_*	android.colorCorrection.transform. Ajustements spécifiques à la plate-forme si android.colorCorrection.mode est défini sur FAST ou HIGH_QUALITY.
android.control.afMode	DÉSACTIVÉ	Aucun
	FOCUS_MODE_*	android.lens.focusDistance
android.control.videoStabilization	DÉSACTIVÉ	Aucun
	ACTIVÉ	Peut ajuster android.scaler.cropRegion pour implémenter la stabilisation vidéo
android.control.mode	DÉSACTIVÉ	AE, AWB et 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 "Traitement d'image" de la figure 2 fonctionnent toutes selon un principe similaire. En général, chaque bloc comporte trois modes :

• DÉSACTIVÉ : 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.
• RAPIDE : dans ce mode, le bloc de traitement ne doit pas ralentir la fréquence d'images de sortie par rapport au mode DÉSACTIVÉ, mais doit 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 regroupement/d'omission sur le capteur
• Bande passante de l'interface de l'imageur
• Bande passante des différents blocs de traitement de l'ISP

Étant donné que ces facteurs peuvent varier considérablement entre les différents FAI et capteurs, l'interface HAL de l'appareil photo tente 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.
• Étant donné que toute requête peut utiliser tout ou partie des flux de sortie actuellement configurés, le capteur et l'ISP 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 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.