kolejka przetwarzania koloru w darktable

Większość aplikacji do przetwarzania obrazu pochodzi z lat 90. i/lub dziedziczy przepływ pracy z lat 90. XX wieku. Aplikacje te przetwarzały obrazy zakodowane za pomocą 8-bitowych liczb całkowitych bez znaku, ponieważ były one bardziej wydajne pod względem pamięci i obliczeń. Jednak ze względu na użycie formatu liczb całkowitych (co implikuje błędy zaokrąglania) musieli zastosować „gamma” (zasadniczo funkcję transferu stosującą potęgę 1/2,2 lub 1/2,4 do kodowania wartości RGB) i zwiększyć głębokość bitową w słabym oświetleniu, aby zmniejszyć tam błędy zaokrągleń (ludzie są bardzo wrażliwi na szczegóły przy słabym oświetleniu). 8-bitowe formaty liczb całkowitych są również technicznie ograniczone do zakresu 0-255. Wszystko poza tym zakresem przepełnia się i jest przycinane do najbliższej granicy.

Te przepływy pracy, wykorzystujące ograniczone reprezentacje RGB i prawdopodobnie nieliniowe transformacje do kodowania sygnałów RGB, są nazywane „ekranocentrycznymi”. Opierają się na założeniu, że obraz został przygotowany do wyświetlania na wczesnym etapie procesu przetwarzania, i osadzają zakodowane założenia dotyczące wartości RGB czerni, średniej szarości i bieli. Większość algorytmów przetwarzania obrazu używanych w tych przepływach pracy została dostosowana do tych założeń. Na przykład tryb mieszania nakładek oczekuje średniej szarości zakodowanej w 50% (lub 128 w kodowaniu całkowitym).

Niestety skalowanie nieliniowe, które jest niezbędne, aby kodowanie liczb całkowitych działało, łamie naturalne relacje między wartościami pikseli. Odcień i nasycenie zmieniają się w nieprzewidywalny sposób, a relacje wartości między sąsiednimi pikselami są rozszerzane lub kompresowane w taki sposób, że gradienty również ulegają nieprzewidywalnym zmianom.

Kolejki ekranocentryczne niszczą zatem filtry optyczne (rozmycie lub rozmycie soczewki), kompozycję alfa (która opiera się na optycznych i geometrycznych definicjach okluzji), kolory i gradienty (lokalne relacje między chrominancją a luminancją pikseli). Nie skalują się również dobrze do obrazów HDR, co doprowadziło do rozwoju wielu wątpliwych lokalnych i globalnych metod mapowania tonów oraz niesławnego „wyglądu HDR” z 2010 roku.

Współczesne komputery nie mają takich samych ograniczeń obliczeniowych, jak te z lat 90.. i mogą pracować na pikselach, których wartości są całkowicie nieograniczone (od 0 do + nieskończoności) i zakodowanych jako liczby rzeczywiste (przy użyciu formatów zmiennoprzecinkowych). Możliwości te umożliwiają to, co nazywamy „scenocentrycznym” przepływem pracy, w którym piksele mogą zachować swoje oryginalne relacje radiometryczne niemal w całej kolejce przetwarzania. W scenocentrycznej organizacji pracy piksele są przygotowywane do wyświetlania tylko na ostatnim etapie kolejki, w transformacji wyświetlania. Oznacza to, że wartości RGB pikseli są utrzymywane proporcjonalnie do intensywności emisji światła, zarejestrowanej przez kamerę na scenie, umożliwiając dokładne komponowanie alfa i emulacje filtrów optycznych, a także skalowanie do dowolnego zakresu dynamicznego za pomocą tego samego algorytmu (SDR oraz HDR).

Scenocentryczne kolejki przetwarzania tracą jednak wygodne, stałe wartości bieli, szarości i czerni, które charakteryzują kolejki ekranocentryczne, a ustawienie tych wartości zgodnie ze sceną i warunkami fotografowania staje się teraz obowiązkiem użytkownika. Wymaga to bardziej złożonego interfejsu użytkownika.

Ponadto, ponieważ wartości scenocentryczne mają mieć znaczenie fizyczne, piksele nie mogą mieć zerowej intensywności. Oznaczałoby to, że w ogóle nie mają światła, a istnienie zerowego światła łamie wiele fizycznie dokładnych algorytmów. W rzeczywistości biel i czerń nic nie znaczą w odniesieniu do oryginalnej sceny, która jest jedynie zbiorem luminancji o różnym natężeniu. Scenocentryczna organizacja pracy ma po prostu na celu ponowne odwzorowanie niektórych dowolnych luminancji scen na to, co będzie wyglądać na białe lub czarne na nośniku wyjściowym.

