Gamma 2,2 to uproszczenie, którym posługuje się cała branża — prawdziwe sRGB, LogC czy ACEScct mają dodatkowe segmenty, o których żaden slider Ci nie powie.
Rozdział 2 pokazał, dlaczego percepcja jasności jest w przybliżeniu logarytmiczna. Najprostszy sposób, żeby to przybliżyć jedną funkcją, to potęga:
Gamma nie jest wynalazkiem branży efektów specjalnych — to spadek po kineskopach (CRT). Działo elektronowe starego telewizora czy monitora fizycznie reagowało na napięcie sterujące z wykładnikiem bliskim 2,4–2,5: podwojenie napięcia nie dawało podwojenia jasności plamki, tylko jasność w przybliżeniu proporcjonalną do napięcia podniesionego do tej potęgi. Żeby obraz wyglądał poprawnie, sygnał trzeba było więc wcześniej zakodować odwrotną potęgą (1/γ) — i ten krok, historycznie czysto elektroniczna konieczność, przypadkiem zadziałał też jako niezłe przybliżenie krzywej percepcji z Rozdziału 2. Nowoczesne ekrany (LCD, OLED) nie mają już fizycznego działa elektronowego, ale zachowały ten sam standard kodowania cyfrowo — dekodują go programowo, nie dzięki fizyce lampy.
Czysta funkcja potęgowa ma jedną niewygodną własność blisko zera: jej pochodna przy V=0 dąży do nieskończoności (dla wykładnika mniejszego niż 1, jak 1/2,4). W praktyce oznacza to, że najmniejsze różnice w wartości liniowej blisko czerni zostałyby wzmocnione do bardzo dużych skoków w wartości zakodowanej — każdy szum czy błąd zaokrąglenia w cieniach eksplodowałby na widoczne artefakty. Standard sRGB (IEC 61966-2-1) rozwiązuje to, zastępując sam dół krzywej krótkim odcinkiem liniowym:
Progi 0,0031308 (w linear) i 0,04045 (w sRGB) to dokładnie ten sam punkt na krzywej, wyrażony w dwóch różnych jednostkach — miejsce, w którym odcinek liniowy przechodzi w odcinek potęgowy tak, żeby wartość i nachylenie funkcji zgadzały się po obu stronach (bez tego przejście byłoby widoczne jako subtelny załamek na krzywej). Dokładne wyprowadzenie tych stałych — skąd się bierze akurat 1,055 i 0,055 — jest w Dodatku C; tutaj wystarczy wiedzieć, że różnica między tą pełną formułą a uproszczoną gołą potęgą 1/2,2 jest w praktyce niewielka.
Ekran SDR ma zakres rzędu 7–10 stopów (Rozdział 2) — i krzywa gamma jest dobrana pod dokładnie taki zakres: rozkłada dostępne kody (8 czy 10 bitów) tak, żeby wystarczyło ich na cienie i światła w tych granicach, bez widocznego bandingu. Nowoczesna matryca kamery filmowej rejestruje jednak 12–16 stopów i więcej. Gdyby zapisać taki materiał wprost krzywą gamma zaprojektowaną pod ekran, coś musi ucierpieć: albo górne stopy się przepalą (zabraknie kodów, żeby je odróżnić od bieli), albo cienie stracą precyzję, bo gamma i tak większość dostępnych kodów kieruje w stronę czerni, zostawiając mało miejsca dla rozciągniętego w górę zakresu jasnych partii.
Log encoding rozwiązuje to inaczej niż gamma: zamiast krzywej potęgowej używa logarytmu, którego kluczowa własność to stały krok kodu na każdy stop (podwojenie jasności), niezależnie od tego, czy ten stop leży blisko czerni czy blisko granicy zakresu matrycy. Gamma tej własności nie ma — jej „gęstość kodów na stop” zmienia się wzdłuż krzywej. To dlatego materiał z kamery filmowej bywa nagrywany w formie „płaskiej”, mało kontrastowej — log nie jest formatem do oglądania, tylko gęstym, równomiernym zapisem surowego zakresu, przeznaczonym do gradingu (Część III) już po zdjęciach.
Krzywe log kamer (ARRI LogC, Sony S-Log3) mają stałe dobrane przez producenta pod konkretną matrycę — publikowane w białych księgach danego producenta, sprawdzane per projekt, nie warte zapamiętywania na pamięć. ACEScct, log encoding samego ACES używany jako working space pod grading (Rozdział 6, Dodatek G), ma stałe w pełni jawne i publiczne — dobry, konkretny przykład tej samej idei:
ARRI LogC (obecnie w wersji Wide Gamut / LogC4), Sony S-Log3 i historyczny Cineon (log encoding zaprojektowany jeszcze pod skan negatywu filmowego, prekursor całej tej rodziny krzywych) mają dokładnie tę samą architekturę — krótki liniowy odcinek blisko czerni plus segment logarytmiczny — różniącą się stałymi dobranymi pod konkretną matrycę czy skaner. Rozdział 6 pokazuje, gdzie w praktyce Arnold i RenderMan aplikują te krzywe automatycznie, zamiast liczyć je ręcznie w node'ach.
Wiesz już, czym są te krzywe i po co istnieją. Rozdział 6 pokazuje, jak w praktyce nie liczy się ich ręcznie w każdym node'zie — jeden config OpenColorIO aplikuje właściwe dekodowanie na wejściu, właściwy working space w środku i właściwy display transform na wyjściu, automatycznie, w viewporcie Arnolda i RenderMana naraz.