Elementy sterujące kolorem wreszcie poprawne

Wprowadzenie

Narzędzia kontra maszyny, rzemiosło kontra przemysł

W swojej książce Społeczeństwo technologiczne  (1954) Jacques Ellul przedstawia różnicę między okresem przed- i porewolucji przemysłowej w następujący sposób:

Epoka przedindustrialna to panowanie narzędzia i rzemiosła. Najważniejszą cechą narzędzi jest to, że są ogólne, wszechstronne i łatwe do przystosowania. To rzemieślnik musi rozwijać swoje umiejętności, aby narzędzia podążały za jego intencją, tak by ręka nadrabiała ograniczenia instrumentu. Koncepcja ta jest wciąż dobrze znana dzisiejszym muzykom: musisz ćwiczyć, uczyć się, próbować, ponosić porażki, próbować ponownie… nie ma dróg na skróty. Ellul podkreśla ideę oszczędności, która towarzyszy narzędziom: zasoby są ograniczone, więc Twój zestaw narzędzi jest w zasadzie określony przez to, na co Cię stać, co możesz nosić, opanować i zbudować lokalnie. Trendy zmieniają się powoli i są lokalne, ponieważ wykorzystują lokalne zasoby i dostosowują się do lokalnych potrzeb, a narzędzia podążają za tym samym wzorcem. Narzędzia to dziedzictwo przekazywane od mistrza do ucznia, od rodzica do dziecka. Nie stają się niekompatybilne ani przestarzałe.

Epoka przemysłowa to panowanie maszyny. Wywodzi się z kultury standaryzacji i umasowienia. Maszyna jest znacznie bardziej produktywna, ponieważ jest wyspecjalizowana do jednego zadania, ale jest bezużyteczna do wszystkiego innego i rzadko można ją przystosować do innego zastosowania. Kiedy zmieniają się potrzeby produkcyjne, maszyna zostaje zastąpiona inną, ponieważ do niczego innego się nie nadaje. To już nie jest schemat oszczędny i jest dopuszczalny, ponieważ zasoby są znacznie tańsze, a produkcja masowa umożliwia korzyści skali. Wtedy ludzie stają się sługami maszyny, a rękodzieło staje się luksusem.

Produkcje, które kiedyś odbywały się w domu lub w małych warsztatach, w kontekście rodzinnym, przenoszone są do wielkich fabryk, gdzie jest dość miejsca na maszyny. Nawiasem mówiąc, miało to bardzo konkretne skutki dla tego, jak organizujemy nasze codzienne życie, w tym kiedy i ile razy jemy¹, a także dla wzorców snu². Nie będzie więc przesadą stwierdzenie, że rewolucja przemysłowa głęboko zmieniła również sposób, w jaki myślimy, to, co uważamy za normalne czy oczywiste.

To do mnie przemówiło, ponieważ tak właśnie, intuicyjnie, rozwijałem narzędzia do edycji koloru od samego początku: próbując budować ogólne narzędzia, które opierają się na jak najmniejszej liczbie założeń, by pozostać wszechstronnymi, dając jednocześnie precyzyjną kontrolę nad parametrami obrazu, i ostatecznie polegając na umiejętnościach rzemieślników, a nie na na wpół zepsutych, niezweryfikowanych, automagicznych narzędziach, które działają tylko w idealnych przypadkach.

Fotografia cyfrowa: automatyzowanie czy czerpanie radości z procesu?

Nigdy nie rozumiałem pasji wielu fotografów, zwłaszcza tych najbardziej technofilskich, do procesów sterowanych jednym przyciskiem i procedur zautomatyzowanych. Uczyłem się i uczyłem gry na fortepianie, i jestem przyzwyczajony do paradygmatu zamknij się i ćwicz: trenowania, by rozwijać i utrzymywać sprawność, a następnie powtarzania tych samych kilku taktów raz za razem, aż dźwięk będzie właściwy. Wypracowywania jakości, faktury i wyrazistości dźwięku poprzez ilość nacisku, jaki wywierasz na klawisze, prędkość ataku, ruch nadgarstka i przedramienia. Używania ciała do precyzyjnego ruchu i trenowania go ponad jego obecne możliwości, przekształcania bardzo nienaturalnych gestów w odruchy. I wreszcie uczenia się, jak usłyszeć w umyśle dźwięk, do którego dążysz, zanim jeszcze poruszysz rękami. Wszystkich tych rzeczy, których nigdy nie da się sprowadzić do suwaków i przycisków interfejsu, metryk, zmiennych czy algorytmów.

Sposób, w jaki wielu fotografów podchodzi do edycji zdjęć, brzmi tak, jakby zostali ukarani przez fotografię cyfrową, bo teraz muszą używać oprogramowania, by otrzymać swoje zdjęcia. Zatem należy to sprowadzić do bezdusznej procedury, w której wszystko powinno być zautomatyzowane, jeśli tylko się da. Wymieniamy się gotowymi ustawieniami i przepisami, niektórzy nawet je sprzedają. A teraz mamy jeszcze AI, które naśladuje ten czy inny styl. Gdzie tu radość z industrializacji twórczości artystycznej? Jaki jest sens posiadania hobby, które sprawia wrażenie ciężaru, jakim jest konieczność wywoływania swoich zdjęć? Sztuka jest procesem, a nie procedurą. Jaki chory umysł zaprojektowałby robota, który zamiast Ciebie zajmuje się garncarstwem, grawerowaniem czy układaniem kwiatów? A gdyby tak wykorzystać oprogramowanie jako okazję do dopracowania wyglądu swoich obrazów zgodnie z własnym gustem i wrażliwością? Czy zatraciliśmy czystą przyjemność robienia rzeczy samodzielnie, nawet nieudolnie? W jakim wieku ten apetyt się traci?

Owszem, walka z oprogramowaniem do edycji zdjęć jest frustrującym doświadczeniem, ale musisz zrozumieć, z czym walczysz. Czy to po prostu wewnętrzna trudność Twojego rzemiosła i brak umiejętności, czy też kiepski projekt narzędzia? Kiedy zmagasz się z fortepianem za 25 tys. €, który dopiero co był u technika fortepianowego, wiesz, że instrument nie jest problemem. Ale w przypadku oprogramowania — skąd masz to wiedzieć? Cóż, nie możesz, dopóki w pełni nie zaangażujesz się w paradygmat zamknij się i ćwicz. Dobrzy retuszerzy uzyskają dobre wyniki z każdego oprogramowania, różnica polega na tym, ile czasu im to zajmie. No i, cóż, czasami trzeba dużo nadrabiać za zepsute modele koloru w aplikacjach do edycji.

Narzędzia w interfejsie edycji zdjęć

Jeśli chodzi o projektowanie interfejsu, oszczędność ogólnych, wszechstronnych narzędzi jest najlepszym sposobem, by nie dać się przytłoczyć dziesiątkom funkcji, które wzajemnie się zasłaniają, pokrywają w działaniu i po prostu zaśmiecają Twoje pole widzenia. To feng shui oprogramowania. Ale wtedy natura narzędzi nieco się przesuwa.

Istnieją dwa sposoby myślenia o elementach sterujących kolorem w przetwarzaniu obrazu: od strony ich zastosowania funkcjonalnego oraz od strony sposobu, w jaki pozwalają manipulować właściwościami koloru. Od strony ich zastosowania funkcjonalnego:

Zauważ, że przesunięcie koloru można by ponownie podzielić na dwa tryby: korekcyjny (który wymaga modeli światła) i twórczy (który wymaga modeli percepcyjnych). Nie zajdziemy aż tak daleko.

Jeśli podejdziemy do tej samej listy z drugiego punktu wyjścia — od strony sposobu, w jaki pozwalają manipulować właściwościami koloru — otrzymamy:

Nie przerabiałem całej listy, ale rozumiesz, o co chodzi: niezależnie od tego, czy chcesz sklasyfikować swoją listę narzędzi według metody, czy według funkcji, nie otrzymasz dopasowania jeden do jednego, poza kilkoma przypadkami. Zatem żadne z tych odwzorowań nie pozwala Ci systematycznie sprowadzić narzędzi do jednostkowych elementów interfejsu, tak by uczynić zadość zasadzie oszczędności.

A do tego przetwarzanie obrazu to nie jest po prostu zestaw narzędzi w skrzynce — to w istocie potok (pipeline) filtrów pikseli, które trzeba wstawić jako węzły grafu w kolejności odpowiadającej wymaganiom wejściowym filtrów. Proszę bardzo (w uproszczeniu):

flowchart TD
    r(Raw input) --> d1[Raw denoise]
    d1 --> demosaic[Demosaic]
    demosaic --> d2[RGB denoise]
    d2 --> wb[White balance]
    wb --> bright1["Brightness enhancement (linear)"]
    bright1 --> blur1[Blur / Deblur]
    blur1 --> color_lin["Color shift (linear)"]
    color_lin --> contrast1["Contrast enhancement / Brightness enhancement (non-linear)"]
    contrast1 --> color_nl["Color shift (non-linear) / Colorfulness enhancement"]
    color_nl --> dr[Dynamic range compression]
    dr --> o(Output)

No i, na koniec, problem, którego nikt nie widzi: matematyka. Na przykład filtr sterowany zastosowany do maski krycia i sterowany obrazem RGB (jak w udoskonalaniu masek w Ansel/Darktable) nie ma tej samej matematyki co filtr sterowany zastosowany do maski luminancji i sterowany samą sobą (jak w korektorze tonalnym) czy pełny obraz RGB sterowany samym sobą (jak w usuwaniu zamglenia). Trzeba je zaimplementować kilkukrotnie, z różnymi typami danych wejściowych i różnymi rodzajami optymalizacji. To samo dotyczy metod działających na obrazach niezdemozaikowanych: musimy uwzględnić fakt, że nie mamy pełnego sygnału RGB w każdym elemencie światłoczułym (sensel), a matryce XTrans wymagają specjalnej matematyki, innej niż Bayer.