Wersje darktable wcześniejsze, niż 2.6, wspierały nieliniową kolejkę ekranocentryczną zakładając, że nieliniowa transformacja miała miejsce na początku kolejki, a średni szary został później zakodowany jako 50%. Jednak nie wszystkie moduły i filtry przycinały wartości pikseli powyżej 100%, pozostawiając otwartą możliwość odzyskania tych wartości później w kolejce.

Przekształcenie widoku modułu krzywej filmowej, wprowadzone w darktable 2.6, było pierwszym krokiem w kierunku kolejki scenocentrycznej i odroczyło obowiązkowe, nieliniowe przygotowanie wyświetlacza do końca kolejki, wraz z możliwością ustawienia niestandardowego koloru czarnego, szarego i wartości bieli. Moduł balansu kolorów wprowadził następnie sposób radzenia sobie ze zmienną definicją średniej szarości.

Począwszy od darktable 3.2, użytkownicy mogli wybierać między dwiema organizacjami pracy, które definiowały spójne domyślne ustawienia, moduły i kolejność kolejki zarówno dla przetwarzania ekrano-, jak i scenocentrycznego.

W darktable 3.4 wprowadzono pełne opcje maskowania i mieszania scenocentrycznego, pozwalające na definiowanie masek dla wartości pikseli powyżej 100% i przy użyciu wyłącznie operatorów mieszania, nie ograniczonych tą wartością.

Switching to scene-referred is a cognitive leap for most experienced users, who are used thinking in display-referred ways. In a display-referred workflow, it is customary to anchor the white value and let tone adjustments revolve around that point, trying to maximize brightness while avoiding clipping. In a scene-referred workflow, white and black values are fluid and adapted to the output medium. It is advised that users anchor middle-gray (which will be preserved as-is for any output medium) and let the view transform (filmic) dilate or contract the dynamic range around that point. Because 10 bit HDR white is 4 times as bright as 8 bit SDR white, any rigid definition of “white” becomes irrelevant. But anchoring for middle-gray is actually more convenient, since it keeps the average brightness of the image unchanged through the view transform.

Niektóre moduły (poziomy, poziomy rgb, krzywa tonalna, krzywa rgb) są z natury niezgodne ze scenocentryczną organizacją pracy, ponieważ ich interfejs graficzny domyślnie sugeruje wartości RGB ograniczone do zakresu od 0 do 100%. Chociaż operacje na pikselach, które wykonują, mogą być używane zarówno przy ekrano-, jak i scenocentrycznej organizacji pracy, ponieważ są one wewnętrznie nieograniczone, ich interfejs sterujący nie pozwala na wybieranie pikseli poza zakresem 0-100%.

Podobnie tryby mieszania, takie jak nakładka, światło liniowe, miękkie światło, ostre światło, przyciemnianie, rozjaśnianie itp., mają zakodowane na stałe progi, które wewnętrznie oczekują nieliniowego kodowania ekranocentrycznego.

W darktable 3.4 i późniejszych przesunięcie kursora na tekstową etykietę nagłówka modułu pokazuje podpowiedź, zawierającą przestrzenie barwne, zakresy i kodowania, których moduł oczekuje, używa i które produkuje. Poniżej znajduje się lista użytych pojęć:

liniowe
Wartości pikseli są proporcjonalne do emisji radiometrycznej sceny w sposób, który umożliwia dokładną emulację filtrów fizycznych.
nieliniowe
Wartości pikseli są przeskalowane w taki sposób, że obszary gorzej oświetlone otrzymują większy zakres kodowania, zwykle w celu przemapowania referencyjnej średniej szarości 18,45% do wartości między 46 a 50%.
ekranocentryczne
Oczekuje się, że wartości pikseli będą leżeć między 0 a 100% zakresu wyświetlania, gdzie 100% jest rozumiane jako luminancja 20% odbijającej białej powierzchni (biała plama wzornika kolorów), a 0% jest rozumiane jako maksymalna gęstość nośnika wyjściowego (nasycony czarny tusz lub minimalne podświetlenie panelu LED).
scenocentryczne
Oczekuje się, że wartości pikseli będą większe od zera aż do +nieskończoności. Znaczenie poszczególnych wartości pikseli musi zostać zdefiniowane przez użytkownika w czasie wykonywania. Wartości scenocentryczne nie oznaczają automatycznie kodowania liniowego, skalowanego radiometrycznie.

translations