Qu’est-ce qu’un fichier EXR ?

Un fichier EXR est une image à grande plage dynamique stockée au format OpenEXR : un ou plusieurs canaux nommés d’échantillons en virgule flottante sur 16 bits ou sur 32 bits, ou d’entiers non signés sur 32 bits, accompagnés d’attributs d’en-tête qui les décrivent. Les données de pixels peuvent être non compressées ou utiliser l’une des différentes méthodes de compression avec ou sans perte.

Fonctionnement des fichiers EXR

Un fichier OpenEXR commence par un nombre magique de quatre octets (76 2f 31 01) et un champ de version dont les bits indicateurs signalent un fichier tuilé à partie unique, un fichier à plusieurs parties ou la présence de données profondes. L’indicateur de tuilage n’est activé que pour une image tuilée à partie unique ; dans les fichiers à plusieurs parties et les fichiers à données profondes, l’attribut type de chaque partie indique si elle contient des lignes de balayage ou des tuiles. Vient ensuite un en-tête d’attributs nommés par partie ; channels, compression, dataWindow, displayWindow, lineOrder, pixelAspectRatio, screenWindowCenter et screenWindowWidth sont obligatoires dans chaque en-tête. Les pixels sont stockés dans des blocs, soit des groupes de lignes de balayage, soit des tuiles, localisés au moyen d’une table de décalages. Seuls les fichiers tuilés peuvent contenir plusieurs niveaux de résolution (mipmaps ou ripmaps) ; un fichier à lignes de balayage n’en contient qu’un. Depuis OpenEXR 2.0, un fichier peut contenir plusieurs parties indépendantes et des données profondes, dans lesquelles chaque pixel contient une liste d’échantillons de longueur variable. Par convention, les canaux de couleur sont prémultipliés par alpha. En production, un EXR contient généralement des images issues du rendu ou de la composition, qui sont transformées ultérieurement pour l’affichage.

Points clés

  1. Ne supposez pas que le fichier contient une seule image RGBA. Chaque canal déclare son propre nom et son propre type : HALF (virgule flottante sur 16 bits) pour les données d’image ordinaires, FLOAT (sur 32 bits) lorsqu’une plage ou une précision supérieure est nécessaire, par exemple pour la profondeur, et UINT (sur 32 bits) pour les valeurs discrètes telles que les identifiants d’objets. Seuls quelques noms, comme R, G, B et A, ont une signification prédéfinie ; les calques reposent sur une convention de nommage telle que light1.specular.R, et un fichier à plusieurs parties ajoute des parties nommées séparément. Il faut indiquer à un convertisseur lesquels de ces éléments doivent constituer l’image de sortie, ou le laisser choisir.
  2. La taille de l’image découle de deux rectangles. La fenêtre d’affichage est le cadre prévu ; la fenêtre de données est la région qui contient effectivement des pixels, et elle peut être plus petite (une région d’intérêt rendue) ou plus grande (une marge hors cadre conservée pour les flous ou les tremblements de caméra). Chaque fenêtre est définie par les coordonnées de ses pixels d’angle ; une fenêtre d’affichage allant de (0, 0) à (1919, 1079) mesure donc 1920 sur 1080. La documentation d’OpenEXR indique que les pixels situés au-delà de la fenêtre d’affichage ne sont normalement pas affichés et qu’une visionneuse remplit d’une couleur par défaut la zone d’affichage extérieure à la fenêtre de données. Un logiciel qui dimensionne sa sortie à partir de la seule fenêtre de données attribue à ces fichiers des dimensions ou un placement incorrects.
  3. Le caractère sans perte de la compression dépend de la méthode et parfois du type de canal. L’attribut compression de l’en-tête s’applique à tous les canaux correspondants ; une méthode doit donc convenir à chaque type de canal stocké avec les autres. PIZ, ZIP, ZIPS et RLE sont sans perte. PXR24 conserve exactement les canaux HALF et UINT, mais arrondit les données FLOAT à 24 bits. B44 et B44A sont avec perte pour les canaux HALF et laissent les canaux UINT et FLOAT non compressés. DWAA et DWAB sont des méthodes avec perte fondées sur la DCT pour les données RGB. Les données profondes n’autorisent que l’absence de compression, RLE, ZIPS ou ZIP. La documentation actuelle répertorie aussi des méthodes plus récentes : HTJ2K256 et HTJ2K32 (sans perte, High-Throughput JPEG 2000), LJ2K (avec perte) et ZSTD (sans perte). Vérifiez que chaque lecteur de la chaîne de traitement prend en charge la méthode utilisée pour l’écriture.
  4. Par convention, les valeurs RGB sont linéaires par rapport à la lumière de la scène, et 1,0 n’est pas une limite d’écrêtage. La convention OpenEXR place le gris moyen à 0,18, et les objets lumineux tels que le feu et les hautes lumières dépassent légitimement 1,0 ; l’affichage d’une telle image nécessite donc au moins une correction gamma et souvent un mappage tonal. Il s’agit d’une convention, pas d’une garantie : la documentation indique que les images sont censées être linéaires et que la bibliothèque n’exige pas que l’espace colorimétrique déclaré soit linéaire. Le fichier peut également ne pas indiquer de manière fiable les primaires RGB qu’il utilise : la documentation précise que l’attribut chromaticities n’est plus jugé fiable, que l’absence de colorInteropID n’implique pas un espace Rec. 709 linéaire, et que colorInteropID, introduit dans OpenEXR 3.4, est désormais l’identifiant recommandé. Convenez de l’espace colorimétrique, y compris du caractère linéaire ou non des valeurs, avec la personne qui a produit les fichiers plutôt que de le déduire.

Quand les fichiers EXR sont utiles

Les chaînes de traitement d’effets visuels choisissent EXR pour la composition en lumière linéaire, les passes de rendu et les fichiers intermédiaires de haute précision. C’est un format de travail : par convention, ses valeurs de couleur décrivent la lumière de la scène et non un signal d’affichage ; produire un dérivé affichable nécessite donc une transformation colorimétrique délibérée ainsi qu’un choix des canaux, de la partie et de la fenêtre à utiliser.

Comment Transloadit vous aide avec les fichiers EXR

Le tableau des formats d’image de Transloadit, qui couvre les Robots fondés sur ImageMagick tels que /image/resize, répertorie EXR comme un format que ces Robots peuvent lire et écrire. La ligne indique la version de la bibliothèque OpenEXR incluse dans la version compilée d’ImageMagick, ce qui délimite les méthodes de compression et les attributs que cette dernière peut reconnaître.

Le tableau indique ce que la version compilée d’ImageMagick peut lire et écrire. Il ne documente pas les canaux, la partie, la fenêtre ou la transformation colorimétrique qu’utilise une conversion. Traitez un fichier de production représentatif avec votre Assembly et examinez le résultat avant de vous y fier.

Explorer les possibilités de Transloadit en matière de formats de fichiers et de compression

Références

Transformer vos connaissances sur les médias en une chaîne de traitement opérationnelle

Reliez les téléversements, le traitement, l’IA, le stockage et la diffusion via une seule API déclarative — la pile d’encodage, la montée en charge et l’évolution constante des formats sont prises en charge pour vous.

Essayer Transloadit gratuitement