Zatem, biorąc pod uwagę, że:

1. funkcjonalności mają różne metody,
2. metod nie da się sprowadzić do pojedynczej funkcjonalności,
3. wszystkie są wstawiane jako węzły w potoku, w którym kolejność ma znaczenie,
4. metody mają warianty implementacji zależne od ich sygnału wejściowego, tj. od ich pozycji w potoku,
5. użytkownicy chcą się dobrze bawić, nie musząc niczego się uczyć,
6. bałagan w interfejsie nikomu nie służy i wszystkich męczy,

…mamy problem: jak podzielić funkcje i zorganizować je w spójny interfejs?

W profesjonalnym środowisku, gdzie można oczekiwać, że użytkownicy potrafią samodzielnie zbudować potok i rozumieją tajniki jego węzłów, można pójść drogą DaVinci Resolve i zbudować edytor węzłowy. Wtedy budujesz jeden węzeł na metodę i obsługujesz wewnętrznie warianty implementacji, sprawdzając typ sygnału wejściowego. To najbardziej minimalistyczny sposób, bo nie ma żadnego dublowania interfejsu: po prostu bank węzłów, a węzły można ustawiać równolegle, zamiast wymuszać kolejność sekwencyjną. Wymaga to jednak użytkowników-ekspertów.

Droga Lightrooma/Capture One polega na całkowitym ukryciu, że w ogóle istnieje potok, i zapewnieniu płaskiego interfejsu. Wtedy wielokrotne instancjonowanie węzłów realizowane jest za pomocą masek: dodawanie nowych masek pozwala przypisać im podzbiór elementów sterujących oprogramowania, aby selektywnie edytować zamaskowane obszary. Wiąże się to jednak również z faktem, że żadna z tych aplikacji nie umożliwia edycji liniowej odniesionej do sceny (scene-referred), co sprawia, że rozmywanie, wyostrzanie, odszumianie i faktyczne przejścia masek działają dziwacznie.

Ansel obiera drogę pośrednią. Po pierwsze, istnieje teraz prototypowy edytor węzłowy:

Pozwala nam to jawnie pokazać kolejność w potoku, ręcznie ją zmieniać i przełączać ustawienia kolejności w sposób, który pokazuje również wejścia i wyjścia. Wcześniej mieliśmy tylko stos modułów interfejsu w prawym pasku bocznym, który jako tako sugerował kolejność potoku, jeśli czytać go jak stos warstw, ale użytkownicy często nadużywali go jako zwykłej wygody porządkowania narzędziownika interfejsu.

A dalej, podział funkcji jest hybrydowy:

• Moduły korektor kontrastu, kontrast lokalny i rozmyj lub wyostrz są z natury dwoiste: mogą zwiększać lub zmniejszać kontrast lokalny i ostrość w zależności od swoich parametrów. Korektor kontrastu ma nawet metodę odszumiania, co ma sens, bo wyostrzanie zwiększa szum, więc właściwym miejscem, by trzymać go pod kontrolą, jest to, gdzie powstaje. To są moduły zorientowane na metodę.
• Balans bieli dubluje funkcjonalność części adaptacji chromatycznej modułu kalibracja koloru. Balans bieli to prosta normalizacja kanałowa, która zachodzi w RGB matrycy i jest potrzebna niektórym metodom demozaikowania (zwłaszcza dla matryc XTrans), podczas gdy kalibracja koloru przeprowadza znacznie dokładniejszą percepcyjnie kompensację iluminanta w przestrzeni CIE CAT16. Przestrzeń ta jest zdefiniowana na podstawie przestrzeni CIE XYZ 1931, którą otrzymujemy dopiero po profilowaniu koloru wejściowego (a to wymaga do działania obrazu zdemozaikowanego). Istnieją różne powody i potrzeby dla obu, i muszą one znajdować się w różnych miejscach potoku. To są moduły zorientowane na potok: choć wydają się funkcjonalnie podobne, ich powody istnienia oraz ich wewnętrzne wymagania (i zupełnie inna matematyka) czynią je znacznie bardziej różnymi, niż mogłoby się wydawać. To samo dotyczy różnych modułów odszumiania: niektóre działają na wejściu RAW, inne nie, a niektóre działają lepiej na sygnałach nieliniowych.
• Balans koloru został zaprojektowany jako kompleksowy moduł koloru, stosujący rozszerzone ASC CDL  (slope-offset-power), a następnie obsługujący globalne i zależne od luminancji nasycenie oraz chromę, zastępując tym samym wcześniejsze moduły Darktable, takie jak contrast-brightness-saturation, vibrance i velvia (wszystkie działające w CIE Lab 1976). Wzięty w oderwaniu, jest to moduł zorientowany na funkcjonalność, ale nie jest jedynym modułem przesuwającym kolor. Pozostałe moduły przesuwające kolor używają bardzo różnych metod (macierze, LUT-y lub elementy sterujące zależne od odcienia), które są od 3 do 9 razy mniej kosztowne obliczeniowo i działają w różnych przestrzeniach barwnych.

Ansel dziedziczy swoją koncepcję modułów po Darktable: moduły są jednocześnie widżetem narzędziownika interfejsu i filtrem pikseli wstawionym gdzieś w potoku. Zatem projektowanie bardzo małych modułów (pod względem funkcji) zrodzi mnóstwo widżetów interfejsu wysokiego poziomu w prawym pasku bocznym, podczas gdy projektowanie bardzo dużych modułów da mniej widżetów wysokiego poziomu, ale będą one wyższe lub będą używać więcej wewnętrznych zakładek. Druga opcja może i tak być korzystniejsza, bo moduły interfejsu wysokiego poziomu działają jak tace, więc mniej tac spójnych funkcjonalnie pomaga lepiej zrozumieć podział funkcji na wysokim poziomie (jak spis treści).

Ale na tym się nie kończy, bo znowu… węzły. Moduł powinien być zestawem elementów sterujących kolorem, które są spójne jako wielokrotnie instancjonowany, zamaskowany węzeł w potoku. Nie ma sensu upychać w module dziesiątków funkcji, gdzie połowa z nich ma znaczenie jako ustawienia globalne, a reszta tylko w lokalności maski; po zinstancjonowaniu będą one jedynie zużywać cykle procesora na darmo.

I wreszcie jest wydajność. Elementy sterujące kolorem, które muszą działać w jakiejś konkretnej przestrzeni barwnej, będą wymagać konwersji koloru tam i z powrotem, co zużyje cykle procesora, więc lepiej, by wszystkie działały w tym samym module, jeśli mają sens razem pod względem funkcjonalności. Ponadto każdy nowy moduł uruchomi nową pętlę po pikselach, co oznacza, że jeszcze raz przeniesie obraz do pamięci podręcznej procesora z/do pamięci RAM. Zatem zwijanie funkcji do tej samej pętli zapobiega dodatkowemu nadużywaniu przepustowości wejścia/wyjścia i pomaga w wydajności.

Zatem, jeśli podsumujemy całą listę ograniczeń, mamy tutaj naprawdę trudne wyzwanie do rozwiązania:

1. powinniśmy zawsze dążyć do budowania jak najmniejszej liczby elementów interfejsu, bo zaśmiecony interfejs sprawia, że wszystko trudno znaleźć (i jest przytłaczający poznawczo): najlepszym miejscem do ukrycia drzewa jest las,
2. bałagan, który tworzymy, powinien być zorganizowany od globalnego do lokalnego, od ogólnego do szczegółowego, od często używanego do niszowego, bo to najłatwiejszy sposób na rozumowanie: myślenie o strukturze interfejsu jako o „spisie treści" to najlepsze, do czego jak dotąd doszedłem,
3. ale uczynienie z tego zasady systematycznego dzielenia funkcji na podstawie funkcjonalności lub na podstawie metody i tak kończy się dublowaniem w obu przypadkach, chyba że pójdziemy w kierunku pełnego edytora węzłowego, zrobimy wszystko w oparciu o metodę i przeniesiemy odpowiedzialność za budowanie potoków na użytkownika-eksperta,
4. moduły powinny być projektowane jako zorientowane na funkcjonalność wszędzie tam, gdzie to możliwe, ale obowiązuje mnóstwo ograniczeń:
   1. typ sygnału wejściowego, który określa pozycję w potoku i może zmusić nas do priorytetowego traktowania zorientowania na potok i dublowania narzędzi,
   2. istotność i spójność zestawu elementów sterujących modułu, gdy jest on wielokrotnie instancjonowany i zamaskowany: moduł powinien być spójną jednostką procesu edycji, a nie workiem, do którego wciśnie się wszystko. Zwłaszcza jeśli ma sens (z punktu widzenia procesu) zastosowanie maski tylko na podzbiorze funkcji modułu, to ten podzbiór powinien być własnym modułem,
   3. kwestie wydajności (podróż w obie strony po przestrzeni barwnej, mapowanie gamutu wyjścia, przepustowość wejścia/wyjścia): nie możemy myśleć o ergonomii użytkownika wyłącznie od strony interfejsu; szybkość działania też jest częścią ergonomii,
   4. matematyczna natura realizowanych operacji: niektóre metody (zwłaszcza wyostrzanie/kontrast lokalny) mogą mieć przeciwne efekty w zależności od znaku swoich parametrów, niektóre metody słabo nadają się do grupowania razem w tym samym filtrze pikseli,
5. wreszcie, trzeba uwzględnić liczbę kliknięć/kroków przewijania potrzebnych do dotarcia do często używanej funkcji, bo oś od ogólnego do szczegółowego nie zawsze jest równoległa do osi od często używanego do niszowego. Zatem, choć organizacja wysokiego poziomu od ogólnego do szczegółowego ma sens poznawczo, nie zawsze jest najbardziej ergonomiczna.

