Cette page a été traduite par l'API Cloud Translation.

Sous-système HAL

Demandes

Le framework d'application envoie des requêtes de résultats capturés au sous-système de l'appareil photo. Une requête correspond à un ensemble de résultats. Une requête encapsule toutes les informations de configuration sur la capture et le traitement de ces résultats. Cela inclut, par exemple, 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 un contrôle beaucoup plus précis de la sortie et du traitement 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 requêtes 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 la caméra

Le sous-système de l'appareil photo comprend les implémentations des composants du pipeline de l'appareil photo, 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 assurer la compatibilité multiplate-forme entre plusieurs fabricants d'appareils et fournisseurs de processeurs d'image (ISP, ou capteur d'appareil photo), le modèle de pipeline de l'appareil photo est virtuel et ne correspond pas directement à un ISP réel. Toutefois, il est suffisamment semblable aux pipelines de traitement réels pour que vous puissiez le mapper efficacement sur 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é entre les appareils.

Le pipeline de l'appareil photo prend également en charge 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, en informant les applications d'événements tels qu'un verrouillage du mode autofocus ou des erreurs.

Couche d'abstraction matérielle de la caméra

Figure 2. Pipeline de la 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 la 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 des capteurs.
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, la résolution de sortie et le format de pixel peuvent varier d'une unité à l'autre.

Récapitulatif de l'utilisation de l'API
Voici un bref récapitulatif des étapes à suivre pour utiliser l'API de l'appareil photo Android. Consultez la section "Démarrage et séquence d'opérations attendues" pour obtenir une analyse détaillée de ces étapes, y compris des appels d'API.

Écoutez et énumérez les appareils photo.
Ouvrez l'appareil et connectez les écouteurs.
Configurez les sorties pour le cas d'utilisation cible (capture d'image, enregistrement, etc.).
Créez une ou plusieurs requêtes pour le cas d'utilisation cible.
Capturez/Répétez les requêtes et les rafales.
Recevoir les métadonnées des résultats et les données d'image
Lorsque vous changez de cas d'utilisation, revenez à l'étape 3.

Résumé de l'opération HAL

Les requêtes asynchrones de capture proviennent du framework.
L'appareil HAL doit traiter les requêtes dans l'ordre. Pour chaque requête, créez 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 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.
Toute la configuration et l'état de la 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 la caméra

Démarrage et séquence de fonctionnement attendue

Cette section contient une explication détaillée des étapes attendues lors de l'utilisation de l'API de l'appareil photo. Pour en savoir plus sur les définitions d'interface HIDL, consultez platform/hardware/interfaces/camera/.

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

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.
Le framework énumère les appareils photo via ICameraProvider::getCameraIdList().
Le framework instancie une nouvelle ICameraDevice en appelant le ICameraProvider::getCameraDeviceInterface_VX_X() correspondant.
Le framework appelle ICameraDevice::open() pour créer une session de capture active ICameraDeviceSession.

Utiliser une session d'appareil photo active

Le framework appelle ICameraDeviceSession::configureStreams() avec une liste de flux d'entrée/sortie vers l'appareil HAL.
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.
Le framework crée 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 enregistré précédemment par le framework. Il est envoyé au HAL avec ICameraDeviceSession::processCaptureRequest(). Le HAL doit bloquer le retour de cet appel jusqu'à ce qu'il soit prêt à envoyer la requête suivante.
Le framework continue d'envoyer des requêtes et d'appeler ICameraDeviceSession::constructDefaultRequestSettings() pour obtenir les tampons de paramètres par défaut pour d'autres cas d'utilisation, si nécessaire.
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 de début de l'exposition. Ce rappel de notification ne doit pas se produire avant le premier appel processCaptureResult() pour une requête, mais aucun résultat n'est envoyé à une application pour une capture avant l'appel de notify() pour cette capture.
Après un certain temps de latence du pipeline, le HAL commence à renvoyer les captures terminées au framework avec ICameraDeviceCallback::processCaptureResult(). Elles sont renvoyées dans l'ordre 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 de l'appareil HAL de la caméra.

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

Le framework peut arrêter d'envoyer 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. Certaines diffusions peuvent être réutilisées à partir de la configuration précédente. Le framework continue ensuite à partir de la première requête de capture vers le HAL, si au moins un flux de sortie enregistré reste. (Sinon, ICameraDeviceSession::configureStreams() est obligatoire en premier.)
Le framework peut appeler ICameraDeviceSession::close() pour mettre fin à la session d'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 se bloquer 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() lancé, le framework ne peut pas appeler d'autres fonctions de l'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 avoir renvoyé une notification d'erreur fatale à l'échelle de l'appareil, le HAL doit se comporter comme si close() avait été appelé. Toutefois, le HAL doit annuler ou terminer toutes les captures en attente avant d'appeler notify(). Ainsi, 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() à partir d'un message d'erreur fatal.

Figure 4. Flux de fonctionnement de la caméra

Niveaux matériels

Les appareils photo peuvent implémenter plusieurs niveaux matériels en fonction de leurs fonctionnalités. Pour en savoir plus, consultez la section 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 à 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 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. Pour connaître la définition 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	DÉSACTIVÉ	Aucune
	ACTIVÉ	android.sensor.exposureTime android.sensor.frameDuration android.sensor.sensitivity android.lens.aperture (si compatible) android.lens.filterDensity (si compatible)
	ON_AUTO_FLASH	Tout est activé, y compris 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É	Aucune
	WHITE_BALANCE_*	android.colorCorrection.transform. Ajustements spécifiques à la plate-forme si android.colorCorrection.mode est "FAST" ou "HIGH_QUALITY".
android.control.afMode	DÉSACTIVÉ	Aucune
	FOCUS_MODE_*	android.lens.focusDistance
android.control.videoStabilization	DÉSACTIVÉ	Aucune
	ACTIVÉ	Vous pouvez 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 AE, AWB et AF individuels sont utilisés
	SCENE_MODE_*	Peut remplacer tous les paramètres listés ci-dessus. Les commandes individuelles de l'alimentation 3A sont désactivées.

Les commandes du bloc de 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émosaïcisation, de correction des couleurs et d'ajustement de la courbe de tons ne peuvent pas être désactivés.
RAPIDE: 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 produire la meilleure qualité de sortie possible compte tenu de cette restriction. Il s'agit généralement des modes d'aperçu ou d'enregistrement vidéo, ou de la capture en rafale pour les 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 meilleur résultat de 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 la capture d'images fixes de haute qualité. Certains blocs incluent un contrôle manuel qui peut être sélectionné à la place 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 des tons 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 pour les flux d'images de sortie
Disponibilité des modes de binning/saut sur l'imageur
Bande passante de l'interface de l'imageur
La bande passante des différents blocs de traitement de l'ISP

Étant donné que ces facteurs peuvent varier considérablement d'un FAI et d'un capteur à l'autre, l'interface HAL de l'appareil photo tente d'extraire 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 résolution la plus faible possible compte tenu 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 plus grande taille de flux de sortie demandée.
Étant donné que toute requête peut utiliser tous les 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 en même temps que le reste du pipeline de la caméra, mais il ne peut pas traiter plus d'une capture à la fois.