Contrast
I’ve always had a hate/hate relationship with the “contrast” slider – no matter which software. It would always clip the shadows, or worse, create negative values if used on floating point data (less of an issue in Photoshop but easily observable in Fusion). It looked ugly and I’ve spent a lot of redoing other people’s grading nodes because the color values were broken all over the place.
If you don’t know it already, here’s what the contrast slider usually does:
contrast as found in most image editing software
If you color-correct in sRGB (yuck) the slider really does change the picture’s contrast. But like I said, it clips shadow details pretty quickly. Which translates to “instantaneous” in linear (non-gamma-corrected) space where color values are tiny. The better way to increase contrast was an S-shaped curve tool (recently, Photoshop has finally improved its contrast algorithm and labeled the formula it used before as “legacy”).
Nuke also has a contrast slider in its color correction node. First I avoided it like the plague until I tried it on a test gradient to figure out what it does. Lo and behold, it’s actually usable since its formula has been re-invented for linear floating point pipelines. It is actually a gamma correction but instead of “pivoting” around a value of 1.0 it is anchored on 0.18 – neutral gray in linear space:
contrast as implemented in Nuke (on a scale from 0.0 to 1.0)
The formula is easy to implement: pow(color / 0.18, contrast_value) * 0.18
Of course it needs a failsafe when contrast_value is zero, but this is obviously a constant value of 0.18.
I have built this formula into a Fuse for Fusion along with Nuke’s other color correction sliders. This makes the tool useful to copy color corrections made in a Nuke script to Fusion. It could have been a macro, but the Fuse API allowed me to play around with the GUI and make Nuke users feel even more at home – myself included.
Download and more info at Vfxpedia.
Log2Lin
Analoger Film ist tot, mag sich mancher bereits denken. Doch ganz so schnell wird der Spaß mit dem dpx-Format und dem logarithmischen Farbraum vermutlich nicht verschwinden.
Bisher habe ich unhinterfragt als log-lin-Konvertierung nur die Standardkurven verwendet, die bekanntlich auf Kodak-Filmmaterialien von vor zig Jahrzehnten basieren. Black Level 95, White 685, Gamma 0.6.
Erst kürzlich hat mir jemand vom Filmexperten “Josh Pines” erzählt, dessen alternative Methode der logarithmischen Konvertierung wohl ein kleiner heiliger Gral sein muss. Zumindest in angloamerikanischen High-End-Schmieden (Weta usw.) ist sie im Einsatz und schon deshalb schadet es wohl kaum, sie zu übernehmen. Pines’ Formel behebt nämlich das Problem, dass negative Werte entstehen können, die im Compositing ein pain in the ass sind.
Eine leicht zu implementierende Version habe ich auf der OpenEXR-Liste gefunden. In der folgenden Formel ist x ist der Farbwert im logarithmischen Raum, er wird aber als float-Werte zwischen 0 und 1 eingesetzt, und nicht als 10-Bit-Wert zwischen 0 und 1023.
y = pow(10.0, (x * 1023 – LogReference) * 0.002 / Gamma) * LinReference
Gamma = 0.6
LogReference = 445
LinReference = 0.18
Und Rückwärts als lin2log:
y = (LogReference + log10(max(x, 0.0000001 ) / LinReference) * Gamma / 0.002) / 1023
Der Wert 445 auf der logarithmischen Skala wird auf den mittleren Grauwert im linearen Raum (0,18) abgebildet. Hier sind Implementierungen der Formeln als Fusion-Makro:
Das resultierende lineare Bild ist, wie man an der oben abgebildeten Kurve sieht, etwas dunkler. Im sRGB Farbraum fällt das wiederum wenig auf, das Bild wirkt lediglich etwas flauer, da die Schwärzen – siehe Ausschnittsvergrößerung – ja angehoben wurden.
