Notes concernant ACES
Introduction
Terminologie
- AP0 : ACES Primaries 0, les primaires standards ACES.
- AP1 : ACES Primaries 1, les primaires ACEScg.
- IDT : Input Device Transform. La transformation appliquée aux entrées pour les passer en espace ACES (plans de tournage, textures).
- ODT : Output Device Transform. La transformation appliquée aux sorties (mp4, images pour le web), à ne pas confondre avec les vues, même si certaines LUT, telle que sRGB, sont similaires.
- EOTF : Electro-Optical Transfer Function
- OETF : Opto-Electronic Transfer Function
Des courbes avant de commencer
La courbe ci-dessus représente la relation entre l’intensité du signal électrique (l’intensité des diodes du moniteur) et l’intensité optique (la lumière) généré. Encore une fois, on observe qu’une alimentation de moitié ne renvoie pas la moitié de son intensité, mais beaucoup moins (0.18).
Quand on travaille dans un logiciel qui ne gère pas les espaces colorimétriques (ou qu’on choisit sciemment de ne pas s’en préoccuper) on a donc cette réponse : Les pixels sombres de notre image (ou texture) sont donc affiché pratiquement deux fois plus sombre que leur valeur réelle. Pour compenser ça, on a tendance à instinctivement monter les valeurs sombres. En fait on fait une image sRGB, sRGB étant la réponse de notre moniteur.
C’est la raison pour laquelle cette courbe est également appliquée aux images en entrée des logiciels, afin de rabaisser les valeurs sombres qui ont été augmentées par vous (du fait de la réponse non-linéaire de votre moniteur).
Ceci est la courbe de réponse de ACES sur un moniteur sRGB. Notez comment la valeur de 1.0 est affiché à 0.812… sur l’écran. Ceci permet de laisser un écart entre 0.812… et 1.0 pour afficher les valeurs entre 1.0 et 16.0 (qui ne sont pas affichés sur cette courbe).
Plus d’informations ici.
.png)
Cette courbe est une juxtaposition des deux précédentes. C’est la fameuse courbe filmic (ou S-shaped) supposé diminuer la valeur des hautes lumières pour en rendre le contenu distinguable.
Historiquement, c’est le fonctionnement des pellicules Kodak qui, par la magie de la chimie, atténuait l’impression de la lumière au prorata de sa luminosité. Plus la lumière était intense, moins son impression sur la pellicule était forte, permettant d’afficher une large gamme d’intensité lumineuse en une image.
Display-referred VS Scene-referred
ACES intègre une distinction que les habitués de la prise photo connaissent sûrement :
- Les valeurs numériques qu’un moniteur peut afficher (entre 0.0 et 1.0, souvent 0 et 255) combiné à ce que représentent ces valeurs dans le monde réel (à quelle luminosité correspond 0.0 et 1.0 sur le moniteur). On parle alors de Display-referred encoding (ou Display-referred image).
- Les valeurs numériques des pixels (0.0, 0.5, 1.0, 2.0, 16.0, 55. 538.0, etc) d’une image. On parle alors de Scene-referred encoding (ou Scene-referred image).
L’œil a un comportement complexe, mais ce qu’il faut comprendre c’est qu’il est capable de distinguer un écart de contraste (les nuances entre du noir et du blanc) bien plus élevé que ce que les écrans peuvent afficher. Il en est de même, à moindre échelle, pour les caméras capables de représenter des écarts important d’intensités lumineuses.
Sans cette distinction, on appliquerait bêtement la sortie d’une caméra ou d’un rendu sur l’écran, et toute valeur au-dessus de 1 se mettrait immédiatement à brûler. Notez que c’est souvent ce qu’on fait en rendu :
Ce type de brûlure est classique quand on fait du rendu sans prendre en compte cette distinction.
Pourtant, dans la vraie vie, même un spéculaire un peu fort, vous ne le voyez pas blanc brillant. Ceci est dû au fait que vos yeux peuvent en supporter un écart plus important que votre écran. Il faut donc afficher l’image sur votre écran de sorte que les hautes lumières ne soient, en fait, pas si hautes.
En ayant cette distinction en tête, on peut appliquer, sur les valeurs des pixels de notre image (qui est en scene-reffered donc), une courbe (ayant une allure logarithmique) venant compenser les hautes lumières avant l’affichage :
On parle parfois d’appliquer une réponse, car on vient interpréter les valeurs brutes (d’une caméra ou d’un rendu, bref, d’une scène) en valeurs affichables.
La lumière générale en prend un coup : Une valeur de 1, devient 0.812…, mais entre 0.812… et 1.0, vous avez, dans le cas de ACES, des valeurs d’intensité de 1.0 à 16.0. Un peu comme ce que ferait votre œil en fait.
Convertir une séquence d’image EXR ACEScg en MP4
Il y a plusieurs façons de sortir un MP4 depuis une séquence d’image EXR ACEScg.
Passer par une séquence d’image 8 bits
Cette approche consiste à estimer que ffmpeg n’est pas très flexible et lui donner toujours le même type d’entrée avec le format adéquat ; un format simple. On a donc :
EXR ACEScg -> PNG/Tiff sRGB -> ffmpeg
Cette approche simplifie la gestion de la commande ffmpeg qui peut se concentrer sur des problématiques d’exports en s’évitant une manipulation des video filter.
Cela peut se faire par l’outil ocioconvert :
ocioconvert --ch 0, 1, 2 input.exr 'ACES - ACEScg' output.png 'Output - sRGB'
Ou par Nuke.
Passer par la gestion des LUTs de ffmpeg
ffmpeg peut gérer certains formats de LUTs dans les video filter.
Cette approche a le mérite d’éviter une étape intermédiaire, mais complexifie la commande ffmpeg.
Peu de formats de LUTs gèrent correctement les valeurs flottantes et au-dessus de 1 (pour rappel, ACES va de 0 à 16).
D’après mes recherches, seul les LUTs cineSpace (.csp) rassemblent les propriétés suivantes :
- Exportables avec
ociobakelut. - Compatibles avec Nuke.
- Compatibles avec
ffmpeg. - Donne un résultat correct dans les hautes lumières (valeurs au-dessus de 1).
Au même titre que ocioconvert, ociobakelut est un utilitaire de la suite OpenColorIO. Il permet, entre autres, de générer des LUTs de transformation :
ociobakelut --inputspace 'ACES - ACEScg' --outputspace 'Output - sRGB' --format cinespace acescg_to_srgb_cinespace.csp
Plus d’informations d’information avec ociobakelut --help.
Une fois en possession de cette LUT, il faut l’appliquer à l’entrée de la vidéo :
ffmpeg -r 24 -i input.exr -vf lut3d='acescg_to_srgb_cinespace.csp' output.mp4
Note, comme toute commande simple ffmpeg, il est rare que celle-ci soit suffisante.
Le MP4 généré précédemment est fait pour être utilisé avec une fonction de conversion YUV Rec 601.
Dans Nuke, la valeur par défaut du paramètre YCrCb matrix n’est pas claire (Rec 601 ou Rec 709). Si vous devez générer un MP4 lisible avec une conversion Rec 709, il vous faut passer par une conversion de couleur, via colormatrix, comme suit :
ffmpeg -r 24 -i input.exr -vf lut3d=acescg_to_srgb_cinespace.csp,colormatrix=bt470bg:bt709 output.mp4
Le MP4 ainsi généré correspondra aux valeurs des EXR ACEScg quand il est importé dans Nuke avec le paramètre YCrCb matrix à Rec 709.
Exporter une image sRGB (PNG ou JPEG) depuis Houdini
La gestion d’OpenColorIO dans Houdini n’est pas très fine et concerne surtout les viewers (Render et Composite). L’export d’images sRGB reste problématique.
Ainsi, la case « Convert to Image's File Format Colorspace » d’une ROP File Output ne semble pas fonctionner correctement.
Comme proposé ici, l’astuce consiste à appliquer la transformation manuellement. Pour cela, dans votre Image Network, il faut créer un nœud VOP (VEX/VOP COP2 Generator) :
À l’intérieur, il faut créer un ocio_transform (dans Convert/OCIO Transform) :
Ce dernier doit convertir l’espace vos données ACEScg en sRGB d’affichage :
- From Space :
ACES - ACEScg - To Space :
Output - sRGB
En sortie, les valeurs sont donc déjà converties et prêtes à être écrite dans un fichier. Il est donc inutile d’appliquer une quelconque correction ou LUT supplémentaire.
Créez un ROP File Output :
- Décochez « Convert to Image's File Format Colorspace ».
- Assurez-vous que l’Output Gamma est à
1. - Assurez-vous qu’aucune Output LUT.
Bien entendu, utilisez l’extension d’un format de fichier utilisant du sRGB (PNG, JPEG).
Le graph final ressemble à ça :
Vous pouvez maintenant exécuter votre nœud de ROP et utiliser vos images.
Dernière mise à jour : mer. 09 février 2022