ASCII

Im VFX- und Grading-Workflow wird ein neutrales Format benötigt, das zwischen verschiedenen Software-Umgebungen funktioniert, ohne dass Daten verfälscht oder neu interpretiert werden. ASCII-basierte Austauschformate lösen exakt dieses Problem — sie speichern Farbkorrektionen, Keyframes und Effekt-Parameter als reiner Text, nicht als proprietäre Binär-Dateien. DaVinci, Nuke, After Effects und Premiere lesen diese Dateien nativ ein, weil sie auf dem gleichen Standard basieren.

Praktisch am Set und im Schnitt: Wenn der Colorist eine Grading-Session in DaVinci abschließt und der VFX-Supervisor die gleichen Farbwerte in Nuke weiterverwenden muss, wird die Korrektur nicht als fertige Bilddatei exportiert — die Werte werden als Text geschrieben: RGB-Kurven, Lift/Gamma/Gain, Sättigung, alles als Zahlen und Befehle. Das Zielprogramm liest diese Zeilen und rekonstruiert die Korrektur pixel-perfect. Keine Neuinterpretation, keine Farbverfälschung durch JPG- oder ProRes-Kompression. Besonders bei Archivierung und Long-Term-Workflows, wo jahrelang später noch auf alte Korrekturwerte zurückgegriffen werden muss, schützt ASCII vor proprietären Software-Updates, die Dateien unlesbar machen können.

Grenzen und Realität: ASCII ist textbasiert, deshalb groß und relativ langsam beim Parsing großer Datenmengen. Moderne VFX-Pipelines verwenden daher oft binäre Varianten (wie HEX oder OpenEXR-Metadata), bleiben aber intern an ASCII-kompatible Strukturen gebunden. Ein Nuke-Script selbst ist ASCII — lesbar, editierbar, versionierbar. Deshalb funktioniert Collaboration: Mehrere Artist:innen können an der gleichen .nk-Datei arbeiten, Änderungen mergen, Konflikte tracken wie im Code.

In der Praxis empfiehlt sich daher: Kritische Grading-Sessions, Lookup-Tables und VFX-Parameter werden immer in textbasierten Formaten gespeichert, nicht nur als finale Render.