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

Sous-système HAL

Demandes

Le framework de l'application envoie des requêtes de résultats enregistrés au sous-système de l'appareil photo. Une requête correspond à un ensemble de résultats. Une requête encapsule tout des 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 ; capteur manuel, objectif, et le contrôle du flash. Modes de fonctionnement 3A Contrôle du traitement du format RAW vers YUV et la génération de statistiques. Vous pouvez ainsi mieux contrôler les résultats en sortie et en traitement. Plusieurs requêtes peuvent être en cours de transfert à la fois l'envoi de demandes n'est pas bloquant. Les requêtes sont toujours traitées 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 de la caméra. tel que l'algorithme 3A et les contrôles de traitement. HAL de la caméra fournit des interfaces pour vous permettre de mettre en œuvre vos versions de ces composants. À assurer la compatibilité multiplate-forme entre les différents fabricants d’appareils et fournisseurs de processeurs de signal d'image (FAI ou capteur d'appareil photo), le pipeline de l'appareil photo est virtuel et ne correspond pas directement à un vrai FAI. Cependant, il est suffisamment semblable aux vrais pipelines de traitement pour que vous puissiez la mapper le matériel de manière efficace. De plus, il est suffisamment abstrait pour permettre différents algorithmes et ordres d'opération, sans compromettre la qualité, l'efficacité ou la compatibilité multi-appareil.

Le pipeline de caméra est également compatible avec les déclencheurs que le framework de l'application peut lancer pour activer des éléments tels que l'autofocus. Il renvoie également des notifications framework d'application, qui signale aux applications des événements tels que le verrouillage de la mise au point automatique ou des erreurs.

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

Figure 2. Pipeline de caméra

Veuillez noter que certains blocs de traitement d'image illustrés dans le schéma ci-dessus ne sont pas bien défini dans la version initiale. Le pipeline de caméra permet d'obtenir hypothèses:

La sortie RAW de Bayer n'est soumise à aucun traitement au sein du FAI.
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 un ordre arbitraire.
Même si plusieurs unités de mise à l'échelle et de recadrage sont affichées, toutes les unités d'échelle partagent le même commandes de zone de sortie (zoom numérique). Cependant, chaque bloc peut être associé la résolution de sortie et le format de pixel.

Résumé de l'utilisation de l'API
Voici un bref résumé des étapes d'utilisation de l'API d'appareil photo Android. Consultez le la section sur le démarrage et la séquence des opérations attendue pour une répartition détaillée des y compris les appels d'API.

Écoutez et énumérez les caméras.
Ouvrez l'appareil et connectez les écouteurs.
Configurer des sorties pour le cas d'utilisation cible (comme la capture fixe, l'enregistrement, etc.).
Créez une ou plusieurs requêtes pour le cas d'utilisation cible.
Requêtes de capture/répétition et utilisation intensive
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 de capture asynchrones proviennent du framework.
L'appareil HAL doit traiter les requêtes dans l'ordre. Et pour chaque requête, produisez métadonnées de résultat de sortie et un ou plusieurs tampons d'image de sortie.
"premier entré, premier sorti" pour les demandes et les résultats, et 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, de sorte que le et le framework peuvent les faire correspondre si nécessaire.
L'ensemble de la configuration et de l'état de la capture (à l'exception des routines 3A) est encapsulé dans les requêtes et les résultats.

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

Séquence de démarrage et d'opération attendue

Cette section décrit en détail les étapes à suivre lors de l'utilisation l'API de la caméra. Consultez la page <ph type="x-smartling-placeholder"></ph> platform/hardware/interfaces/camera/ pour l'interface HIDL et définitions.

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

Après l'initialisation, le framework commence à écouter fournisseurs de caméras qui mettent en œuvre ICameraProvider. Si le fournisseur ou sont présents, le framework tente d'établir une connexion.
Le framework énumère les appareils photo via ICameraProvider::getCameraIdList()
Le framework instancie un nouveau ICameraDevice en appelant la méthode ICameraProvider::getCameraDeviceInterface_VX_X()
Le framework appelle ICameraDevice::open() pour créer la session de capture active ICameraDeviceSession.

Utiliser une session caméra 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 appels à ICameraDeviceSession::constructDefaultRequestSettings(). Cela peut se produire à tout moment après que ICameraDeviceSession a été créé par ICameraDevice::open.
Le framework construit et envoie la première requête de capture au HAL avec en fonction de l'un des ensembles de paramètres par défaut, et avec au moins un du flux de sortie enregistré précédemment par le framework. Ce message est envoyé au HAL avec ICameraDeviceSession::processCaptureRequest(). Le HAL doit bloquer le retour de cet appel jusqu'à ce qu'il soit prêt pour le prochain appel soit envoyée.
Le framework continue d'envoyer des requêtes et des appels ICameraDeviceSession::constructDefaultRequestSettings() pour obtenir des 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 capture), le HAL appelle ICameraDeviceCallback::notify() avec Le message SHUTTER, y compris le numéro de trame et le code temporel du début d'exposition. Il n'est pas nécessaire que ce rappel de notification ait lieu avant le premier processCaptureResult() pour une requête, mais aucun résultat n'est envoyé à une application pour une capture notify() pour cette capture est appelé.
Après un certain délai dans le pipeline, le HAL commence à renvoyer les captures terminées le framework avec ICameraDeviceCallback::processCaptureResult(). Ils sont renvoyés dans le même ordre que celui des demandes. Multiples peuvent être en cours de transfert en même temps, en fonction de la profondeur du pipeline appareil HAL de la caméra.

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

Il est possible que le framework cesse d'envoyer de nouvelles requêtes. les captures existantes (toutes les mémoires tampons sont remplies, tous les résultats) ; renvoyé), puis appeler ICameraDeviceSession::configureStreams(). à nouveau. Le matériel et le pipeline de l'appareil photo sont alors réinitialisés pour un nouvel ensemble des flux d'entrée/sortie. Certains flux peuvent être réutilisés configuration. Le framework continue ensuite à partir de la première requête de capture au HAL, si au moins un reste le flux de sortie enregistré. Dans le cas contraire, ICameraDeviceSession::configureStreams() est d'abord obligatoire.)
Le framework peut appeler ICameraDeviceSession::close() pour mettre fin à la session caméra. Cette méthode peut être appelée à tout moment lorsqu'aucun autre appel du framework sont actifs, bien que l'appel puisse être bloqué jusqu'à captures en cours de transfert (tous les résultats renvoyés, tous les tampons) ). Une fois l'appel close() renvoyé, plus aucun appel vers Les autorisations ICameraDeviceCallback sont autorisées à partir du HAL. Une fois que l'appel close() est en cours. Le framework ne peut appeler aucun autre Fonctions de l'appareil HAL.
En cas d'erreur ou de tout autre événement asynchrone, le HAL doit appeler ICameraDeviceCallback::notify() par les identifiants message d'erreur/d'événement. Après une notification d'erreur fatale au niveau de l'appareil, le HAL doit agir comme si close() avait été appelé. Cependant, le HAL doit annuler ou terminez toutes les captures en attente avant d'appeler notify(). afin qu'une fois notify() est appelé avec une erreur fatale, le framework recevoir d'autres rappels de l'appareil. Autres méthodes close() doit renvoyer -ENODEV ou NULL après le renvoi d'une erreur fatale par la méthode notify() s'affiche.