Wszystkie te sprzeczne wymagania trzeba rozstrzygać indywidualnie, analizując całość potoku, w przeciwnym razie nie budujemy aplikacji do pracy, lecz rejestr wtyczek. Znajdują się one na skrzyżowaniu programowania niskopoziomowego, matematyki, procesu retuszu i ergonomii interfejsu, a żadne z tych zagadnień nie jest ogólnie ważniejsze od pozostałych. Jednak niektóre z tych ograniczeń są łatwiejsze do zrozumienia niż inne, przez co poświęca się im znacznie więcej uwagi, w typowym efekcie latarni : dalej ścigasz problemy w warstwie, którą rozumiesz, całkowicie pomijając ich prawdziwe źródło, bo dotyka ono warstwy, której nie rozumiesz / o której nic nie wiesz. Właśnie dlatego praca z „projektantami UX" to prawdziwa udręka, bo zazwyczaj nie mają zaplecza, by spojrzeć poza interfejs, i często nie obchodzi ich, że pod interfejsem jest silnik do sterowania. Nie możesz po prostu postanowić, że anulujesz grawitację, bo chciałbyś usunąć element sterujący pochyleniem  dla prostszego interfejsu.

Projektowanie to proces iteracyjnych udoskonaleń w oparciu o informacje zwrotne od użytkowników. Niektóre z tych iteracji będą przeprojektowywać od makro do mikro (od architektury całej aplikacji do wewnętrznych elementów sterujących modułu), a niektóre będą przeprojektowywać od mikro do makro, aż wszystko zbiegnie się ku ujednoliconej semantyce i spójnemu podziałowi funkcji. Głupotą jest myśleć, że ktokolwiek zrobi to dobrze za jednym podejściem, albo że tylko jeden z poziomów mikro/makro wymaga naprawy. To most, który buduje się z obu końców jednocześnie, szukając sposobu, by spotkały się pośrodku.

Właściwości dobrych elementów sterujących kolorem

Z moich 17 lat doświadczenia w edycji zdjęć oraz 8 lat doświadczenia w studiowaniu i eksperymentowaniu z matematyką przetwarzania obrazu wynika kilka rzeczy, których nauczyłem się o tym, co jest dobrym, a co złym elementem sterującym kolorem. Przez „element sterujący kolorem" rozumiem jakiś sposób przekazania intencji użytkownika algorytmowi pikselowemu, który edytuje wizualną właściwość obrazu. Dobre elementy sterujące kolorem:

1. są względem siebie ortogonalne, co oznacza, że jeden element sterujący zmienia w danej chwili jeden wymiar koloru i nie zmusza Cię do kompensowania innym elementem sterującym,
2. są równomiernie skalowane z perspektywy percepcyjnej, co oznacza, że przejście od „0" do „1" zmieni wynik wizualny o tyle samo, co przejście od „1" do „2". Niestety nie zawsze jest to możliwe, bo matematyka i fizyka Cię nienawidzą.
3. skalują się z gracją wraz ze wzrostem zakresu dynamicznego, co odrzuca w zasadzie wszystkie modele wyglądu koloru (CIE Lab 1976, CIECAM 16, dt UCS 22), zbudowane dla SDR na zbiorach danych zarejestrowanych dla malowanych próbek barwnych.
4. degradują się z gracją wraz ze wzrostem wielkości zmian, co oznacza, że mogą zostać przesadzone, ale nie mogą zmienić treści obrazu ani stworzyć artefaktów,
5. zachowują gradienty obrazu, co oznacza, że utrzymują lokalne wariacje tonalne i chromatyczne jako wariacje, zamiast je spłaszczać, sprawiać, że przestrzeliwują (tworząc halo, obwódki, szum itd.) czy je odwracać.
6. pozwalają artystom zbliżyć się jak najbardziej do ich intencji w jak najkrótszym czasie.
7. nie są zdublowane.

Z punktu 1. wywnioskujemy na przykład, że każdy rodzaj krzywej tonalnej RGB jest zły, bo odbarwi światła i nasyci cienie jako produkt uboczny ilości dodanego kontrastu (luminancji), a nie możesz kontrolować (ani odseparować) wielkości zmiany nasycenia, jaką uzyskasz, od wielkości zmiany kontrastu, o którą prosiłeś, poza sztuczkami takimi jak zachowywanie proporcji RGB czy ręczne masowanie nasycenia/odbarwiania przez zastosowanie krzywej tonalnej. To jest powód istnienia korektora tonalnego, który koryguje kontrast, używając selektywnej regulacji ekspozycji zamiast krzywej tonalnej.

Z punktu 2. wywnioskujemy, że elementy sterujące interfejsu powinny używać modeli wyglądu koloru, gdziekolwiek to możliwe.

Z punktu 3. wywnioskujemy, że modele wyglądu koloru używane w interfejsie nie powinny być używane na pikselu, lecz powinny być przekonwertowane, tak by piksele były obsługiwane w RGB. To typowy paradygmat model-widok-kontroler , który jest konsekwentnie ignorowany we wszystkich aplikacjach do przetwarzania obrazu. Najwyraźniej wśród programistów panuje przekonanie, że model koloru pikseli powinien pokrywać się jeden do jednego z przestrzenią barwną kontrolera interfejsu.

Z punktu 4. wywnioskujemy, że elementy sterujące, które są praktycznie użyteczne tylko na małym podzbiorze swojego zakresu wartości, używają złej matematyki, złych modeli koloru, złych priorów. Tryby awarii są równie ważne jak to, co dzieje się przy użyciu elementów sterujących w ich optymalnym punkcie.

Z punktu 5. po prostu potwierdzamy punkt 3.

Z punktu 6. postawiliśmy nowy problem: wielu fotografów nie ma intencji retuszu/edycji (w sensie: wizualnego celu końcowego), lecz jedynie przesuwa suwaki w kierunku, który zdaje się sprawiać, że obraz wygląda ładniej, i kończy ze szczęśliwym przypadkiem, którego nie potrafiliby odtworzyć (albo porzuca obraz, bo nie umieją nad nim popracować). W tym przypadku nie ma miary sukcesu dla elementów sterujących, bo nie ma różnicy do obliczenia między intencją a wynikiem, skoro intencja jest niezdefiniowana. Dlatego, pracując z informacjami zwrotnymi od użytkowników, musimy być krytyczni i badać, kto mówi i skąd. To znaczy: nie każda informacja zwrotna od użytkownika jest dobrą informacją zwrotną (a lata doświadczenia same w sobie niczego nie dowodzą).

A punkt 7. jest jedynie przypomnieniem poprzedniej sekcji: konieczność zdublowania ustawienia jest zwykle oznaką złego podziału funkcji, albo trzeba mieć dobry powód, by to zrobić.

Wszystkie te przypadki są oczywiście ideałami, do których należy dążyć. W praktyce trzeba ocenić różnych kandydatów i wybrać najlepszego, który rzadko będzie spełniał wszystkie wymagania. Ale żeby ocenić konkurujących kandydatów, najpierw potrzebujesz obiektywnych punktów odniesienia i skal. To są punkty odniesienia, które przez lata stały się dla mnie oczywiste.

Właściwości dobrych procesów edycji

Pamiętam niekończące się łańcuchy e-maili, 9 lat temu na liście mailingowej Darktable (obecnie nieistniejącej), dotyczące tego, jak najlepiej zreorganizować interfejs, w których powiedziano mi: „nie ma dobrego ani złego procesu, są tylko osobiste preferencje". Absolutny relatywizm jest zawsze głupszy, niż brzmi. Ta głupota trwa teraz dalej na discuss.pixls.us. To naprawdę te same dyskusje, mówiące te same rzeczy o tych samych problemach, kręcące się w kółko od ponad 9 lat, i wciąż żadnego namacalnego rozwiązania.

Najpierw mamy oczywisty przypadek, w którym definiujesz maskę parametryczną na, powiedzmy, balansie koloru RGB i ustawiasz ją tak, by wmaskowywać wartości RGB między takimi a takimi + epsilon. Potem jesteś zadowolony z kolorów, ale obraz wygląda trochę ciemno, więc idziesz podnieść ekspozycję. Teraz Twoja maska parametryczna jest nieważna i musisz zrobić ją ponownie, bo ekspozycja znajduje się wcześniej w potoku niż balans koloru RGB, więc przesunąłeś cały swój zakres wartości kodu RGB. To jest edycja cykliczna, to najłatwiejsza do uniknięcia strata czasu, a jeśli chcesz jej zapobiec, nie masz wielkiego wyboru: musisz pilnować kolejności potoku. Edycja cykliczna jest obiektywnie złym procesem. Czy muszę to uzasadniać?

Nie kończy się to na maskach, bo wiele modułów koloru musi znormalizować biel HDR, aby móc używać modeli koloru, które mogą działać tylko przy założeniu, że biel = {1, 1, 1}. Dlatego umieszczam je później w potoku, po globalnych regulacjach jasności i kontrastu.

A dalej mamy przypadek edycji wsadowej: masz serię zdjęć do edycji, chcesz, żeby wyglądały spójnie w całej serii, ale mają drobne wariacje w oświetleniu, kontraście i temperaturze barwowej. Jedynym sposobem, by to zadziałało, jest wykonanie pierwszego kroku normalizacji obrazu, aby obsłużyć indywidualne wariacje obrazów i przekonwertować je do stałego stanu. Gdy to jest zrobione, możesz wsadowo zastosować ten sam styl lub skopiować i wkleić na wierzch historię późniejszych modułów, bo ten następny krok otrzyma znormalizowane „stałe" dane wejściowe i powinien w związku z tym wyprodukować spójne (jeśli nie stałe) wyniki. Niewykonanie tego pierwszego kroku normalizacji sprawi, że następny stanie się całkowicie nieprzewidywalny i niewiarygodny, co zniweczy cel edycji wsadowej. I nawet przy tym pozornie sztywnym procesie i tak będziesz musiał wykonać indywidualne dostrajanie, jeśli naprawdę chcesz spójnych wyników. To nie jest moja opinia, to zwykły fakt: jeśli chcesz spójnych wyjść dla zestawu modyfikacji obrazu ze sztywnymi ustawieniami, potrzebujesz spójnych wejść.

