Linear light workflow

Co dokładnie znaczy „liniowe”

Przypomnij sobie najprostszy wzór na oświetlenie rozproszone z raytracing-book (Rozdział 5):

Ten wzór jest wprost proporcjonalny względem L_i: podwój jasność źródła światła, a L_o też się podwoi. To jest dokładnie to, co znaczy liniowość radiometryczna — nie „prosta linia na wykresie” w sensie ogólnym, tylko konkretna własność fizyczna: ilość energii świetlnej i liczba, którą tę energię reprezentujesz, rosną w tym samym tempie. Dwa razy więcej fotonów = dwa razy większa liczba. Bez tego założenia każdy wzór z poprzedniej książki — Lambert, Fresnel, rozkład GGX — przestaje dawać sensowne wyniki, bo cała ich algebra (dodawanie wkładów wielu świateł, mnożenie przez cosinus, całkowanie po hemisferze) zakłada dokładnie tę proporcjonalność.

Piksel w pliku to nie to samo co jasność fizyczna

Rozdział 2 pokazał, że oko reaguje na jasność w przybliżeniu logarytmicznie, nie liniowo — i że z tego powodu formaty obrazu (a za nimi każdy monitor) kodują jasność percepcyjnie, gamma lub logiem, żeby nie marnować poziomów tam, gdzie oko i tak ich nie rozróżnia. To świetne rozwiązanie dla plików, które ktoś ogląda — i fatalne, jeśli wrzucić taką liczbę wprost do wzoru na L_o powyżej, bo ten wzór nie wie nic o percepcji. On zakłada, że liczba, którą dostaje, jest proporcjonalna do fotonów, a wartość 0,5 zapisana w pliku sRGB reprezentuje nie połowę fizycznej jasności bieli, tylko dużo mniej — mniej więcej jedną piątą (dokładny wywód krzywej sRGB w Rozdziale 5 i Dodatku C).

Co się dzieje, kiedy zabraknie dekodowania

Najprostszy sposób, żeby zobaczyć problem na liczbach: uśrednij dwa piksele tekstury — jeden ciemny (0,2), jeden jasny (0,8) — tak, jak robi to każde rozmycie, mipmapping czy crossfade. Porównaj wynik, gdy uśredniasz wartości wprost z pliku (błędnie), z wynikiem, gdy najpierw je dekodujesz do linear, uśredniasz fizyczną jasność, i dopiero potem kodujesz z powrotem do wyświetlenia (poprawnie).

Ten sam mechanizm — nie losowy, tylko systematyczny błąd w jedną stronę — stoi za klasycznym objawem „render wygląda spłowiały/zmatowiały mimo poprawnych wzorów”: ktoś gdzieś w łańcuchu uśrednił, przefiltrował albo przemnożył wartości zakodowane percepcyjnie tak, jakby były liniowe.

Trzy miejsca, w których liniowość najczęściej się łamie

• Tekstury kolorowe wchodzące bezpośrednio do BRDF — plik Base Color/Albedo zapisany jako PNG czy JPG jest w sRGB; jeśli renderer nie zdekoduje go przed podstawieniem jako k_d we wzorze powyżej, cały shading network liczy na złych liczbach od samego początku. Pełny mechanizm w Rozdziale 11.
• Filtering i mipmapping na zakodowanych wartościach — dokładnie ten sam problem co w policzonym przykładzie wyżej, tylko wykonywany automatycznie przez GPU czy renderer przy budowie mipmap. Jeśli filtrowanie zdarza się przed dekodowaniem, każdy poziom mipmapy jest odrobinę pociemniony (raytracing-book, Dodatek G, opisuje mechanikę mipmappingu samą w sobie).
• Blending i crossfade w kompozytingu — dissolve między dwoma ujęciami, rozmycie ruchu liczone na już zakodowanym obrazie, czy nawet zwykłe „opacity 50%” w złym trybie — wszystkie cierpią na ten sam błąd, jeśli operują na wartościach display-referred zamiast scene-referred.

Linear light workflow jako reguła, nie wyjątek

Linear light workflow to nazwa dla prostej zasady porządkującej wszystko powyżej: dekoduj na wejściu, licz w scene-linear, koduj dopiero na wyjściu — i nigdzie pomiędzy. „Scene-linear” oznacza tu przestrzeń, w której liczby są wprost proporcjonalne do fizycznej ilości światła (tak jak w formule z pierwszej sekcji) — cały shading, cały light transport, całe blending i filtering z poprzedniej sekcji powinny się odbywać właśnie w niej. Kodowanie percepcyjne (gamma, log) pojawia się tylko w dwóch miejscach: na wejściu, przy odczycie tekstur kolorowych zapisanych percepcyjnie (dekodowanie w drugą stronę), i na wyjściu, przy wysłaniu finalnego obrazu na ekran (display transform).

Zwróć uwagę, że sam mechanizm dekodowania i kodowania to na razie czarna skrzynka — „jakaś krzywa gamma”. Rozdział 5 pokazuje, czym dokładnie ta krzywa jest (i że prawdziwe sRGB to coś więcej niż czysta potęga), a Rozdział 6 pokazuje, jak w praktyce ten cały pipeline konfiguruje się jednym configiem OCIO zamiast ręcznie w każdym node'zie. Ta sama zasada „dekoduj na wejściu, koduj na wyjściu” jest już wspomniana pobieżnie w raytracing-book (Dodatek E) — tam jako ciekawostka zamykająca temat renderowania; tutaj jest to fundament, na którym stoi reszta książki.