LUT 3D

Transforme les valeurs RVB grâce à un fichier 3D LUT.

Une LUT 3D est une table tridimensionnelle utilisée pour transformer une valeur RVB donnée en une autre valeur RVB. C’est normalement utilisé pour la simulation de film et la gradation de couleurs.

This module accepts .cube, .3dl and .png (haldclut) files. Uncompressed 3D LUT data is not saved in the database or the XMP file, but is instead saved to the 3D LUT file path inside the 3D LUT root folder. It is therefore important to back up your 3D LUT folder properly – sharing an image with its XMP is pointless if the recipient doesn’t also have the same 3D LUT file in their own 3D LUT folder.

The compressed G’MIC format .gmz is no longer supported. If you have .gmz files, see Converting .gmz files below.

Remarque : le module écrête toutes les valeurs en dehors de la plage [0,1]. Vous devrez peut-être réduire la plage des valeurs d’entrée avant d’appliquer la LUT.

Utilisation

Les LUT sont le plus souvent utilisées dans Ansel pour l’étalonnage des couleurs ou la simulation de rendu film. Pour cette raison, par défaut, le module est placé après le module filmique dans le pixelpipe et doit être appliqué à une image neutre (sans appliquer au préalable un rendu spécifique). Bien que vous puissiez trouver des centaines de LUT gratuites sur Internet, notez que toutes ne sont pas compatibles avec l’environnement et le flux de travail d’Ansel – les LUT incompatibles ne produiront pas le rendu annoncé. Pour limiter le risque, une LUT d’étalonnage des couleurs doit avoir été créée pour fonctionner avec l’un des « espaces colorimétriques d’application » disponibles (voir ci-dessous), à la fois pour l’entrée et la sortie du module.

Les LUTs log de caméra (comme F-log ou S-Log3) sont différentes des LUTs de gradation de couleurs et de simulation de film, et sont destinées à convertir les données logarithmiques brutes de la caméra en quelque chose (données brutes linéaires ou autre espace colorimétrique) que Ansel est capable de comprendre. Dans ce cas, le module lut 3D doit être placé manuellement entre les modules dématriçage et profil de couleur d’entrée. Une fois cela fait, vous ne pouvez plus choisir l’« espace de couleur » (dans lut 3D). Le « profil d’entrée » du module de profil de couleur d’entrée doit être aligné avec la sortie de la LUT. Veuillez noter que ce cas d’utilisation n’a pas encore été testé.

Contrôles du module

sélection du fichier

Choisit le fichier LUT 3D à utiliser. La sélection du fichier est inactive si le dossier racine des LUT 3D n’a pas été défini dans préférences > traitement.

espace de couleur

Une LUT 3D est définie par rapport à un espace de couleur spécifique. Choisissez l’espace de couleur pour lequel le fichier LUT 3D sélectionné a été créé. Les fichiers Cube sont généralement liés à REC.709 tandis que la plupart des autres sont liés à sRGB.

interpolation

Définit comment calculer les couleurs de sortie lorsque les couleurs d’entrée ne sont pas exactement sur un nœud du cube RVB décrit par la LUT 3D. Trois méthodes d’interpolation sont disponibles : tétraédrique (par défaut), trilinéaire et pyramidale. Habituellement, vous ne verrez aucune différence entre les méthodes d’interpolation, sauf avec des LUT de petite taille.

Converting .gmz files

What changed, and why

Ansel used to read .gmz, G’MIC’s own compressed LUT container. Support for it has been removed, along with the G’MIC dependency itself.

The reason is proportion. Ansel called exactly three functions from G’MIC — read a .gmz, decompress its keypoints, cache the result — and linking those three functions meant linking all of G’MIC: a 7.4 MB shared library that in turn pulls in around fifty more, among them libcurl, OpenSSL, libssh, LDAP, Kerberos and SASL — a complete HTTP and TLS stack, in a photo editor — plus an X11 display stack and G’MIC’s own private copies of libpng, libjpeg, libtiff, OpenEXR, WebP and FFTW, duplicating decoders Ansel already links directly. G’MIC also required Ansel to raise the stack size of every thread it creates to 2 MiB, and it published its own OpenMP thread count process-wide, which silently overrode Ansel’s “CPU cores” preference for anyone who set it.

That was the cost. The benefit, measured over 61 days of anonymous usage statistics: the whole 3D LUT module accounts for 0.2 % of module activations, and .gmz is only a fraction of that — most people who use LUTs use .cube.

Nor is .gmz merely a container that could have been parsed in a few lines. Its keypoints are reconstructed either by a dense radial-basis-function solve or by a multiscale diffusion PDE, both written in G’MIC’s own scripting language. Reimplementing and then maintaining two numerical solvers in Ansel, forever, to read a format that ships alongside a .cube equivalent, is not a trade worth making.

So the format is deprecated, and converting is a one-off.

The easy way: download the .cube version

Most .gmz files in circulation are the G’MIC film-emulation CLUT collections, and the same collections are published as .cube. Before converting anything, check whether the pack you use offers a .cube download — for most people that is the whole procedure.

Converting with the G’MIC command line

G’MIC’s own command-line tool reads .gmz and writes .cube. Install it:

A .gmz can hold a single LUT or a whole library of them, each with a name. This command converts every LUT in the file, one .cube per LUT, keeping the original names:

1mkdir -p converted
2gmic input.gmz foreach { nm={n} decompress_clut 33,33,33 output_cube converted/$nm.cube }

Reading it left to right: load the .gmz; for each LUT it contains, remember the LUT’s name, decompress its keypoints into a 33×33×33 cube, and write that cube out under the remembered name. Capturing {n} before decompress_clut matters — the decompression step replaces the image name with an internal expression, so a naive output_cube {n}.cube produces files called things like (256;0^256;255^256;1).cube.

33,33,33 is the output resolution, and 33 is the conventional size for a .cube. You can ask for more (65,65,65) at the cost of a much larger file and a slower conversion; the keypoints hold no more detail either way, so this only changes how finely the reconstruction is sampled.

For a single-LUT file where you do not care about the name, the short form is enough:

1gmic input.gmz decompress_clut 33,33,33 output_cube output.cube

Decompression is not instant — it is solving a scattered-data interpolation problem — so expect a few seconds per LUT.

Converting with the GIMP plugin

If you would rather not use a terminal, the G’MIC-Qt plugin for GIMP can do it: open the .gmz, and in the CLUT filters set the output mode to Save CLUT as .cube or .png File.

Afterwards, in Ansel

Put the converted .cube files in your 3D LUT root folder (set in preferences > processing), then select the LUT again in the module. The result is identical: the .cube holds the same reconstructed LUT that Ansel used to compute from the .gmz on every load, so this is also slightly faster to open.

Existing edits that referenced a .gmz will not be silently altered. Ansel detects them and applies no LUT at all, rather than guessing; in the darkroom you get a dialog naming the file, and elsewhere a line in the log identifying the image. Those edits need the LUT re-selected once, pointing at the converted .cube.

This applies as well to edits made with a much older version, which stored the compressed LUT data inside the edit rather than referencing a file. Ansel recognises those too, and the remedy is the same.