Ma to jednak swoje ograniczenie, bo pracując na sygnale HDR, musisz wcześnie skonfigurować mapowanie tonalne HDR -> SDR, żebyś mógł faktycznie widzieć, co robisz na obrazie, bez przycinania świateł. Jest więc pierwszy krok objęcia widoku swojej treści, a potem krok finalizowania granic zakresu dynamicznego. Oznacza to, że zawsze powinieneś najpierw ustawić globalną ekspozycję, patrząc na tony średnie (i nic więcej), a potem ustawić na razie swój roboczy mapper tonalny. Zatem ta zasada próbowania zakotwiczenia procesu jeden do jednego na kolejności potoku (która sama jest zakotwiczona na wymaganiach wejściowych modułów) ma pewne wyjątki i nie da się jej stosować bez rozeznania.

Co oznacza, że powinieneś był się tego wszystkiego nauczyć. Dobre procesy pochodzą od ludzi, którzy zastanawiali się, jak dostosować się do narzędzi, których używali, patrząc na nie zarówno z praktycznego, jak i teoretycznego punktu widzenia, a nie od zadowolonych szczęściarzy, którzy pomylili wszystkie nawyki, jakie nabyli przez lata, z procesem. Znów, są rzeczy dziejące się pod powierzchnią interfejsu, nie piszemy listów w edytorze tekstu. Od ponad 9 lat wykrzykuję w kółko na forach: TO JEST POTOK, A NIE ROZŁĄCZONY ZBIÓR PRZYPADKOWYCH ELEMENTÓW STERUJĄCYCH OBRAZEM. Kolejność ma znaczenie. Jeśli jest tylko jedna rzecz, którą zrozumiesz z całego tego gadania, to powinna być to właśnie ta.

I uważam, że Lightroom wyrządził wiele szkód oczekiwaniom i zrozumieniu użytkowników, ukrywając swój wewnętrzny potok. Ale u Lightrooma to działa, bo odbiera użytkownikom wiele stopni swobody. Darktable ponownie wykorzystał wiele semantyki interfejsu Lightrooma, oferując jednocześnie stopniowo coraz więcej swobody i bezpośredniej kontroli nad węzłami potoku (wprowadzając przez lata maskowanie na poziomie modułu, potem wielokrotne instancjonowanie modułów i zmianę kolejności względnych instancji, potem maski rastrowe wielokrotnego użytku między niesąsiadującymi modułami, i wreszcie pełną zmianę kolejności modułów), co zmyliło zarówno weteranów, jak i nowicjuszy.

Idea potoku nie jest nawet specyficzna dla fotografii cyfrowej. Malarstwo olejne również ma pewnego rodzaju potok, w którym zaczynasz od przygotowania podłoża, pokrywasz je gruntem, by było mniej chłonne, potem kładziesz kontury, potem przygotowujesz tło, potem nakładasz warstwami swoje laserunki  i wreszcie kładziesz warstwę werniksu. Nikt przy zdrowych zmysłach nie zaczynałby od werniksu i nie kończył gruntem. Fotografia analogowa ma oczywiście potok kąpieli chemicznych, minutników i tym podobnych. A aplikacje do malowania, takie jak Photoshop, Gimp czy Krita, mają jawny potok, zmaterializowany przez warstwy, które wzajemnie się przesłaniają, od dołu do góry, z warstwami efektów, które są niczym innym jak parametrycznymi filtrami pikseli produkującymi dynamiczne wyjścia.

Ale jakimś sposobem, ponieważ oprogramowanie do edycji zdjęć raw sprawia, że wydaje się to oderwane od realiów materialnych, w świecie cyfrowym uchodzi za dopuszczalne pracowanie bez struktury i metody. Proces edycji „niedestrukcyjnej" mógł też zostać zinterpretowany liberalnie jako YOLO , co również nie pomaga. To, że masz Ctrl+Z, nie oznacza, że nagle wszystko jest wybaczające.

Podsumowując, dobre procesy edycji to te, które dają Ci przewidywalne wyniki na każdym kroku, unikając jednocześnie edycji cyklicznej. Muszą być kształtowane przez kolejność potoku, ale nie mogą trzymać się jej jeden do jednego przez cały czas, i musisz kierować się osądem, by odróżnić, kiedy trzymać się potoku, a kiedy od niego odejść. To pozostawia bardzo mało miejsca na osobiste preferencje.

Etyka cyfrowego przetwarzania obrazu

W czasach analogowych artyści pracowali z mediami fizycznymi i mogli wykonywać wszelkiego rodzaju sztuczki oraz znajdować nowe techniki, by osiągnąć niestandardowe rezultaty. Było to dostępne, bo mogłeś fizycznie dotknąć medium, z którym pracowałeś. Artyści byli wolni.

Sztuka cyfrowa jest z natury pełna przemocy, o ile odebrała artystom wolność: teraz nie mogą sami znajdować nowych technik, bo ich sztuka istnieje jako czysta informacja w jakiejś pamięci komputera, więc są ograniczeni do tego, co proponują aplikacje, i mogą albo błagać wydawców/programistów oprogramowania, by uwzględnili ich potrzeby, albo nauczyć się programować i zaprogramować je sami (co jest sporą opłatą wstępną, jeśli nie masz technicznego zaplecza w naukach stosowanych czy informatyce). Utrata wolności może być zamaskowana faktem, że wszystko, co zrobione w oprogramowaniu, jest odwracalne, więc fotografowie nie uszkadzają trwale na przykład negatywów. Co gorsza, oprogramowanie może uczynić Cię bardziej produktywnym, więc z punktu widzenia biznesu to czysty zysk. Ale nie powinno to przesłaniać faktu, że artyści są stawiani w bardziej biernej pozycji konsumenta niż wcześniej i są zdominowani przez tych, którzy umieją i chcą programować za nich, i którzy decydują o tym, jak będą odtąd tworzyć sztukę.

„Przemoc", „tłumienie wolności", „dominacja"… Wiesz, dokąd to zmierza: to się nazywa opresja. Seksowna opresja, która obiecuje Ci osiągnięcie profesjonalnych rezultatów w zaledwie kilka kliknięć bez konieczności chodzenia do szkoły fotograficznej. Albo, w kontekście wolnego oprogramowania, opresja, która wydaje się życzliwa i nieszkodliwa, bo nie ma za co płacić i jest wbudowana prywatność danych. Ale nic z tego nie jest sprzeczne z faktem, że my, programiści, kontrolujemy, co masz prawo robić w/ze swoimi obrazami, a czego nie, bo kontrolujemy kod. Nie dlatego, że zostaliśmy wybrani przez użytkowników, nie dlatego, że jesteśmy kompetentni do danego zadania (do tej pory wykazałem tutaj wielokrotnie, że „zespół" Darktable był niczym więcej niż bandą nierozgarniętych idiotów z nadmiarem wolnego czasu), tylko dlatego, że mamy prawa administratora do jakiegoś repozytorium na Githubie. To daje nam władzę, a władza wiąże się z odpowiedzialnością.

Chodzi mi to po głowie od kilku lat, bo staje się to również dylematem etycznym (na dodatek do wszystkich wcześniej wspomnianych dylematów technicznych), by zdecydować, jakie funkcje dodać, usunąć czy przebudować. Jednocześnie próba zadowolenia wszystkich nie jest możliwa i skończyłaby się przytłoczeniem wszystkich mnóstwem niszowych narzędzi, których nigdy nie użyją (znów: ukrywanie drzewa w lesie). Do tego to również więcej kodu do utrzymania, więc więcej pracy i ciężar dla opiekunów w przyszłości, z większą liczbą zagrożeń dla stabilności oprogramowania. Budowanie scyzoryka szwajcarskiego, który jest ciągle na wpół zepsuty, nikomu nie pomoże.

Pozostaje jednak faktem, że usuwanie elementów sterujących w imię uproszczenia interfejsu może po prostu być odbieraniem wolności, jeśli nie mamy pewności, że podobna funkcjonalność nadal istnieje, w taki czy inny sposób, w oprogramowaniu. Wolność artystyczna nie jest towarem, jest niezbędnym haustem świeżego powietrza w społeczeństwach, które coraz bardziej dryfują w stronę (techno-)faszyzmu, po raz kolejny.

Znów, wszystko to trzeba rozstrzygać indywidualnie. Pozwolenie, by aplikacje do przetwarzania obrazu szły we wszystkich kierunkach naraz, próbując zaspokoić wszystkie potrzeby w jednej aplikacji, nawet te najbardziej osobliwe, doprowadzi do zbudowania pięcionogich owiec, które są niepraktyczne w użyciu dla kogokolwiek. Co zatacza koło z powrotem do mojej pierwszej sekcji: budowania ogólnych, wszechstronnych i wolnych od założeń narzędzi, które można dostosować do wielu różnych potrzeb w sposób sfaktoryzowany. Przemysł kontra rzemiosło.

Produktywność osiąga się przez specjalizację (która, w połączeniu ze standaryzacją, odblokowuje automatyzację), specjalizację osiąga się przez dublowanie, dublowanie tworzy przerost i bałagan w interfejsie, przerost i bałagan są wrogami UX i kreatywności. Wnioskiem z tego wszystkiego jest: wybierzmy, co warto wyspecjalizować, i tym samym utrudnijmy wolność użytkowników. Zatem produktywność jest złym paradygmatem: jej naturalnym wnioskiem jest opresja.

