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ą.

Przejście na scenocentryczność to skok poznawczy dla większości doświadczonych użytkowników, którzy są przyzwyczajeni do myślenia w sposób ekranocentryczny. W ekranocentrycznej organizacji pracy zwyczajowo zakotwicza się wartość bieli i pozwala, aby korekty tonów obracały się wokół tego punktu, próbując zmaksymalizować jasność, jednocześnie unikając przycinania. W scenocentrycznej organizacji pracy wartości bieli i czerni są płynne i dostosowane do nośnika wyjściowego. Zaleca się, aby użytkownicy zakotwiczyli środkową szarość (która zostanie zachowana bez zmian dla dowolnego nośnika wyjściowego) i pozwolili, aby moduł krzywej filmowej poszerzył lub zawęził zakres dynamiczny wokół tego punktu. Ponieważ 10-bitowa biel HDR jest 4 razy jaśniejsza niż 8-bitowa biel SDR, jakakolwiek sztywna definicja „bieli” staje się nieistotna. Ale zakotwiczenie dla średniej szarości jest w rzeczywistości wygodniejsze, ponieważ utrzymuje średnią jasność obrazu niezmienioną przez transformację widoku.

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