Figure 4. Flux de fonctionnement de la caméra

Niveaux de matériel

Les caméras peuvent implémenter plusieurs niveaux de matériel en fonction de leur des fonctionnalités. Pour en savoir plus, consultez <ph type="x-smartling-placeholder"></ph> matériel compatible.

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

Selon les paramètres du bloc de contrôle 3A, le pipeline de caméra ignore certains paramètres de la demande 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 la durée d'exposition, la durée d'affichage et les paramètres de sensibilité de la sont contrôlés par l'algorithme de la plate-forme 3A, et toutes les valeurs spécifiées par l'application sont ignorés. Les valeurs choisies pour la trame par les routines 3A doivent être indiquées dans les métadonnées de sortie. Le tableau suivant décrit les différents modes Bloc de contrôle 3A et les propriétés contrôlées par ces modes. Voir le <ph type="x-smartling-placeholder"></ph> 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 compatible) android.lens.filterDensity (si compatible)
	ACTIVÉ_AUTO_FLASH	Tout est activé, plus android.flash.firingPower, android.flash.firingTime et android.flash.mode
	ALLUMAGE_ALWAYS_FLASH	Identique à ON_AUTO_FLASH
	ACTIVÉ_AUTO_FLASH_RED_EYE	Identique à ON_AUTO_FLASH