Przeciwieństwem produktywności jest odporność i wszechstronność. Może być wolniejsza (ale czy na pewno?), ale możemy obsłużyć większą różnorodność przypadków tą samą liczbą narzędzi, bez arbitralnego usuwania opcji, a więc wolności użytkownika. Koncepcja odporności została już rozwinięta w kontekście niestabilności społecznej i klimatycznej przez Oliviera Hamanta w jego książce Antidote to the cult of performance. Robustness from nature  (2024). Jednym z jego głównych wniosków jest to, że kult wydajności (lub efektywności) prowadzi jedynie do rywalizacji, która promuje przemoc, a w nadchodzących niestabilnych czasach potrzebujemy współpracy. W społeczeństwie, które produkuje więcej niż wystarczająco, by pokryć potrzeby wszystkich (ale źle to rozdziela), wydajność nie przynosi nam niczego poza większymi zyskami (znów, źle rozdzielonymi). Ale z pewnością produkuje wypalenie, zarówno w ludziach, jak i w ekosystemach.

W oprogramowaniu wypalenie może pochodzić z kilku rzeczy:

1. technostres  związany ze zbyt wieloma aplikacjami, narzędziami, standardami i paradygmatami, do których trzeba się dostosować,
2. przeciążenie informacyjne  związane z nadmiarem widżetów i narzędzi interfejsu do nawigowania,
3. zmęczenie zmianami  związane ze zbyt częstymi aktualizacjami zmieniającymi procesy pracy.

Podsumowując, ściganie się za wydajnością kaskadowo prowadzi do serii wad:

1. z technicznego punktu widzenia oznacza to konieczność budowania bardziej wyspecjalizowanych narzędzi zaśmiecających interfejs, co produkuje przeciążenie informacyjne,
2. z punktu widzenia UX utrzymywanie bałaganu i przeciążenia w rozsądnych granicach implikuje arbitralne wybieranie, czyje potrzeby zostaną zaspokojone (prawdopodobnie większości), a czyje zignorowane, co jest odbieraniem wolności artystycznej każdemu, kto zbyt mocno odbiega od głównego nurtu: to pierwszy taki przypadek w historii sztuki, i żadna ilość wolności oprogramowania nie czyni go mniej pełnym przemocy,
3. z marketingowego punktu widzenia tylko profesjonaliści potrzebują produktywności, a obecnie zdają się w większości preferować oprogramowanie komercyjne. Open source nie ma żadnej korzyści z „zdobywania nowych rynków", powinien raczej dążyć do pokrycia porzuconych nisz. A do tego fotografia profesjonalna powoli umiera od lat 80., więc nie jestem pewien, czy pozostanie znaczącym rynkiem na dużo dłużej.

To było długie wprowadzenie, ale w świecie, w którym każdy uważa, że może być projektantem, konieczne jest kompletne przedstawienie pełnej listy antagonistycznych wymagań projektowych, aby uspokoić tych, którzy sądzą, że są kolejnym Leonardem da Vinci, i uświadomić im, że prosty pomysł, który wpadł im do głowy, wydaje się genialny tylko dlatego, że nie mają pełnej specyfikacji. Miałem ich zbyt wielu w swojej skrzynce odbiorczej i w moich systemach śledzenia zgłoszeń.

Jak jest to rozwiązane w Ansel

Wszystkie zrzuty ekranu zostały wykonane na laptopie 15,6’’.

Prezentacja modułów globalnych

Przede wszystkim przypomnijmy, jak została przerobiona ogólna prezentacja ciemni:

