RequestAvailableCapabilities Énumération
Définition
Important
Certaines informations portent sur la préversion du produit qui est susceptible d’être en grande partie modifiée avant sa publication. Microsoft exclut toute garantie, expresse ou implicite, concernant les informations fournies ici.
Énumère les valeurs retournées par plusieurs méthodes de RequestAvailableCapabilities.
public enum RequestAvailableCapabilitiestype RequestAvailableCapabilities = - Héritage
-
RequestAvailableCapabilities
Champs
| Nom | Valeur | Description |
|---|---|---|
| BackwardCompatible | 0 | Ensemble minimal de fonctionnalités prises en charge par chaque appareil photo (indépendamment d’android.info.supportedHardwareLevel). Cette fonctionnalité est répertoriée par tous les appareils normaux et indique que l’appareil photo a un ensemble de fonctionnalités comparable aux exigences de base pour l’API android.hardware.Camera plus ancienne. Les appareils dotés de la fonctionnalité DEPTH_OUTPUT peuvent ne pas répertorier cette fonctionnalité, ce qui indique qu’ils prennent en charge uniquement la mesure de profondeur, et non la sortie de couleur standard. Les parties de cette page sont des modifications basées sur le travail créé et partagé par Android Open Source et utilisées en fonction des termes décrits dans la Creative Commons 2.5 Attribution License. |
| ManualSensor | 1 | L’appareil photo peut être contrôlé manuellement (algorithmes 3A tels que l’exposition automatique, et le focus automatique peut être contourné). L’appareil photo prend en charge le contrôle manuel de base des étapes associées à l’acquisition d’images de capteur. Cela signifie que les contrôles suivants sont garantis pour être pris en charge : contrôle de durée de trame manuelle ; android.sensor.frameDuration ; android.sensor.info.maxFrameDuration ; Contrôle d’exposition manuel ; android.sensor.exposureTime ; android.sensor.info.exposureTimeRange ; Contrôle de sensibilité manuel ; android.sensor.sensitivity ; android.sensor.info.sensitivityRange ; Contrôle manuel des lentilles (si l’objectif est réglable) ; android.lens.* ; Contrôle flash manuel (si une unité flash est présente) ; android.flash.* ; Verrouillage manuel au niveau noir ; android.blackLevel.lock ; Verrouillage d’exposition automatique ; android.control.aeLock Si l’un des algorithmes 3A ci-dessus est activé, l’appareil photo signale avec précision les valeurs appliquées par 3A dans le résultat. Un appareil photo donné peut également prendre en charge des contrôles de capteur manuels supplémentaires, mais cette fonctionnalité couvre uniquement la liste des contrôles ci-dessus. S’il est pris en charge, android.scaler.streamConfigurationMap retourne également une durée d’image minimale supérieure à zéro pour chaque combinaison de format de taille prise en charge. Pour les appareils photo avec LOGICAL_MULTI_CAMERA capacité, lorsque les commutateurs de caméra physique actifs sous-jacents, exposureTime, sensibilité et les propriétés de lentille peuvent changer même si AE/AF est verrouillé. Toutefois, l’exposition automatique globale et l’expérience de focus automatique pour les utilisateurs seront cohérentes. Pour plus d’informations, reportez-vous à LOGICAL_MULTI_CAMERA fonctionnalité. Les parties de cette page sont des modifications basées sur le travail créé et partagé par Android Open Source et utilisées en fonction des termes décrits dans la Creative Commons 2.5 Attribution License. |
| ManualPostProcessing | 2 | Les étapes de post-traitement de l’appareil photo peuvent être contrôlées manuellement. L’appareil photo prend en charge le contrôle manuel de base des étapes de post-traitement de l’image. Cela signifie que les contrôles suivants sont garantis pour être pris en charge : contrôle tonemap manuel ; android.tonemap.curve ; android.tonemap.mode ; android.tonemap.maxCurvePoints ; android.tonemap.gamma ; android.tonemap.presetCurve ; Contrôle manuel de l’équilibre blanc ; android.colorCorrection.transform ; android.colorCorrection.gains ; Contrôle manuel de la carte d’ombrage des lentilles ; android.shading.mode ; android.statistics.lensShadingMapMode ; android.statistics.lensShadingMap ; android.lens.info.shadingMapSize ; Contrôle de correction d’aberration manuel (si la correction de l’aberration est prise en charge) ; android.colorCorrection.aberrationMode ; android.colorCorrection.availableAberrationModes ; Verrouillage de l’équilibrage automatique des blancs ; android.control.awbLock Si l’équilibrage automatique est activé, l’appareil photo signale avec précision les valeurs appliquées par AWB dans le résultat. Un appareil photo donné peut également prendre en charge des contrôles post-traitement supplémentaires, mais cette fonctionnalité couvre uniquement la liste des contrôles ci-dessus. Pour les appareils photo avec LOGICAL_MULTI_CAMERA capacité, lorsque les commutateurs de caméra physique actifs sous-jacents, le tonmap, l’équilibre blanc et la carte de trame de fond peuvent changer même si awb est verrouillé. Toutefois, l’expérience globale de post-traitement pour les utilisateurs sera cohérente. Pour plus d’informations, reportez-vous à LOGICAL_MULTI_CAMERA fonctionnalité. Les parties de cette page sont des modifications basées sur le travail créé et partagé par Android Open Source et utilisées en fonction des termes décrits dans la Creative Commons 2.5 Attribution License. |
| Raw | 3 | L’appareil photo prend en charge la mise en place de mémoires tampons ET de métadonnées RAW pour les interpréter. Les appareils prenant en charge la fonctionnalité RAW permettent à la fois d’enregistrer des fichiers DNG et de traiter directement les images de capteur brutes. RAW_SENSOR est pris en charge en tant que format de sortie ; La résolution maximale disponible pour RAW_SENSOR flux correspond à la valeur dans android.sensor.info.pixelArraySize ou android.sensor.info.preCorrectionActiveArraySize ; Toutes les entrées de métadonnées facultatives liées à DNG sont fournies par l’appareil photo
Référence Android pour Les parties de cette page sont des modifications basées sur le travail créé et partagé par Android Open Source et utilisées en fonction des termes décrits dans la Creative Commons 2.5 Attribution License. |
| PrivateReprocessing | 4 | L’appareil photo prend en charge le cas d’usage de retraitement du décalage d’obturation zéro. ; Un flux d’entrée est pris en charge, c’est-à-dire android.request.maxNumInputStreams == 1 ; ImageFormat.PRIVATE est pris en charge en tant que format de sortie/entrée, autrement dit, ImageFormat.PRIVATE est inclus dans les listes de formats retournés par StreamConfigurationMap.getInputFormats() et StreamConfigurationMap.getOutputFormats() ; StreamConfigurationMap.getValidOutputFormatsForInput(int) retourne un int non vide[] pour chaque format d’entrée pris en charge retourné par StreamConfigurationMap.getInputFormats() ; Chaque taille retournée par getInputSizes(ImageFormat.PRIVATE) est également incluse dans getOutputSizes(ImageFormat.PRIVATE) ; L’utilisation d’ImageFormat.PRIVATE ne provoque pas de chute de fréquence d’images par rapport au taux de capture maximal du capteur (à cette résolution) ; ImageFormat.PRIVATE sera retraiter dans les formats ImageFormat.YUV_420_888 et ImageFormat.JPEG ; Pour une caméra MONOCHROME prenant en charge le format Y8, ImageFormat.PRIVATE sera reprocessable dans ImageFormat.Y8 ; La résolution maximale disponible pour les flux PRIVÉS (à la fois en entrée/sortie) correspond à la résolution maximale disponible des flux JPEG ; Métadonnées statiques android.reprocess.maxCaptureStall ; Seuls les contrôles ci-dessous sont efficaces pour le retraitement des demandes et seront présents dans les résultats de capture, d’autres contrôles dans les demandes de retraitement seront ignorés par l’appareil photo ; android.jpeg.* ; android.noiseReduction.mode ; android.edge.mode ; android.noiseReduction.availableNoiseReductionModes et android.edge.availableEdgeModes répertorient les deux ZERO_SHUTTER_LAG en mode pris en charge Les parties de cette page sont des modifications basées sur le travail créé et partagé par Android Open Source et utilisées en fonction des termes décrits dans la Creative Commons 2.5 Attribution License. |
| ReadSensorSettings | 5 | L’appareil photo prend en charge la création de rapports précis sur les paramètres du capteur pour la plupart des contrôles de capteur pendant l’exécution de l’algorithme 3A intégré. Cela permet de créer des rapports sur les paramètres de capteur même si ces paramètres ne peuvent pas être modifiés manuellement. Les valeurs signalées pour les contrôles suivants sont garanties d’être disponibles dans CaptureResult, notamment lorsque 3A est activé : Contrôle d’exposition ; android.sensor.exposureTime ; Contrôle de confidentialité ; android.sensor.sensitivity ; Contrôles de lentille (si l’objectif est réglable) ; android.lens.focusDistance ; android.lens.aperture Cette fonctionnalité est un sous-ensemble de la fonctionnalité de contrôle MANUAL_SENSOR et sera toujours incluse si la fonctionnalité MANUAL_SENSOR est disponible. Les parties de cette page sont des modifications basées sur le travail créé et partagé par Android Open Source et utilisées en fonction des termes décrits dans la Creative Commons 2.5 Attribution License. |
| BurstCapture | 6 | L’appareil photo prend en charge la capture d’images haute résolution à = >20 images par seconde, au moins au format YUV non compressé, lorsque les paramètres de post-traitement sont définis sur FAST. En outre, toutes les résolutions d’image inférieures à 24 millisecondes peuvent être capturées à = >10 images par seconde. Ici, « haute résolution » signifie au moins 8 millisecondes, ou la résolution maximale de l’appareil, selon ce qui est plus petit. Plus précisément, cela signifie qu’une taille correspondant à la taille de tableau active de l’appareil photo est répertoriée comme une taille prise en charge pour le format ImageFormat.YUV_420_888 dans StreamConfigurationMap.getOutputSizes(int) ou StreamConfigurationMap.getHighResolutionOutputSizes(int), avec une durée minimale d’image pour ce format et cette taille = <1/20 s, ou <= 1/10 s si la taille de l’image est inférieure à 24 millisecondes, respectivement ; et l’entrée android.control.aeAvailableTargetFpsRanges répertorie au moins une plage FPS où le FPS minimal est >= 1 / minimumFrameDuration pour le format YUV_420_888 de taille maximale. Si cette taille maximale est répertoriée dans StreamConfigurationMap.getHighResolutionOutputSizes(int), la liste des résolutions pour YUV_420_888 de StreamConfigurationMap.getOutputSizes(int) contient au moins une résolution >= 8 millisecondes, avec une durée minimale d’image de <= 1/20 s. Si l’appareil prend en charge ImageFormat.RAW10, ImageFormat.RAW12, ImageFormat.RAW14, ImageFormat.Y8, ceux-ci peuvent également être capturés à la même vitesse que la taille maximale YUV_420_888 résolution. Si l’appareil prend en charge la fonctionnalité de PRIVATE_REPROCESSING, les mêmes garanties que pour le format YUV_420_888 s’appliquent également au format ImageFormat.PRIVATE. En outre, le champ android.sync.maxLatency est garanti pour avoir une valeur comprise entre 0 et 4, inclus. android.control.aeLockAvailable et android.control.awbLockAvailable sont également garantis pour être vrais de sorte que la capture en rafale avec ces deux verrous ON génère une sortie d’image cohérente. Les parties de cette page sont des modifications basées sur le travail créé et partagé par Android Open Source et utilisées en fonction des termes décrits dans la Creative Commons 2.5 Attribution License. |
| YuvReprocessing | 7 | L’appareil photo prend en charge le YUV_420_888 le cas d’usage de retraitement, comme PRIVATE_REPROCESSING, cette fonctionnalité nécessite que l’appareil photo prenne en charge ce qui suit : un flux d’entrée est pris en charge, autrement dit, android.request.maxNumInputStreams == 1 ; ImageFormat.YUV_420_888 est pris en charge en tant que format de sortie/entrée, autrement dit, YUV_420_888 est inclus dans les listes de formats retournés par StreamConfigurationMap.getInputFormats() et StreamConfigurationMap.getOutputFormats() ; StreamConfigurationMap.getValidOutputFormatsForInput(int) retourne un int non vide[] pour chaque format d’entrée pris en charge retourné par StreamConfigurationMap.getInputFormats() ; Chaque taille retournée par getInputSizes(YUV_420_888) est également incluse dans getOutputSizes(YUV_420_888) ; L’utilisation de ImageFormat.YUV_420_888 n’entraîne pas de chute de fréquence d’images par rapport au taux de capture maximal du capteur (à cette résolution) ; ImageFormat.YUV_420_888 sera retraiter dans les formats ImageFormat.YUV_420_888 et ImageFormat.JPEG ; La résolution maximale disponible pour les flux ImageFormat.YUV_420_888 (à la fois en entrée/sortie) correspond à la résolution maximale disponible des flux ImageFormat.JPEG ; Pour une caméra MONOCHROME avec prise en charge du format Y8, toutes les exigences mentionnées ci-dessus pour YUV_420_888 s’appliquent également au format Y8 ; Métadonnées statiques android.reprocess.maxCaptureStall ; Seuls les contrôles ci-dessous sont efficaces pour le retraitement des demandes et seront présents dans les résultats de capture. Les demandes de retraitement proviennent des résultats de capture d’origine associés aux mémoires tampons de sortie intermédiaires ImageFormat.YUV_420_888. Tous les autres contrôles des demandes de retraitement seront ignorés par l’appareil photo ; android.jpeg.* ; android.noiseReduction.mode ; android.edge.mode ; android.reprocess.effectiveExposureFactor ; android.noiseReduction.availableNoiseReductionModes et android.edge.availableEdgeModes répertorient les deux ZERO_SHUTTER_LAG en mode pris en charge Les parties de cette page sont des modifications basées sur le travail créé et partagé par Android Open Source et utilisées en fonction des termes décrits dans la Creative Commons 2.5 Attribution License. |
| DepthOutput | 8 | L’appareil photo peut produire des mesures de profondeur à partir de son champ de vue. Cette fonctionnalité nécessite que l’appareil photo prend en charge les éléments suivants : ImageFormat.DEPTH16 est pris en charge en tant que format de sortie ; ImageFormat.DEPTH_POINT_CLOUD est éventuellement pris en charge en tant que format de sortie ; Cet appareil photo, ainsi que tous les appareils photo avec le même android.lens.facing, répertorient les entrées de métadonnées d’étalonnage suivantes dans CameraCharacteristics et CaptureResult :; android.lens.poseTranslation ; android.lens.poseRotation ; android.lens.intrinsèqueCalibration ; android.lens.distortion ; L’entrée android.depth.depthIsExclusive est répertoriée par cet appareil ; À partir d’Android P, l’entrée android.lens.poseReference est répertoriée par cet appareil ; Une caméra LIMITÉE avec uniquement la fonctionnalité de DEPTH_OUTPUT n’a pas besoin de prendre en charge les sorties normales YUV_420_888, Y8, JPEG et PRIV-format. Il doit uniquement prendre en charge le format DEPTH16 En règle générale, la sortie de profondeur fonctionne à une fréquence d’images plus lente que la capture de couleurs standard, de sorte que les formats DEPTH16 et DEPTH_POINT_CLOUD ont généralement une durée de blocage qui doit être prise en compte (voir StreamConfigurationMap.getOutputStallDuration(int, Size)). Sur un appareil qui prend en charge à la fois la profondeur et la sortie basée sur des couleurs, pour activer l’aperçu fluide, l’utilisation d’un bursting répétitif est recommandée, où une cible de sortie de profondeur n est incluse une seule fois toutes les images N, où N correspond au rapport entre le taux de sortie d’aperçu et le taux de sortie de profondeur, y compris le temps de décrochage de profondeur. Les parties de cette page sont des modifications basées sur le travail créé et partagé par Android Open Source et utilisées en fonction des termes décrits dans la Creative Commons 2.5 Attribution License. |
| ConstrainedHighSpeedVideo | 9 | L’appareil prend en charge le cas d’usage de l’enregistrement vidéo à haute vitesse limité (fréquence >d’images =120fps). L’appareil photo prend en charge la session de capture haute vitesse créée par CameraDevice.createConstrainedHighSpeedCaptureSession(List, StateCallback, Handler), qui accepte uniquement les listes de demandes à grande vitesse créées par CameraConstrainedHighSpeedCaptureSession.createHighSpeedRequestList(CaptureRequest). Un appareil photo peut toujours prendre en charge la diffusion vidéo à grande vitesse en publiant les plages FPS à haute vitesse dans android.control.aeAvailableTargetFpsRanges. Dans ce cas, toutes les demandes de capture normales par contrôle d’image et les exigences de synchronisation s’appliquent aux plages fps à haute vitesse, identiques à toutes les autres plages fps. Cette fonctionnalité décrit la capacité d’un mode d’exploitation spécialisé avec de nombreuses limitations (voir ci-dessous), qui est uniquement destinée à l’enregistrement vidéo à haute vitesse. Les tailles vidéo et les plages fps prises en charge sont spécifiées dans StreamConfigurationMap.getHighSpeedVideoFpsRanges(). Pour obtenir les taux d’images de sortie souhaités, l’application est uniquement autorisée à sélectionner la taille de vidéo et les combinaisons de plages FPS fournies par StreamConfigurationMap.getHighSpeedVideoSizes(). La plage fps peut être contrôlée via android.control.aeTargetFpsRange. Dans cette fonctionnalité, l’appareil photo remplace aeMode, awbMode et afMode sur ON, AUTO et CONTINUOUS_VIDEO, respectivement. Tous les contrôles en mode bloc post-traitement seront remplacés par FAST. Par conséquent, aucun contrôle manuel des paramètres de capture et de post-traitement n’est possible. Tous les autres contrôles fonctionnent de la même façon que lorsque android.control.mode == AUTO. Cela signifie que tous les autres champs android.control.* continuent de fonctionner, tels que ; android.control.aeTargetFpsRange ; android.control.aeExposureCompensation ; android.control.aeLock ; android.control.awbLock ; android.control.effectMode ; android.control.aeRegions ; android.control.afRegions ; android.control.awbRegions ; android.control.afTrigger ; android.control.aePrecaptureTrigger ; android.control.zoomRatio En dehors d’android.control.*, les contrôles suivants fonctionnent : android.flash.mode (mode TORCH uniquement, flash automatique pour la capture continue ne fonctionnera pas, car aeMode est ACTIVÉ) ; android.lens.opticalStabilizationMode (s’il est pris en charge) ; android.scaler.cropRegion ; android.statistics.faceDetectMode (s’il est pris en charge) Pour le cas d’usage de l’enregistrement à haute vitesse, la fréquence d’images maximale prise en charge réelle peut être inférieure à celle de la caméra, en fonction des surfaces de destination pour les données d’image. Par exemple, si l’aire de destination provient de l’encodeur vidéo, l’application a besoin de vérifier si l’encodeur vidéo est capable de prendre en charge la fréquence d’images élevée pour une taille de vidéo donnée, ou elle finira par une fréquence d’images d’enregistrement inférieure. Si l’aire de destination provient de la fenêtre d’aperçu, la fréquence d’images d’aperçu réelle est limitée par le taux d’actualisation de l’écran. L’appareil photo prend uniquement en charge jusqu’à 2 surfaces de sortie simultanées à haute vitesse (préversion et surfaces d’enregistrement) dans ce mode. Les contrôles ci-dessus ne sont effectifs que si toutes les conditions ci-dessous sont remplies : l’application crée une session de capture de caméra sans plus de 2 surfaces via CameraDevice.createConstrainedHighSpeedCaptureSession(List, StateCallback, Handler). Les surfaces ciblées doivent être en préversion (surface SurfaceView ou SurfaceTexture) ou surface d’enregistrement (à partir de MediaRecorder.getSurface() ou MediaCodec.createInputSurface()) ; Les tailles de flux sont sélectionnées parmi les tailles signalées par StreamConfigurationMap.getHighSpeedVideoSizes() ; Les plages FPS sont sélectionnées à partir de StreamConfigurationMap.getHighSpeedVideoFpsRanges() Lorsque les conditions ci-dessus ne sont pas satisfaites, CameraDevice.createConstrainedHighSpeedCaptureSession(List, StateCallback, Handler) échoue. Le passage à une plage FPS qui a un fpS maximal différent peut déclencher des reconfigurations d’appareil photo, ce qui peut introduire une latence supplémentaire. Il est recommandé que l’application évite les modifications FPS cibles inutiles autant que possible pendant la diffusion en continu à grande vitesse. Les parties de cette page sont des modifications basées sur le travail créé et partagé par Android Open Source et utilisées en fonction des termes décrits dans la Creative Commons 2.5 Attribution License. |
| MotionTracking | 10 | L’appareil photo prend en charge la valeur MOTION_TRACKING pour android.control.captureIntent, ce qui limite la durée d’exposition maximale à 20 ms. Cela limite le flou de mouvement des images de capture, ce qui entraîne de meilleurs résultats de suivi des images pour les cas d’usage tels que la stabilisation d’image ou la réalité augmentée. Les parties de cette page sont des modifications basées sur le travail créé et partagé par Android Open Source et utilisées en fonction des termes décrits dans la Creative Commons 2.5 Attribution License. |
| LogicalMultiCamera | 11 | L’appareil photo est une caméra logique soutenue par deux caméras physiques ou plus. Au niveau de l’API 28, les caméras physiques doivent également être exposées à l’application via CameraManager.getCameraIdList(). À partir du niveau 29 de l’API : certaines caméras physiques ou toutes ne peuvent pas être exposées indépendamment à l’application, auquel cas les ID de caméra physique ne seront pas disponibles dans CameraManager.getCameraIdList(). Mais l’application peut toujours interroger les caractéristiques des caméras physiques en appelant CameraManager.getCameraCharacteristics(String) ; Si une caméra physique est masquée dans la liste des ID de l’appareil photo, les combinaisons de flux obligatoires pour cette caméra physique doivent être prises en charge par le biais de la caméra logique à l’aide de flux physiques. Une exception est que dans le niveau 30 de l’API, une caméra physique peut devenir indisponible via CameraManager.AvailabilityCallback.onPhysicalCameraUnavailable callback Les combinaisons de flux logiques et physiques ou de flux physiques provenant de différentes caméras physiques ne sont pas garanties. Toutefois, si l’appareil photo prend en charge CameraDevice.isSessionConfigurationSupported, l’application doit pouvoir interroger si une combinaison de flux impliquant des flux physiques est prise en charge en appelant CameraDevice.isSessionConfigurationSupported. L’application caméra ne doit pas supposer qu’il y a au plus 1 caméra arrière et 1 caméra avant dans le système. Pour une application qui bascule entre les caméras avant et arrière, il est recommandé de basculer entre la première caméra arrière et la première caméra avant dans la liste des appareils photo pris en charge. Cette fonctionnalité nécessite que l’appareil photo prend en charge les éléments suivants : les ID des caméras physiques sous-jacentes sont retournés via CameraCharacteristics.getPhysicalCameraIds() ; Cet appareil photo doit répertorier les métadonnées statiques android.logicalMultiCamera.sensorSyncType dans CameraCharacteristics ; Les métadonnées statiques des caméras physiques sous-jacentes doivent répertorier les entrées suivantes afin que l’application puisse mettre en corrélation des pixels à partir des flux physiques :; android.lens.poseReference ; android.lens.poseRotation ; android.lens.poseTranslation ; android.lens.intrinsèqueCalibration ; android.lens.distortion ; Les SENSOR_INFO_TIMESTAMP_SOURCE de l’appareil logique et des appareils physiques doivent être identiques ; La caméra logique doit être LIMITÉE ou supérieure Les métadonnées dynamiques d’un appareil photo logique peuvent contenir android.logicalMultiCamera.activePhysicalId pour notifier l’application de l’ID actuel de la caméra physique active. Une caméra physique active est la caméra physique à partir de laquelle les données d’image principales de la caméra logique (YUV ou RAW) et les métadonnées proviennent. En outre, cela sert d’indication que la caméra physique est utilisée pour générer un flux RAW, ou dans le cas où seules les caméras physiques prennent en charge RAW, quel flux RAW physique l’application doit demander. Les balises de métadonnées statiques de la caméra logique ci-dessous décrivent la caméra physique active par défaut. Une caméra physique active est par défaut si elle est utilisée lorsque l’application utilise directement les requêtes générées à partir d’un modèle. Tous les modèles sont par défaut la même caméra physique active. android.sensor.info.sensitivityRange ; android.sensor.info.colorFilterArrangement ; android.sensor.info.exposureTimeRange ; android.sensor.info.maxFrameDuration ; android.sensor.info.physicalSize ; android.sensor.info.whiteLevel ; android.sensor.info.lensShadingApplied ; android.sensor.referenceIlluminant1 ; android.sensor.referenceIlluminant2 ; android.sensor.calibrationTransform1 ; android.sensor.calibrationTransform2 ; android.sensor.colorTransform1 ; android.sensor.colorTransform2 ; android.sensor.forwardMatrix1 ; android.sensor.forwardMatrix2 ; android.sensor.blackLevelPattern ; android.sensor.maxAnalogSensitivity ; android.sensor.opticalBlackRegions ; android.sensor.availableTestPatternModes ; android.lens.info.hyperfocalDistance ; android.lens.info.minimumFocusDistance ; android.lens.info.focusDistanceCalibration ; android.lens.poseRotation ; android.lens.poseTranslation ; android.lens.intrinsèqueCalibration ; android.lens.poseReference ; android.lens.distortion Le champ d’affichage des flux physiques non RAW ne doit pas être inférieur à celui des flux logiques non RAW, ou le champ de vue maximal de la caméra physique, selon la taille la plus petite. L’application doit vérifier les métadonnées de résultat de capture physique et les caractéristiques de la caméra physique pour savoir comment les flux physiques sont rognés ou zoomés. Voir android.lens.focalLength sur la façon dont le champ de vue est calculé. En règle générale, le flux physique de la caméra physique active a le même champ de vue que les flux logiques. Toutefois, la même chose peut ne pas être vraie pour les flux physiques provenant de caméras physiques non actives. Par exemple, si la caméra logique a une configuration à grande échelle où l’objectif large est la valeur par défaut, lorsque la région de rognage est définie sur la taille de tableau active de la caméra logique (et que le rapport de zoom est défini sur 1,0 à partir d’Android 11), un flux physique pour la caméra ultra-large peut préférer mettre des images avec un champ de vue plus grand que celui de la caméra large pour une meilleure marge de correspondance stéréo ou un suivi de mouvement plus robuste. En même temps, le champ d’affichage des flux non RAW physiques ne doit pas être inférieur à la zone de rognage demandée et au rapport de zoom, tant qu’il se trouve dans la capacité de l’objectif physique. Par exemple, pour une caméra logique avec une configuration d’objectif de télémétrie large où l’objectif large est la valeur par défaut, si la région de rognage de la caméra logique est définie sur une taille maximale et que le ratio de zoom est défini sur 1,0, le flux physique de l’objectif de télémétrie sera configuré sur sa région de rognage de taille maximale (aucun zoom). Déconseillé : avant Android 11, le champ d’affichage de tous les flux physiques non RAW ne peut pas être supérieur à celui des flux logiques non RAW. Si la caméra logique a une configuration de lentille à grande échelle où l’objectif large est la valeur par défaut, lorsque la région de rognage de la caméra logique est définie sur une taille maximale, la FOV des flux physiques pour l’objectif ultra-large sera la même que le flux logique, en rendant la région de rognage plus petite que sa taille de tableau active pour compenser la plus petite longueur focale. Pour une caméra logique, les caméras physiques sous-jacentes ont généralement différentes fonctionnalités RAW (comme la résolution ou le modèle CFA). Il existe deux façons pour l’application de capturer des images RAW à partir de la caméra logique : si la caméra logique dispose d’une fonctionnalité RAW, l’application peut créer et utiliser des flux RAW de la même façon que précédemment. Si un flux RAW est configuré, pour maintenir la compatibilité descendante, l’appareil photo garantit que la caméra physique active par défaut reste active et ne passe pas à d’autres caméras physiques. (Une exception est que, si la caméra logique se compose de capteurs d’images identiques et publie plusieurs focalLength en raison de différents objectifs, l’appareil photo peut générer des images RAW à partir de différentes caméras physiques basées sur le focalLength défini par l’application.) Cette approche rétrocompatible entraîne généralement une perte de zoom optique, de téléobjectif ou de lentille ultra-large ; Sinon, si elle est prise en charge par l’appareil, MultiResolutionImageReader peut être utilisée pour capturer des images RAW à partir de l’une des caméras physiques sous-jacentes (en fonction du niveau de zoom actuel). Étant donné que différentes caméras physiques peuvent avoir des caractéristiques RAW différentes, l’application doit utiliser les caractéristiques et les métadonnées de résultat de la caméra physique active pour les métadonnées RAW pertinentes Les balises de métadonnées de requête de capture et de résultat requises pour les fonctionnalités de caméra compatible descendante seront uniquement basées sur la fonctionnalité de caméra logique. En revanche, l’utilisation de contrôles de capture manuels (capteur ou post-traitement) avec une caméra logique peut entraîner un comportement inattendu lorsque le HAL décide de basculer entre les caméras physiques avec différentes caractéristiques sous le capot. Par exemple, lorsque l’application définit manuellement le temps d’exposition et la sensibilité lors du zoom avant, la luminosité des images de la caméra peut changer soudainement, car HAL passe d’une caméra physique à l’autre. Les parties de cette page sont des modifications basées sur le travail créé et partagé par Android Open Source et utilisées en fonction des termes décrits dans la Creative Commons 2.5 Attribution License. |
| Monochrome | 12 | L’appareil photo est une caméra monochrome qui ne contient pas de tableau de filtres de couleurs, et pour YUV_420_888 flux, les valeurs de pixels sur vous et les plans V sont toutes 128. Une caméra MONOCHROME doit prendre en charge les combinaisons de flux garanties requises pour son niveau d’appareil et ses fonctionnalités. En outre, si l’appareil photo monochrome prend en charge le format Y8, toutes les exigences de combinaison de flux obligatoires liées à YUV_420_888 s’appliquent également à Y8. Il n’existe aucune exigence obligatoire en matière de combinaison de flux en ce qui concerne Y8 pour les appareils photo Bayer. À partir d’Android Q, les SENSOR_INFO_COLOR_FILTER_ARRANGEMENT d’une caméra MONOCHROME seront mono ou NIR. Les parties de cette page sont des modifications basées sur le travail créé et partagé par Android Open Source et utilisées en fonction des termes décrits dans la Creative Commons 2.5 Attribution License. |
| SecureImageData | 13 | L’appareil photo est capable d’écrire des données d’image dans une région de mémoire inaccessible à l’espace utilisateur Android ou au noyau Android, et uniquement accessible aux environnements d’exécution approuvés (TEE). Les parties de cette page sont des modifications basées sur le travail créé et partagé par Android Open Source et utilisées en fonction des termes décrits dans la Creative Commons 2.5 Attribution License. |
| SystemCamera | 14 | L’appareil photo est accessible uniquement par les composants système d’Android et les applications privilégiées. Les processus doivent avoir le android.permission.SYSTEM_CAMERA en plus d’android.permission.CAMERA pour se connecter à cet appareil photo. Les parties de cette page sont des modifications basées sur le travail créé et partagé par Android Open Source et utilisées en fonction des termes décrits dans la Creative Commons 2.5 Attribution License. |
| OfflineProcessing | 15 | L’appareil photo prend en charge le cas d’usage OFFLINE_PROCESSING. Avec OFFLINE_PROCESSING fonctionnalité, l’application peut basculer une session de capture en cours en mode hors connexion en appelant la méthode CameraCaptureSession#switchToOffline et en spécifiant les flux à conserver en mode hors connexion. L’appareil photo arrête ensuite les demandes répétées actives, préparez certaines demandes en mode hors connexion et retournez un objet de session hors connexion. Une fois l’appel switchToOffline retourné, la session de capture d’origine est en état fermé comme si la méthode CameraCaptureSession#close a été appelée. En mode hors connexion, toutes les demandes en arrière-plan continueront d’être traitées en arrière-plan, et l’application peut fermer immédiatement la caméra ou créer une session de capture sans perdre les images de sortie de ces demandes et les résultats de capture. Bien que l’appareil photo traite les demandes hors connexion, il peut ne pas être en mesure de prendre en charge toutes les configurations de flux qu’il peut prendre en charge sans demandes hors connexion. Quand cela se produit, l’appel de méthode createCaptureSession échoue. Les configurations de flux suivantes sont garanties pour fonctionner sans atteindre l’exception occupée par la ressource : une session hors connexion en cours : cibler une surface de sortie au format YUV ou JPEG, toute résolution ; Session de capture de caméra active :; Une surface d’aperçu (SurfaceView ou SurfaceTexture) jusqu’à 1920 largeur ; Une surface ImageReader YUV jusqu’à 1920 largeur ; Un Jpeg ImageReader, toute résolution : l’appareil photo est autorisé à ralentir la vitesse de sortie JPEG de 50% s’il existe une session hors connexion en cours ; Si l’appareil prend en charge PRIVATE_REPROCESSING, une paire d’images ImageWriter/ImageReader présente un format privé, avec la même résolution supérieure ou égale à la résolution JPEG ImageReader ci-dessus ; Vous pouvez également remplacer la session de caméra active ci-dessus par une caméra héritée par les paramètres suivants : Taille d’aperçu jusqu’à 1920 largeur ; Taille de rappel d’aperçu jusqu’à 1920 largeur ; Taille de la vidéo jusqu’à 1920 largeur ; Taille de l’image, toute résolution : l’appareil photo est autorisé à ralentir la vitesse de sortie JPEG de 50% s’il existe une session hors connexion en cours Les parties de cette page sont des modifications basées sur le travail créé et partagé par Android Open Source et utilisées en fonction des termes décrits dans la Creative Commons 2.5 Attribution License. |
| UltraHighResolutionSensor | 16 | Cet appareil photo est capable de produire des images ultra haute résolution en plus des tailles d’image décrites dans android.scaler.streamConfigurationMap. Il peut fonctionner en mode « par défaut » et en mode « résolution maximale ». Cela se fait généralement en binning pixels en mode « par défaut » et non en les binning en mode « max resolution ». android.scaler.streamConfigurationMap décrit les flux pris en charge en mode « par défaut ». Les configurations de flux prises en charge en mode « résolution maximale » sont décrites par android.scaler.streamConfigurationMapMaximumResolution. La taille maximale du tableau de pixels en mode résolution d’un appareil photo (android.sensor.info.pixelArraySize) avec cette fonctionnalité sera d’au moins 24 millisecondes. Les parties de cette page sont des modifications basées sur le travail créé et partagé par Android Open Source et utilisées en fonction des termes décrits dans la Creative Commons 2.5 Attribution License. |
| RemosaicReprocessing | 17 | L’appareil prend en charge le retraitement à partir du format RAW_SENSOR avec un modèle bayer donné par android.sensor.info.binningFactor (m x n groupe de pixels avec le même filtre de couleur) à un modèle bayer régulier remosaïque. Cette fonctionnalité ne sera présente que pour les appareils dotés d’une fonctionnalité REQUEST_AVAILABLE_CAPABILITIES_ULTRA_HIGH_RESOLUTION_SENSOR. Lorsque REQUEST_AVAILABLE_CAPABILITIES_ULTRA_HIGH_RESOLUTION_SENSOR appareils ne publient pas cette fonctionnalité, les images ImageFormat.RAW_SENSOR ont déjà un modèle bayer standard. Si un flux RAW_SENSOR est demandé avec un autre flux non RAW dans captureRequest (si plusieurs flux sont pris en charge lorsque android.sensor.pixelMode est défini sur SENSOR_PIXEL_MODE_MAXIMUM_RESOLUTION), le flux RAW_SENSOR aura un modèle bayer standard. Cette fonctionnalité nécessite que l’appareil photo prend en charge les éléments suivants : StreamConfigurationMap mentionné ci-dessous fait référence à celui décrit par android.scaler.streamConfigurationMapMaximumResolution ; Un flux d’entrée est pris en charge, c’est-à-dire android.request.maxNumInputStreams == 1 ; ImageFormat.RAW_SENSOR est pris en charge comme format de sortie/entrée, autrement dit, ImageFormat.RAW_SENSOR est inclus dans les listes de formats retournés par StreamConfigurationMap.getInputFormats() et StreamConfigurationMap.getOutputFormats() ; StreamConfigurationMap.getValidOutputFormatsForInput(int) retourne un int non vide[] pour chaque format d’entrée pris en charge retourné par StreamConfigurationMap.getInputFormats() ; Chaque taille retournée par getInputSizes(ImageFormat.RAW_SENSOR) est également incluse dans getOutputSizes(ImageFormat.RAW_SENSOR) ; L’utilisation de ImageFormat.RAW_SENSOR n’entraîne pas de chute de fréquence d’images par rapport au taux de capture maximal du capteur (à cette résolution) ; Aucun contrôle CaptureRequest n’est applicable lorsqu’une requête a une cible d’entrée au format ImageFormat.RAW_SENSOR Les parties de cette page sont des modifications basées sur le travail créé et partagé par Android Open Source et utilisées en fonction des termes décrits dans la Creative Commons 2.5 Attribution License. |
| DynamicRangeTenBit | 18 | L’appareil prend en charge une ou plusieurs sorties de caméra 10 bits en fonction des profils de plage dynamique spécifiés dans DynamicRangeProfiles.getSupportedProfiles(). Ils peuvent être configurés dans le cadre de l’initialisation de session de capture via OutputConfiguration.setDynamicRangeProfile(long). Les caméras qui activent cette fonctionnalité doivent également prendre en charge les éléments suivants : Profile DynamicRangeProfiles.HLG10 ; Toutes les combinaisons de flux obligatoires pour cette fonctionnalité spécifique en fonction de la documentation ; Si l’appareil ne peut pas capturer une combinaison de profils de plage dynamique standard 8 bits et/ou 10 bits pris en charge dans la même demande de capture, ces contraintes doivent être répertoriées dans DynamicRangeProfiles.getProfileCaptureRequestConstraints(long) ; Profil de plage dynamique recommandé répertorié dans CameraCharacteristics.REQUEST_RECOMMENDED_TEN_BIT_DYNAMIC_RANGE_PROFILE Les parties de cette page sont des modifications basées sur le travail créé et partagé par Android Open Source et utilisées en fonction des termes décrits dans la Creative Commons 2.5 Attribution License. |
| StreamUseCase | 19 | L’appareil photo prend en charge la sélection d’un cas d’usage par flux via OutputConfiguration.setStreamUseCase(long) afin que l’appareil puisse optimiser les paramètres de pipeline de caméra, tels que le réglage, le mode capteur ou les paramètres ISP pour un scénario utilisateur spécifique. Certains exemples d’utilisations de cette fonctionnalité sont les suivants : distinguer les captures YUV de haute qualité à partir d’un flux YUV normal où la qualité de l’image peut ne pas être aussi bonne que le flux JPEG, ou ; Utilisez un flux à plusieurs fins : viseur, enregistrement vidéo et capture. Cela est courant avec les applications qui souhaitent appliquer des modifications de manière égale à l’aperçu, aux images enregistrées et aux vidéos enregistrées Cette fonctionnalité nécessite que l’appareil photo prend en charge les cas d’usage de flux suivants : DEFAULT pour la compatibilité descendante où l’application ne définit pas de cas d’usage de flux ; PRÉVERSION pour l’analyse des images en direct et dans l’application ; STILL_CAPTURE pour la capture de photos toujours ; VIDEO_RECORD pour enregistrer des clips vidéo ; PREVIEW_VIDEO_STILL pour un seul flux utilisé pour le viseur, l’enregistrement vidéo et la capture ; VIDEO_CALL pour les appels vidéo longs CameraCharacteristics.SCALER_AVAILABLE_STREAM_USE_CASES répertorie tous les cas d’usage de flux pris en charge. Reportez-vous aux instructions relatives aux combinaisons de flux obligatoires impliquant des cas d’utilisation de flux, qui peuvent également être interrogées via MandatoryStreamCombination. Les parties de cette page sont des modifications basées sur le travail créé et partagé par Android Open Source et utilisées en fonction des termes décrits dans la Creative Commons 2.5 Attribution License. |
| ColorSpaceProfiles | 20 | L’appareil prend en charge l’interrogation des combinaisons possibles d’espaces de couleurs, de formats d’image et de profils de plage dynamique pris en charge par l’appareil photo et demande un espace de couleur particulier pour une session via SessionConfiguration.setColorSpace(nommé). Les caméras qui permettent cette fonctionnalité peuvent implémenter ou non des profils de plage dynamique. Si ce n’est pas le cas, ColorSpaceProfiles.getSupportedDynamicRangeProfiles(Named, int) retourne uniquement DynamicRangeProfiles.STANDARD et ColorSpaceProfiles.getSupportedColorSpacesForDynamicRange(int, long) suppose la prise en charge du profil DynamicRangeProfiles.STANDARD dans toutes les combinaisons d’espaces de couleurs et de formats d’image. Les parties de cette page sont des modifications basées sur le travail créé et partagé par Android Open Source et utilisées en fonction des termes décrits dans la Creative Commons 2.5 Attribution License. |
Remarques
Les parties de cette page sont des modifications basées sur le travail créé et partagé par Android Open Source et utilisées en fonction des termes décrits dans la Creative Commons 2.5 Attribution License.