android.control.awbMode.	OFF	Aucune
	Solde_blanc*	android.colorCorrection.transform. Ajustements spécifiques à la plate-forme si android.colorCorrection.mode est FAST ou HIGH_QUALITY.
android.control.afMode.	OFF	Aucune
	MODE_FOCUS_*	android.lens.focusDistance
android.control.videoStabilization.	OFF	Aucune
	ON	Possibilité d'ajuster android.scaler.cropRegion pour implémenter la stabilisation vidéo
android.control.mode.	OFF	AE, AWB et AF sont désactivés
	AUTO	Des paramètres individuels d'AE, AWB et AF sont utilisés
	MODE_SCÈNE_*	Peut remplacer tous les paramètres listés ci-dessus. Les commandes 3A individuelles sont désactivées.

Les commandes du bloc "Image Processing" (Traitement de l'image) de la figure 2 fonctionnent toutes sur un principe similaire, et généralement, chaque bloc possède trois modes:

DÉSACTIVÉ: ce bloc de traitement est désactivé. Les fonctions de démonstration, de correction des couleurs Les blocs d'ajustement de la courbe de tonalité ne peuvent pas être désactivés.
RAPIDE: dans ce mode, le bloc de traitement ne ralentit pas nécessairement la trame de sortie. par rapport au mode Éteint, mais dans le cas contraire, la qualité la sortie, elle peut être donnée à cette restriction. Généralement, cela est utilisé pour d'aperçu, d'enregistrement vidéo ou de capture rafale pour les images fixes. Certains cela peut équivaloir au mode Éteint (aucun traitement ne peut être effectué sans un ralentissement de la fréquence d'images). Sur certains appareils, cela peut être équivalent à Mode HIGH_QUALITY (la meilleure qualité ne ralentit pas la fréquence d'images).
HIGH_QUALITY: dans ce mode, le bloc de traitement devrait produire possible, ce qui ralentit la fréquence d'images de sortie si nécessaire. En général, il est utilisé pour des images fixes de haute qualité. Quelques 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 accepte une couleur la matrice de transformation, tandis que l'ajustement de la courbe de tonalité prend en charge une la courbe de mappage des tons.

La fréquence d'images maximale acceptée par un sous-système d'appareil photo est une fonction de nombreux facteurs:

Résolutions demandées des flux d'images de sortie
Disponibilité des modes de binning et de saut d'éléments sur l'imager
La bande passante de l'interface de l'imager
La bande passante des différents blocs de traitement du FAI

Ces facteurs pouvant varier considérablement selon les FAI et les capteurs, L'interface HAL de la caméra tente d'éliminer les restrictions de bande passante que possible. Le modèle présenté présente les caractéristiques suivantes:

Le capteur d'image est toujours configuré pour émettre la plus petite résolution compte tenu des tailles de flux de sortie demandées par l'application. Le plus petit la résolution est définie comme étant au moins égale à la plus grande demande la taille du flux de sortie.
É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 permettre la mise à l'échelle tous les flux en même temps.
Les flux JPEG agissent comme des flux YUV traités pour les requêtes pour lesquelles ils non incluses ; dans les demandes où elles sont directement référencées, elles servent de Flux JPEG.
Le processeur JPEG peut s'exécuter simultanément avec le reste du pipeline de l'appareil photo, ne peut pas traiter plus d'une capture à la fois.