• zakładki modułów dostały jawne nazwy zamiast tajemniczych ikon,
• zakładki są uporządkowane (zewnętrznie) w sugerowanej kolejności procesu pracy, od lewej do prawej, więc użytkownicy muszą po prostu podążać za interfejsem jak za przewodnikiem,
• wewnątrz zakładek moduły są uporządkowane w kolejności potoku (z logiką warstwy „nad", od dołu do góry), która jest również ogólnie zalecaną kolejnością procesu pracy. Nowa zakładka „podstawowa" jest wyjątkiem, mając sekcje modułów: wewnątrz sekcji moduły są uporządkowane potokowo, ale same sekcje są uporządkowane pod kątem procesu pracy (znów logika warstwy „nad", więc od dołu do góry),
• zakładka „potok" lub graf węzłowy kolejności modułów rozwiewa wszelkie wątpliwości i pokazuje bezpośredni widok węzłów potoku bez pośredniego porządkowania,
• zakładki „ulubione" zostały całkowicie usunięte, bo tylko udają, że rozwiązują przerost, dodając go więcej.

Tymczasem centralne paski narzędzi zostały całkowicie usunięte, uwalniając maksimum miejsca dla obrazów w orientacji pionowej, na ekranach 16:9 i 16:10, gdzie przestrzeń pionowa jest naprawdę cenniejsza niż pozioma. Użycie menu globalnego ponownie pozwoliło usunąć wiele dziwnych przycisków-ikon z pasków narzędzi i zastąpić je jawnymi, tekstowymi pozycjami menu. Zatem w trybie pełnoekranowym tracisz teraz tylko wysokość globalnego paska menu:

Opcje mieszania i maskowania, będąc ujednolicone między modułami, zostały przeniesione do lewego paska bocznego. Uwalnia to dużo przestrzeni pionowej dla modułów, zmniejszając potrzebę wewnętrznych zakładek i zapobiegając wielu klikaniom w tę i z powrotem. Zauważ, że opcje mieszania są obecnie przepisywane, po tym jak API masek zostało całkowicie przebudowane, uproszczone i rozszerzone, więc to tylko widok tymczasowy.

Widoki Ansel są dość rozwlekłe, więc aby pomóc odróżnić stały tekst (etykiety) od zmiennych (wartości), wprowadzono kolorowanie składni:

• etykiety stałych są białe,
• wartości zmiennych są pomarańczowe.

Kalibracja koloru

W kalibracji koloru 3 zakładki R, G i B zostały scalone w jedną zakładkę mikser, która teraz mieści się w całości w pionie. To samo dotyczy jasności, barwności i cz-b, które zostały scalone w wyjścia.

Zakładka mikser ma teraz 2 alternatywne tryby GUI, oprócz typowego (nazwanego teraz pełnym) ;

Widok barw podstawowych trafił do Darktable’a wcześniej w potoku, tyle że zrobili z niego samodzielny moduł, co jest głupie : wewnętrzna matematyka pikseli to dokładnie mnożenie przez macierz 3×3, czyli dokładnie to, czym jest też kalibracja koloru, więc nie było potrzeby tworzenia dodatkowego modułu. To znów problem rozwiązany w niewłaściwej warstwie : potrzebna była dodatkowa warstwa GUI w istniejącym module, a oni zrobili z tego zdublowany moduł.

Zamiast tego Ansel implementuje to jako warstwę GUI, co oznacza, że typowe parametry miksera kanałów są konwertowane tam i z powrotem na parametry widoku barw podstawowych, a matematyka pikseli w module nie zmieniła się od 2021 roku. Aby transformacja z macierzy 3×3 do widoku barw podstawowych była w pełni odwracalna, trzeba było dodać dodatkowy parametr wzmocnienia, który matematycznie domyka transformację.

Widok prosty to coś, co odkładałem na później przez kilka lat : ponowne wyrażenie nieprzyjaznych dla użytkownika parametrów miksera w kategoriach obrotu odcienia, rozciągania płaszczyzny chromy (kontrast barwny) i achromatycznego skalowania. Rozciąganie U/V zastępuje starszy moduł Darktable’a kontrast barwny , który działa w CIE Lab 1976 i ściska/rozciąga chromatyczność a oraz b. Widok prosty idzie dalej i pozwala Ci zdefiniować własną przestrzeń chromatyczności uv za pomocą obrotu osi chromy (uv) : gdy ustawiony na 0°, u jest osią zielono-magentową, a v osią niebiesko-żółtą (podobnie do kontrastu barwnego). Ale potem możesz obrócić ją tak, jak potrzebujesz, na przykład wokół -20° oś v staje się dość bliska osi temperatury barwowej, a oś u prostopadłej osi tinty. Odsyłam Cię do dokumentacji.

Ten tryb szczególnie dobrze nadaje się do odzyskiwania przytłaczających niebieskich świateł scenicznych, znacznie łatwiej niż za pomocą typowego interfejsu miksera kanałów :

After

Before

1. poprzez ściśnięcie osi V mocno ściskamy gamut na osi niebiesko-żółtej, co jest znacznie łagodniejsze dla reszty gamutu niż użycie globalnej kompresji chromy,
2. poprzez ściśnięcie osi U ściskamy gamut również na osi magentowo-zielonej, ale znacznie łagodniej,
3. odcień sprzężenia achromatycznego jest ustawiony na głęboki niebieski. Zwiększając siłę sprzężenia, przenosimy część niebieskiego na oś achromatyczną, co oznacza, że jednocześnie go odsycamy i rozjaśniamy, co bardzo pomaga sprowadzić go z powrotem do gamutu, zachowując jednocześnie ogólne wrażenie niebieskiego. I odwrotnie, kolor dopełniający zostaje przyciemniony i ponownie nasycony, ale ponieważ tym kolorem przeciwstawnym jest żółty, a oś żółto-niebieską ściśnęliśmy poprzez V, kończymy mniej więcej w tym samym miejscu.

Tak więc ten prosty zapis współrzędnych parametrów miksera kanałów daje 6 kontrolek zamiast 9, a są one o wiele bardziej znaczące i łatwiejsze w kontroli. To problem UX, który został rozwiązany wyłącznie od strony matematycznej, ponieważ jest to nic innego jak ponowne wyrażenie macierzy 3×3 w nowej ortogonalnej bazie wektorów własnych, obróconej na achromatycznej osi RGB, co oznacza, że zaczęło się to czysto z intuicji algebry liniowej. Dzięki właściwościom tej nowej bazy wektorów własnych (które są narzucone przez projekt) mogłem usunąć wymiary i zamienić pozostałe w bardziej znaczące kontrolki. To właśnie mam na myśli, gdy powtarzam, że problemów UX nie da się rozwiązać, jedynie patrząc na GUI.

Tonowanie rozdzielcze RGB

Starszy moduł tonowania rozdzielczego  Darktable’a działał w przestrzeni HSL, która nie obsługuje wartości kodu RGB większych niż 1 (a więc żadnego odniesienia do sceny). Poza tym mieszanie kolorów w HSL jest dziwaczne i sprawia wrażenie zabawkowych filtrów, gdy zaczynasz zwiększać ustawienia.

Jednocześnie obecny schemat adaptacji chromatycznej w Anselu zakłada pojedynczy iluminant. Jednak rzeczywiste sceny zawsze mają co najmniej dwa iluminanty :

1. główne źródło światła, które jest iluminantem pierwotnym i będzie głównie oddziaływać na światła i tony średnie,
2. kolorowe powierzchnie odbijające światło z głównego źródła i zabarwiające je, które działają jako iluminanty wtórne i będą głównie oddziaływać na cienie aż do tonów średnich.

Dotychczas, aby poradzić sobie z tą sytuacją mieszanych iluminantów, trzeba było duplikować instancje kalibracji koloru i maskować je do środka/na zewnątrz. Ale próba wycięcia binarnej maski (jeden obszar przypisany do jednego iluminantu, a reszta do drugiego) jest krucha, ponieważ nie uwzględnia mieszania światła zachodzącego wokół tonów średnich.

Nowy moduł tonowania rozdzielczego w Anselu oferuje zatem dwa miksery kanałów i dwie korekcje temperatury barwowej oraz duplikuje nowe tryby GUI z kalibracji koloru. Pozwala Ci zdefiniować jasność każdego iluminantu, przypisuje jedną macierz koloru do każdego z nich i oblicza mieszankę obu macierzy, którą stosuje do każdego piksela w zależności od jego luminancji.

After

Before

W tym momencie możesz pomyśleć, że mam obsesję na punkcie fotografii koncertowej, ale to tylko dlatego, że światła sceniczne to najbardziej wymagająca konfiguracja i nie wybaczają żadnego błędu w potoku koloru. To były nierozwiązane problemy przez dziesięciolecia; niebieskie światła znane były z tego, że rozpadają się na magentę, i stanowią ostateczny wzorzec testowy koloru.

Tutaj dopasowaliśmy temperaturę świateł, aby uzyskać bardziej naturalne tony skóry, zachowując jednocześnie ogólne niebieskie otoczenie w cieniach. W takiej scenie nie ma bieli, którą można by próbkować, więc jedynym drogowskazem jest dążenie do naturalnych tonów skóry. Następnie robisz, co w Twojej mocy, aby zachować ducha oświetlenia scenicznego (utrzymać niebieski niebieskim), pamiętając o granicach swojego gamutu RGB. Więcej szczegółów znajdziesz w dokumentacji.

Barwy podstawowe koloru

Jak wspomniałem wcześniej, moduł barw podstawowych w Darktable jest zaledwie duplikatem miksera kanałów z innym interfejsem. Ale zdarzają się przypadki, gdy przekształcanie całej przestrzeni barwnej przez jej barwy podstawowe zbyt mocno psuje zakres niskiego nasycenia, który był całkowicie poprawny. Zaistniała więc potrzeba wpływania na kolory podstawowe i drugorzędne (w wierzchołkach sześcianu gamutu) w sposób, który wykluczał środek gamutu, ale wciąż płynnie mieszał efekty pomiędzy oboma obszarami i zachowywał gradienty obrazu.

Osiągnięto to, budując tablicę LUT RGB w nowym module : barwy podstawowe koloru.

After

Before

Ten przykład został zaprojektowany tak, aby czerwony i pomarańczowy były mniej przytłaczające, ale dramatycznie pogłębić niebieskie, aby pokazać, jak stabilna jest transformacja koloru wzdłuż krawędzi między powierzchniami o różnych kolorach.

Ponieważ wewnętrznie moduł dynamicznie buduje LUT poprzez przesuwanie koloru węzłów kontrolnych, użytkownicy zyskują możliwość decydowania, jak daleko od wierzchołków sześcianu RGB znajdują się węzły kontrolne, za pomocą suwaka pokrycia gamutu. Następnie 3 parametry wygładzania pozwalają mocniej lub słabiej mieszać przesunięcia kolorów w RGB oraz mocniej lub słabiej chronić kolory neutralne przed przesunięciem. Wreszcie moduł ma podgląd LUT 3D:

Podgląd LUT pokazuje przesunięcia kolorów w całym sześcianie RGB od punktu wyjścia do punktu docelowego. Można go obracać wokół osi achromatycznej (azymut) lub ustawić w widoku płaszczyzny chromatyczności (nachylenie osi = 90°). Można go przybliżać, przesuwać i obracać w 3D za pomocą myszy oraz przekrawać, aby uzyskać lepszy widok na określonej głębokości. Wreszcie wygenerowaną tablicę LUT 3D można wyeksportować do pliku cLUT .cube, aby użyć jej ponownie w dowolnym oprogramowaniu, które je obsługuje. Więcej szczegółów znajdziesz w dokumentacji.

Korektor koloru

Darktable’owy „zespół" wziął mój drugi (niedziałający) prototyp  korektora koloru, nie zrozumiał, dlaczego nie działa, dodał etapy filtrowania końcowego, aby ukryć problemy, i wydał go, jakby to była ich własna praca, nawet mnie nie wymieniając. Mogą go sobie zatrzymać : to gówno. A ja i tak nie podpisuję się pod gównem.

Widzisz, problem tego prototypu polega na tym, że stosował przesunięcie nasycenia w przestrzeni barwnej dt UCS 22 HSB, którą zaprojektowałem w 2021 roku . Ta przestrzeń barwna jest już używana w balansie kolorów RGB do nasycenia i miała na celu znalezienie odpowiedniej ilości przyciemnienia, jakie należy zastosować do koloru przy zwiększaniu jego „nasycenia" (właściwie jego chromy, w rygorystycznych terminach nauki o kolorze), aby uniknąć zdegradowania do nienaturalnych kolorów fluo i neonowych, które są typowymi pułapkami przy dodawaniu dużej ilości „nasycenia". Tak więc zamiast typowego ustawienia chromy, które redukuje barwność przy stałej luminancji lub jasności, ta formuła nasycenia również przyciemnia. I choć działa to bardzo dobrze na płaskich polach koloru, problem w tym, że obrazy nie są płaskimi kolorowymi powierzchniami, lecz mają gradienty.

Około 2022 roku zgłoszono mi, że nasycenie dt UCS HSB w balansie kolorów RGB tworzyło dziwną achromatyczną jasną obwódkę między jasnymi, nasyconymi żółtymi jesiennymi liśćmi a głębokim niebieskim niebem za nimi. Problem polegał na tym, że na krawędzi żółte światło z liści i niebieskie światło z nieba mieszały się w achromatyczne (jak powinny, będąc kolorami dopełniającymi) z powodu lekko miękkiego obiektywu lub atmosferycznej mgły. Algorytm nasycenia przyciemniał żółty i niebieski po obu stronach achromatycznej obwódki, ale nie samą obwódkę, która teraz wyróżniała się jaśniej. I nie ma na to poprawki; to nie jest błąd algorytmiczny: problemem jest model koloru, który uwzględnia percepcję, ale nie mieszanie światła. Byłem więc kolejnym autorem kolejnej wadliwej przestrzeni barwnej, której opracowanie zajęło mi miesiące, a numeryczne dopasowanie parametrów modelu — 20 godzin obliczeń.

Próba zaimplementowania korektora koloru z ponownym wykorzystaniem tej samej przestrzeni barwnej jeszcze bardziej pogorszyła te problemy, ponieważ teraz efekt był sterowany według odcienia, co oznaczało problemy w dwóch wymiarach zamiast w jednym. Aby złagodzić problem, próbowałem wygładzić rzeczy za pomocą filtrów sterowanych RGB. Ale nie udało mi się do końca znaleźć magicznej formuły na właściwe, odporne mieszanie. Wtedy właśnie zespół Darktable postanowił zgarnąć błyszczącą nowość z półki, i wtedy zrozumiałem, że może się to udać tylko w RGB, jeśli ma mieszać się prawidłowo i zachowywać gradienty.

After

Before

Korektor koloru dziedziczy ten sam interaktywny kursor co korektor tonalny, umożliwiając bezpośrednią edycję na obrazie poprzez próbkowanie odcienia piksela pod kursorem, a przewijanie automatycznie aktualizuje wykres. Węzły można swobodnie dodawać w dowolnym miejscu, a z poziomu interaktywnego kursora dodanie węzła przy bieżącym odcieniu odbywa się kliknięciem prawym przyciskiem.

Korektor koloru pozwala zdefiniować przesunięcie koloru według odcienia dla cieni, tonów średnich i świateł. Próbnik koloru pozwala zobaczyć, gdzie dany obszar plasuje się pomiędzy kontrolkami tonalnymi. Umożliwia to bardzo precyzyjną kontrolę, która wraz z tym samym wygładzaniem 3D co w barwach podstawowych koloru zapewnia bardzo odporny sposób mieszania przesunięć kolorów. Szum chromy, który był głównym problemem przy definiowaniu dramatycznych przesunięć kolorów w starszych strefach koloru Darktable’a (działających w CIE Lab 1976) lub w poprzednim prototypie korektora koloru, już się nie pojawia.

Podobnie jak w barwach podstawowych koloru, ten moduł dynamicznie tworzy tablicę LUT RGB 3D, którą można podglądać i zapisywać do plików .cube dokładnie tak samo. Więcej szczegółów znajdziesz w dokumentacji.

Rysowanie

Czy muszę mówić coś więcej ?

Ansel implementuje teraz prototypowy moduł rysowania, który pozwala Ci rysować obrazy rastrowe w potoku odniesionym do sceny za pomocą 32-bitowych pędzli obsługujących kolory HDR (>100%). Pędzle obsługują krycie i przepływ (tak samo jak w Photoshopie), losowe rozpryski, wygładzanie ścieżki, cieniowanie krawędzi i mogą być używane w trybach malowania, wymazywania, rozmazywania i rozmywania. Rozmiar pędzla, krycie, przepływ i twardość można zmapować na nacisk i pochylenie pióra Wacom lub na ogólne przyspieszenie kursora. Używają prawidłowej wstępnie zwielokrotnionej alfy i zapisują warstwy do 16-bitowych zmiennoprzecinkowych plików pomocniczych TIFF, które można edytować w większości popularnych aplikacji do rysowania.

Można używać kilku warstw, tworząc wiele instancji modułu rysowania i komponując je z obrazem za pomocą ogólnych opcji mieszania i maskowania Ansela. Można go również używać do komponowania dowolnego rodzaju warstwy pochodzącej z dowolnego oprogramowania, o ile jest zapisana jako 16-bitowa zmiennoprzecinkowa warstwa w pliku pomocniczym TIFF Ansela. Obraz tła (sprzed modułu) można wyeksportować jako warstwę tła, jeśli potrzebujesz obrazu referencyjnego do rysowania w innym oprogramowaniu i zaimportowania wyniku z powrotem.

Umożliwiła to nowa architektura potoku, która wprowadziła tryb czasu rzeczywistego. Wprawdzie wciąż nie jest to tak szybkie jak Photoshop, ponieważ przy każdym odświeżeniu pociągnięcia pędzla działają inne moduły uruchamiane po rysowaniu w potoku.

To najwyższa wolność osiągnięcia wszystkiego tego, czego przyciski i suwaki nigdy Ci nie dadzą, czy to rozjaśnianie i przyciemnianie, naprawianie uszkodzonych fragmentów (przyciętych świateł, brakujących obszarów), czy po prostu łączenie fotografii i malarstwa. Więcej szczegółów znajdziesz w dokumentacji.

Ziarno fotograficzne

Starszy moduł ziarna Darktable’a był naprawdę niezadowalający, ponieważ pozwalał jedynie na ziarno luminancji i był stosowany na kanale jasności przestrzeni barwnej CIE Lab 1976. Wyniki były dziwne, w żaden sposób nie odpowiadając halogenkom srebra. W końcu zaimplementowałem stochastyczną syntezę ziarna , którą opracowałem w 2023 roku, w nowym module: ziarno fotograficzne. Dzieli on pole świetlne na wirtualne kryształy halogenków srebra i symuluje ziarniste elementy światłoczułe ułożone warstwami. Działa zarówno dla ziarna cz-b, jak i kolorowego, choć musiałem nieco odejść od mojego pierwotnego artykułu, aby obsłużyć kolor.

After

Before

After

Before

Filmic

Przez kilka lat ludzie mówili mi, że głupie moduły Darktable’a sigmoid i nowszy AgX dają im nieco więcej kontroli. I żaden z nich nie potrafił dokładnie powiedzieć, kontroli nad czym. Zajęło mi więc dużo czasu, żeby to rozgryźć.

Sigmoid i AgX nie są rewolucjami, to kolejne filmiki :

1. konwertujesz kolory za pomocą kształtownika logarytmicznego lub potęgowego,
2. nakładasz na wierzch jakąś krzywą w kształcie litery S,
3. następnie robisz, co w Twojej mocy, aby odjebać to, co krzywa tonalna wyprawiała z chromą podczas całego procesu,
4. i wreszcie cofasz kształtownik.

Sigmoid i AgX mogły być alternatywnymi trybami wewnątrz filmica : wszystkie przechodzą przez te same etapy z nieco innymi priorytetami i strategiami. Zapewniłoby to jeden jedyny moduł do kompresji zakresu dynamiki, z różnymi trybami w zależności od tego, jak precyzyjnej kontroli chcieli użytkownicy. Zamiast tego zduplikowali funkcjonalność i dodali balast GUI, więc użytkownicy muszą teraz wybierać między krzywą bazową (która sama była już zduplikowanym i wyspecjalizowanym wariantem krzywej tonalnej), filmic, sigmoid i AgX, aby osiągnąć to samo zadanie, przy czym żaden z nich faktycznie nie określa funkcjonalności, którą zapewnia.

Jedyną rzeczą, którą filmic robi najlepiej, jest jawne obsługiwanie granic zakresu dynamiki, co pozwala używać go do kompensacji punktu czerni przy drukowaniu. Dwa pozostałe traktują je jako produkt uboczny ustawienia kontrastu. Ponieważ twórcy dwóch pozostałych nie dbają o wydruki, możesz się założyć, że to zdejmuje pewne ograniczenia z projektu i usuwa kilka suwaków z GUI. Jedyną rzeczą, którą dwa pozostałe robią lepiej, jest zapewnienie ręcznych kontrolek koloru do odjebania problemów z nasyceniem i przesunięciem odcienia przez mapowanie tonalne, ale naprawdę nie sądzę, żeby taki poziom szczegółowości koloru należał do funkcji mapowania tonalnego : to całkowicie wadliwy podział przepływu pracy i funkcji.

Tak czy inaczej, w końcu zorientowałem się, że subtelniejsza kontrola kontrastu brała się z faktu, że sigmoid bezpośrednio zapewnia kontrolę węzłów palca i barku, podczas gdy filmic używa globalnej szerokości naświetlania i przesunięcia, które są kłopotliwe w użyciu, ponieważ wiążą oba ze sobą. Zostało to pierwotnie zaprojektowane tak, aby mapować to na rzeczywiste karty katalogowe materiałów filmowych, ponieważ szerokość naświetlania to prawdziwa filmowa rzecz, aby może kiedyś emulować prawdziwe materiały filmowe. Ten dzień nigdy nie nadszedł.

Rozwiązałem więc problem w warstwie GUI, dodając konwersję między ustawieniami szerokości naświetlania/przesunięcia a świateł/cieni, i teraz filmic RGB pozwala Ci bezpośrednio manipulować położeniem węzłów palca/barku :

W tym procesie nie zmieniono żadnej matematyki pikseli, parametry modułu są wciąż takie same jak wcześniej, nie utworzono żadnego nowego modułu, to tylko pośredni etap konwersji GUI.

Podsumowanie

Wszystkie nowe moduły obsługują odciążanie GPU poprzez OpenCL. Zostały zaprojektowane z myślą o odporności i sądzę, że ten cel został osiągnięty. Zastąpiły gorsze poprzednie moduły, działające w CIE Lab 1976, które od dawna pokazywały swoje ograniczenia i wady. W Anselu masz teraz pełny potok RGB. Starsze moduły wciąż są w programie i wciąż będą działać dla starych edycji. Ponadto kolorowe suwaki i wykresy odcieni są zarządzane kolorystycznie przy użyciu profilu koloru wyświetlacza.

Moduły, które ostatnio wprowadziłem, nie są błyszczącymi nowymi zabawkami, którymi można się ekscytować. Są zwieńczeniem lat rozmyślań nad spójnym, koherentnym podziałem funkcji, który wspiera przepływ pracy odniesiony do sceny. Ten przepływ pracy odniesiony do sceny jest bardziej złożony niż poprzedni odniesiony do wyświetlacza, choćby dlatego, że musimy znormalizować „biel" przed wejściem do jakiegokolwiek LUT lub percepcyjnej przestrzeni barwnej, ale to jedyny sposób, aby poradzić sobie z obrazami HDR, prawidłowym mieszaniem alfa dla masek i fizycznie dokładnymi filtrami pikseli, które symulują mieszanie światła. Fizycznie dokładne filtry są odporne i dają organiczne rezultaty, nawet doprowadzone do dramatycznych ustawień. Ale często są mniej dostępne dla nowicjuszy i niepokojące dla doświadczonych retuszerów przyzwyczajonych do Lightrooma i im podobnych.

To będzie mój ostatni wpis na tej stronie, ponieważ wycofuję się z programowania. Kosztowało mnie to zbyt wiele : zbyt wiele stresu, zbyt wiele wypaleń, zbyt wiele lat spędzonych na naprawianiu cudzego gówna i cierpieniu z powodu ich złych decyzji. Jestem zmęczony ponad to, co możesz sobie wyobrazić. Nienawidzę programowania i nienawidzę programistów. Znam bardzo niewielu z nich, którzy programują, aby budować rzeczy lub rozwiązywać problemy, większość po prostu zbyt lubi spędzać miło czas z komputerem i zamienia się w strażaków-piromanów, którym nie można zaufać przy projektowaniu rzeczy. Nienawidzę technologii i tak zwanej „innowacji": to wszystko tylko kapitalistyczny przekręt zaprojektowany dla nieskończonego wzrostu w świecie, w którym zasoby są ograniczone, a udajemy, że rozwiązujemy problemy stworzone przez technologię jeszcze większą ilością technologii. To szaleństwo. Świat open-source dziedziczy ten sam sposób myślenia, w tym technosolucjonizm , ponieważ taki właśnie gnijący mózg produkuje 350 lat kapitalizmu, choć FLOSS nie ma zysków, by to usprawiedliwić. Jest pełen kłamstw i pełen gówna, ponieważ libre oznacza wolność tylko dla inżynierów, a użytkownicy mogą iść do diabła. Problem w tym, że kiedyś wierzyłem w te kłamstwa, w te wartości : były (i wciąż są) moje. Ale uświadomienie sobie, że to tylko puste słowa powtarzane w toksycznych „społecznościach" białych mężczyzn w średnim wieku z tytułami inżyniera, magistra i doktora, było brutalnym otrzeźwieniem. Co właściwie robimy, aby wzmocnić użytkowników, którzy naprawdę tego potrzebują ? W którym momencie beztroskie wymaganie korzystania z wiersza poleceń wzmacnia kogokolwiek, kto nie umie czytać kodu ? Przyczyniamy się tylko do pogłębiania przepaści między elitami znającymi się na komputerach a chłopstwem. Pamiętaj, robimy tu oprogramowanie do fotografii, a nie bibliotekę backendową, nie infrastrukturę serwerową, lecz aplikację desktopową dla użytkownika końcowego.

Opróżniłem tu swój mózg, aby zapisać wszystko, czego nauczyłem się o projektowaniu przetwarzania obrazu, jak to zrobiłem i dlaczego. Ważne jest, aby zrozumieć, że użytkownicy, i większość programistów, wiedzą tylko, jak jedna aplikacja zachowuje się na ich własnych obrazach. Przez 8 lat otrzymywałem wiele patologicznych obrazów, które ludzie mi przysyłali, pokazując wady i ograniczenia narzędzi. Mam w tej chwili około 45 GB takich obrazów na swoim dysku twardym. To daje zupełnie inną perspektywę na rzeczywiste problemy niż ta, którą mogą mieć wszyscy zadowoleni turyści : jestem gościem, który wie, co się psuje i kiedy. Jestem gościem, którego znajdują problemy. Jestem projektową Kasandrą . I irytujące jest ciągłe uzasadnianie ludziom, którzy nie widzą problemów, dlaczego ta rzecz, która mogłaby być o wiele prostsza nie może być o wiele prostsza, ponieważ istnieją patologiczne przypadki, w których musimy dostosować się do zmienności danych wejściowych. Aby dostosować się do zmienności danych wejściowych, potrzebujesz parametrów użytkownika zamiast zakodowanych na stałe stałych. Stąd balast GUI. Rodzaj balastu GUI, którego nie da się uniknąć bez szkody dla użyteczności.

Nie da się ocenić jakości projektu, jeśli nie znasz jego wymagań. „Mnie się podoba" lub „mnie się nie podoba" jest nieistotne. Nikt nie lubi zapinać pasów bezpieczeństwa, a i tak to dobry projekt, jeśli weźmiesz pod uwagę, ile istnień uratował. Jakakolwiek prawdziwa krytyka może dotyczyć tylko tego, jak proponowane rozwiązanie osiągnęło cel, co może nastąpić tylko wtedy, gdy znasz cel. W przetwarzaniu obrazu mieszana natura wymagań utrudnia uniknięcie zanurzenia się w pewnym momencie w matematykę i jej hieroglify, i to właśnie tam gubisz ludzi. Ale to i tak nie powstrzymuje ich od wyrażania swojej bezużytecznej opinii, zaczynając od „nie jestem programistą"/„nie jestem matematykiem"/„nie jestem naukowcem od koloru"… „ALE"… [tu jakiś losowy szum mózgowy]. Robienie kodu open-source, gdzie wszystko jest publiczne, dopuszcza tego rodzaju szum wszędzie : jest to naprawdę męczące i wielokrotnie żałowałem, że źródło nie jest zamknięte, żeby móc pracować w spokoju. Większość z tych facetów ma dobre intencje i po prostu chce być częścią czegoś, ale przyczynianie się do przeciążenia informacyjnego nie pomaga i tylko przyczynia się do tworzenia zmęczenia. Komunikacja to miejsce, gdzie każda praca zespołowa traci produktywność

Projektowanie nie polega na słuchaniu tego, co ludzie lubią. Jeśli 65% Twojego panelu testowego lubi tekst pisany na czerwono, a 72% lubi tekst pisany na czerwonym tle, to czy piszesz czerwony tekst na czerwonym tle ? To nie ma sensu. Nie uprawiamy polityki i nie próbujemy zadowolić wyborców podczas kampanii, szukamy długoterminowych/odpornych na przyszłość rozwiązań problemów. Projektowanie polega na słuchaniu tego, czego ludzie potrzebują, co rzadko potrafią jasno wyrazić, i znajdowaniu sposobów, aby sfaktoryzować te potrzeby. Więc jedyne statystyki warte obliczania dotyczą przypadków użycia : jak oprogramowanie jest używane, jakie są najczęstsze punkty bólu i jaka jest ich przyczyna źródłowa. Następnie napraw przyczynę źródłową, która może być daleko od faktycznego objawu problemu. To też jest prawdziwa i cenna umiejętność : podążanie za nitką problemu, poprzez wskazówki i tropy, aby odkryć prawdziwe źródło, a nie tylko załatać końcowy problem lub go obejść. „Słuchanie użytkowników" nie oznacza słuchania każdego pojedynczego człowieka i dawania mu tego, czego indywidualnie chce : nie prowadzimy terapii. Oznacza słuchanie całej bazy użytkowników i identyfikowanie wspólnie podzielanych potrzeb i punktów bólu, aby wymyślić sfaktoryzowane rozwiązanie, które pokryje najwięcej potrzeb przy najmniejszej ilości technologii. Nie oznacza to odrzucania kogokolwiek, kto odbiega od średniej o więcej niż odchylenie standardowe, ale ci ludzie mogą być zmuszeni uciekać się do metod, które nie są skrojone na miarę i zoptymalizowane pod ich potrzeby.

Projektowanie nie istnieje na bezludnej wyspie : dookoła są inne aplikacje do edycji obrazu. Znów trudno jest ocenić, kiedy Twój projekt powinien kopiować inne, ponieważ użytkownicy będą przyzwyczajeni do ich semantyki interfejsu, a kiedy powinieneś się od nich oddalić, ponieważ problem, który próbujesz rozwiązać, jest zbyt różny od tego, co robi konkurencja, lub Twój typowy użytkownik jest zbyt różny. Open-source jest nieustannie rozdarty między pokusą skopiowania 1:1 komercyjnych liderów, których tak bardzo nienawidzi (ale po cichu aspiruje, by nimi być), a pragnieniem przechytrzenia wszystkich przy jednoczesnym wynajdywaniu koła na nowo (często w gorszy sposób). W tym wszystkim Twoją Gwiazdą Polarną jest zadawanie sobie pytania, co godzinę każdego dnia : jaki problem próbujemy rozwiązać i kim są ludzie, którzy się z nim mierzą ? W ten sposób możesz dostosować rzeczy do swojej publiczności, zamiast wpadać w kulty cargo  i przyjmować rozwiązania tylko dlatego, że okazały się skuteczne w kontekście, którego tak naprawdę nie rozumiesz i który niekoniecznie jest Twój.

Moim głównym wnioskiem ze wszystkich tych lat jest to, że stosowanie transformacji koloru do pikseli w jakiejkolwiek innej przestrzeni niż RGB jest skazane na porażkę, jak pokazuje przykład colorbalance RGB : choć może to brzmieć jak świetny pomysł, aby odseparować pracę nad „kolorem" (jako odcień/chroma) od pracy tonalnej, zawsze będzie to tylko kwestia wyboru swojego bólu. Zwiększanie chromy przy stałej jasności degraduje kolory do fluo, zwiększanie nasycenia przy stałej jasności (a więc przyciemniając w całości) nie respektuje teorii mieszania światła, a oba wytwarzają szum chromy z powodu niestabilnej natury kątów odcienia. Ale z drugiej strony RGB nie jest percepcyjnie równomierne, a zielonkawy zakres jakiejkolwiek skali odcienia HSL/HSV zajmuje mniej więcej 30 % przestrzeni, podczas gdy zielony to tylko 1/6 percepcyjnego pierścienia odcieni. Jedynym rozwiązaniem jest obsługa GUI w percepcyjnych modelach koloru i konwersja, w taki czy inny sposób, do RGB przed zastosowaniem do pikseli. Co wymaga od programistów dodatkowej gimnastyki abstrakcji. A to wyraźnie nie jest ich mocna strona, ponieważ poziom matematyki jest dość niski.

Mam już następcę, ale przyszłością Ansela będzie musiała być spółdzielnia, w której użytkownicy gwarantują programistom uczciwe warunki pracy, a programiści gwarantują użytkownikom, że ich potrzeby będą pokryte, wzajemnie odwzajemniając obowiązki. Nie możemy tak dalej, to niezdrowe. A przez „tak" mam na myśli z jednej strony „programistę-hobbystę" z zerową odpowiedzialnością, a z drugiej wypalającego się jedynego dewelopera żyjącego poniżej progu ubóstwa, żeby jakoś sprawić, by coś się działo. Ten paradygmat dostarczył wszystko, co mógł, nie da się go podrasować. Te same przyczyny doprowadzą tylko do konsekwencji, które już znamy : open-source jest do dupy. Jeśli chcesz więcej, ten paradygmat będzie musiał się zmienić. Open-source z jednej strony jest dyktaturą programistów (tych, którzy wiedzą i mogą) nad użytkownikami (tymi, którzy potrzebują), ale z drugiej strony jest wyzyskiem tych, którzy pracują, przez tych, którzy biorą. To tylko karmi wzajemną urazę, ciche pogardzanie i protekcjonalność. Wszyscy tracą.

Alternatywą jest obecne zgównienie korporacyjnych platform i technofaszyzm, który obecnie umożliwia. Zostałeś ostrzeżony.