Żaden z poprzednich 22 rozdziałów nie powiedział wprost: liczby, na których liczysz Lamberta, Fresnela i GGX, muszą być liniowe — a liczby w plikach tekstur i na ekranie liniowe nie są. To najczęstszy praktyczny błąd w całym renderingu.
Oko ludzkie jest dużo czulsze na różnice w ciemnych partiach obrazu niż w jasnych — z tego powodu formaty obrazów od dekad kodują jasność krzywą gamma (~potęga 1/2,2), przydzielając więcej „poziomów” tam, gdzie oko i tak widzi więcej szczegółu. To kodowanie percepcyjne, nie fizyczne.
Tekstura zapisana jako PNG czy JPG (Rozdział 9) jest prawie zawsze w sRGB — bo to, co widzisz w przeglądarce plików, ma wyglądać dobrze na ekranie. Zanim jej kolor wejdzie jako kd do wzoru Lamberta z Rozdziału 5, trzeba go zdekodować z powrotem do liniowej przestrzeni (odwrotność gamma). Zapomnienie o tym kroku to jeden z najczęstszych błędów: render wygląda spłowiały albo zbyt kontrastowy, mimo że wzory są matematycznie poprawne.
Uwaga: to dotyczy tylko tekstur kolorowych (Base Color, Albedo). Mapy „danych” — normal maps, roughness, metallic, maski — nie reprezentują jasności światła, tylko surowe liczby, więc nie przechodzą dekodowania gamma. To dokładnie ta sama para: przełącznik „sRGB” / „Non-Color” przy każdym slocie tekstury w Blenderze, Unrealu i Unity.
Wynik z path tracingu (Rozdział 15) jest liniowym HDR — jasne piksele (słońce, żarówka widziana z bliska) mogą mieć wartości znacznie większe niż 1, bez górnego limitu. Ekran przyjmuje tylko 0–1. Zwykłe obcięcie (clip) każdej wartości >1 do 1 daje brutalnie „wypalone”, płaskie highlighty.
„Color Management” w Blenderze (Standard vs Filmic vs AgX), „OCIO” w Nuke, domyślny ACES w Unrealu i Arnoldzie — to wszystko wybór operatora tone mapowania z tego rozdziału. Klasyczny symptom „mój render wygląda płasko/wyblakło” w 90% przypadków to niedopasowanie color management, nie problem z oświetleniem.
Dodatek F wraca do Rozdziałów 3 i 17: pełna matematyka macierzy 4×4 i współrzędnych jednorodnych, która stoi za każdą transformacją w tej książce.