O wyższości trybu 16-bitowego nad 8-bitowym

Wady trybu 16-bitowego

Tak, tak, to nie pomyłka! Tryb 16-bitowy ma swoje wady. W losowej kolejności:

• Duże pliki -- obrazek w trybie 16-biowym bez kompresji zajmuje dwa razy więcej miejsca na dysku, niż jego 8-bitowy odpowiednik. Pamięci też potrzebuje dwa razy więcej. Jednak po zastosowaniu kompresji (plik PSD) może zdarzyć się, że plik 16-bitowy będzie zajmował mniej miejsca niż 8-bitowy (będzie o tym wpis)! W przypadku formatu TIFF z kompresją LZW lub ZIP -- nie testowałem, ale tu powinno obyć się bez niespodzianek.
• Wolno się zapisuje -- zdjęcie + dużo warstw w trybie 16-bitowym potrafi zapisywać się nawet 20 sekund. W 8-bitach -- około 2-3. Dlaczego tak wolno -- prawdopodobnie przez inny algorytm kompresji. To może tłumaczyć niespodziankę z rozmiarami plików, o której pisałem wyżej.
• Dużo filtrów nie działa -- ale najważniejsze sprawnie funkcjonują :) A nawet jeśli chcemy użyć jakiegoś filtru dostępnego tylko w 8-bitach, to możemy -- na kopii zdjęcia (będzie o tym wpis). Komercyjne filtry od onOne Software i Nik Software działają w 16-bitach bardzo dobrze!
• Pewnie jeszcze coś by się znalazło -- możecie pisać w komentarzach :)

Zobacz zalety na własne oczy

Proponuję prosty eksperyment z histogramem. Należy go wykonać na pliku w trybie 8-bitowym oraz na tym samym 8-bitowym pliku po skonwertowaniu go na tryb 16-bitowy. Eksperyment przeprowadzimy bez użycia warstw, za pomocą polecenia "Image>Adjustments>Levels...". Najpierw ustawimy poziomy wyjściowe na 253 dla czarnego i 255 dla białego, zachowując poziomy wejściowe na 0..255, klikamy OK. W ten sposób "ścisnęliśmy" całą tonalność obrazka do dwóch działek jasności. Następnie robimy operację odwrotną: znów otwieramy poziomy (Levels), ale tym razem zmieniamy poziomy wejściowe na 253 dla czarnego, 255 dla białego, poziomy wyjściowe pozostawiamy bez zmian: 0/255. Wyniki eksperymentu widać na poniższym rysunku.

A jak oczom nie wierzysz to sobie policz

Z teoretycznego punktu widzenia, w trybie 16-bitowym mamy 256^3=16 777 216 razy więcej kolorów! Znaczek ^ należy rozumieć jako "do potęgi". Uwaga: razy więcej!

Policzmy sami. W trybie 8-bitowym, każdy z kanałów RGB może przyjmować wartości od 0 do 255. Czyli w sumie 256=2^8 różnych wartości. Ile można z tego stworzyć kolorów? Liczby w nawiasach oznaczają wartości dla kanału czerwonego, zielonego i niebieskiego. (34,54,134) oznacza czarwony=34, zielony=54, niebieski=134, czyli taki kolor    . Prześledźmy schemat: (0,0,0), (0,0,1), ..., (0,0,255), (0,1,0), ..., (0,1,255), ..., (0,2,0), ..., (255, 255, 255). Zauważmy, że dla każdej wartości koloru zielonego jest 256 różnych wartości kolory niebieskiego. Różnych wartości koloru zielonego jest też 256. Podobnie jest z niebieskim. Mamy więc 256*256*256=256^3=2^8^3=2^24=16 777 216 kolorów, znane również pod pojęciem "24-bitowy kolor" lub "16 milionów kolorów".
Przeprowadźmy teraz analogiczne rachunki dla 16-bitów na kanał. Jeden kanał może przyjmować 2^16=65 536 wartości. Przy trzech kanałach daje to 65536^3=2^16^3=2^48=281 474 976 710 656, czyli 281 bilionów kolorów (w USA powiedzieliby 281 trylionów).

• O ile kolorów jest więcej w trybie 16-bitowym w odniesieniu do trybu 8-bitowego: 2^48-2^24=281 474 959 933 440. Chwila... znów 281 bilionów? Ach -- różnica jest na poziomie milionów ;)
• Ile razy jest więcej kolorów w trybie 16-bitowym w odniesieniu do trybu 8-bitowego:
  2^48/2^24=2^(48-24)=16777216 razy więcej.

Podsumowanie

Jeśli nie chcesz tracić odcieni operując na krzywych, poziomach i innych filtrach zawsze pracuj w trybie 16-bitowym.

Jak nie zepsuć rozpiętości tonalnej zdjęcia

Lightroom czy Camera RAW?

Napiszę krótko -- nie ma najmniejszej różnicy. Oba te programy używają tego samego silnika do wywoływania zdjęć. Różnią się tylko front-endem, czyli tym, co widzi użytkownik. Wszelkie dyskusje na temat przewagi jednego nad drugim z punktu widzenia jakości zdjęć są bezcelowe. Jak to potwierdzić? W Lightroomie wybierz Image▸Edit▸Open as Smart Object in Photoshop, czyli otwórz w photoshopie jako Smart Object.

Teraz, aby zmienić parametry "wywoływania", kliknijmy dwa razy na miniaturce jedynej warstwy na panelu warstw -- otwiera się Camera RAW!

IMHO Lightroom jest o wiele wygodniejszy od Camera Raw przy katalogowaniu zdjęć. Jest ładniejszy :) Jednak jeśli chodzi o "reaktywność", szybkość odzwierciedlania wprowadzonych zmian na miniaturkach, to zestaw Bridge+Camera Raw może mieć przewagę. Przynajmniej na mojej konfiguracji sprzętowej (Windows 7 64-bit, Intel Core 2 Duo 3,16@4,3 GHz, 8 GiB RAM). Moja rada -- przetestować na własnej skórze konfiguracji sprzętowej.

Ustawienia formatu wyjściowego

Zdecydowanie ustalamy 16-bitowe wyjście. Profil barwny wedle gustu. Ja mam ustawiony ProPhoto RGB. O zaletach i wadach różnych profili napisano już bardzo wiele. Od siebie dodam: jeśli nie masz PROFESJONALNEGO skalibrowanego szerokogamutowego monitora, odpowiedniego pomieszczenia edycyjnego (czarne ściany!), oświetlenie i kominiarki (żeby wyeliminować odbicia od skóry) -- nie przejmuj się tym wszystkim zbytnio ;)
Pracować możesz w szerokiej przestrzeni takiej jak Pro Photo. Na monitorze różnicy od sRGB i AdobeRGB raczej nie zauważysz. Na DOBRYM wydruku (takim za 150 zł / ~A3) -- całkiem możliwe, że różnica się pojawi.
Pamiętaj też, aby przed wrzuceniem zdjęć do Internetu skonwertować profil barwny na sRGB -- w innym wypadku, w niektórych przeglądarkach mogą pojawić się niemiłe niespodzianki kolorystyczne.
Oto jak ustawić to o czym pisałem wyżej we wspomnianych programach:

Niedoświetlanie

Większość zdjęć naświetlam na ok. -1 EV. Takie niedoświetlenie pomaga uratować szczegóły ze świateł. Cienie i tony średnie mogę "wyciągnąć" podczas obróbki. Rzecz jasna najlepiej by było, gdyby zdjęcia od razu naświetlać prawidłowo. W praktyce jednak trudno uniknąć błędów rzędu +/- 1 EV, szczególnie gdy zmieniają się warunki otoczenia (plener), a zdjęcia trzeba wykonywać szybko. Matryca w moim aparacie dobrze radzi sobie z wyciąganiem szczegółów nawet przy niedoświetleniu -2 EV. W przypadku innych body trzeba poeksperymentować. Niedoświetlanie o jedną działkę może okazać się za mocne.

Czarne i białe

W wielu poradnikach napisane jest, aby światła ustawić na ~253, cienie na ~5, czyli: aby białe było białe, i czarne -- czarne. Zasadę tę trzeba pamiętać... ale i tak robić po swojemu ;) Każde zdjęcie jest inne, ma inny charakter, inny klimat. Dostosujmy do tego poziom czerni i bieli. Nigdzie nie jest powiedziane, że na zdjęciu musi być jakikolwiek czarny lub biały punkt!
Jest jeszcze jedna rzecz, na którą warto zwrócić uwagę -- jasność skóry. Zazwyczaj nie warto ustawiać ekspozycji zdjęcia tak, aby na skórze występował kolor biały (jakkolwiek go zdefiniujemy, np. 253-255 na wszystkich kanałach RGB). Zwłaszcza, że operacje zwiększające kontrast jeszcze rozjaśnią najjaśniejsze miejsca.
Zgodnie z zone system, skóra powinna być w V, VI i VII strefie. Tłumaczy się to na wartości 132..213 dla kanału jasności w modelu LAB. Przekładając na oko: zaczynamy ciut poniżej średniej szarości 50%, kończymy na jasnej szarości 75%. W żadnym razie nie proponuję zachowań pixel-nazzi. Trzeba robić tak, aby wyglądało tak jak się chce. I już!

Czasem przydaje się podejrzeć na bieżąco jak rozkłada się jasność na zdjęciu. W tym celu stworzyłem "widget" do Photoshopa. Będzie o tym w innym poście :) Poniżej można zobaczyć jak działa:

Wywoływanie niedoświetlonych zdjęć

Można to robić używając (co najmniej) dwóch technik. Pierwsza z nich polega na zwiększeniu ekspozycji (Exposure) tak, aby na skórze prawie występowało prześwietlenie (czysty biały), a następnie obniżeniu jasności (Brightness) do sensownego poziomu (w okolicach 0).

Druga technika zakłada działanie odwrotne. Ustawiamy jasność (Brightness) na prawie-max, a następnie obniżamy ekspozycję (Exposure) wchodząc nawet na minus.

Pierwsza technika zachowuje dynamikę poniżej "ciemniejszych świateł". Niestety, w jasnych światłach straciliśmy detale -- prześwitujące przez drzewa światło zupełnie wypaliło drzewa. Problem ten rozwiązuje druga technika -- dobrze rozciąga jasne światła, uwydatniając szczegóły. Niestety, jednocześnie spłaszcza resztę zdjęcia -- widać to szczególnie na twarzy i rękach modelki.

Jak to naprawić? Globalne dodanie "recovery" do metody pierwszej daje rezultat gorszy niż zastosowanie metody drugiej. Opcji tej nie możemy niestety ustawić lokalnie za pomocą narzędzia Adjustment Brush. Możemy jednak w opcjach narzędzia ustawić prawie najmniejszą ekspozycję i największą jasność. Da to efekt zbliżony do metody #2.

Rozwiązanie to ma jednak poważną wadę -- jest czasochłonne! Każda niedokładność w maskowaniu będzie skutkowała stworzeniem ciemnej obwódki jasnego miejsca. Przydałby się w Lightroomie pędzel historii...

Myślę, że najszybciej jest: użyć metody 1, otworzyć w Photoshopie zdjęcie jako Smart Objcet, stworzyć kopię obiektu (Layer>Smart Object>New Smart Object via Copy), na kopii zastosować metodę 2, wymakować co trzeba i scalić.

Do pomyślenia

Chwila, chwila... Skoro RAWy są 12-14 bitowe, a wywoływane zdjęcie trafia do przestrzeni 16-bitowej, to nie powinniśmy stracić żadnych informacji! Niestety, tak się nie dzieje. Nawet jeśli wywołamy zdjęcie bez żadnych korekt (wszystkie suwaki ustawione na 0, łącznie z kontrastem na Tone Curve). W Camera Raw mogłem bez problemu wyciągnąć szczegóły ze świateł. Po wywołaniu zdjęcia, światła były całkowicie prześwietlone. Nie było tam żadnych szczegółów -- wszystkie pixele w badanym obszarze = (255,255,255). Nawet ekstremalna zmiana kształtu histogramu nie ujawniła żadnych detali.

Podsumowanie

Niezależnie od doboru oprogramowania do wywoływania RAWów spod znaku Adobe, techniczne możliwości wywoływania RAWów są identyczne. Praca w 16-bitowej przestrzeni barw daje duże możliwości ingerencji w zdjęcie bez istotnej straty jakości. Większość swoich zdjęć wywołuję korzystając z połączenia metody I i II: ustawiam ekspozycję dość wysoko, właściwą tonalność nadaję obniżając jasność prawie do zera. Później delikatnie zmniejszam ekspozycję. Kontrast i kolory poprawiam już podczas pracy w Photoshopie.

Ale uwaga -- to jest moja metoda! Nie twierdzę, że jest najlepsza z możliwych. Czytelników zachęcam do samodzielnych eksperymentów :)

Synchronizacja Bridge⇔Lightroom

Kolega namówił mnie na zakup Lightrooma, twierdząc że jest to świetne narzędzie do katalogowania i przeglądania zdjęć. Zaufałem i kupiłem. Jestem w trakcie oswajania się z interfejsem.

Pierwszy problem, który napotkałem ma związek ze współdzieleniem metadanych z ocenami między Bridgem (BR) i Lightroomem (LR). Gwiazdki przenoszą się bez problemu. Kolory też, po wybraniu w menu LR Metadata▸Color Label Set▸Bridge Default. Jeśli zmieniliśmy jakieś matadane w Bridge po zaimportowaniu obrazków do LR, wystarczy zaznaczyć wszystkie obrazki i wybrać Metadata▸Read Metadata from File. AFAIK nie ma możliwości automatycznego (= bez klikania czegokolwiek) uaktualnienia danych w LR, jeśli zmienił się plik XMP. Po wykonaniu powyższych kroków, synchronizację Bridge▸Lightroom mamy prawie zrobioną.

Aby ustawianie przenosiły się z Lightroom do Bridge, wystarczy w dialogu Edit▸Catalog Settings... [Ctrl]+[Alt]+[,], w zakładce Metadata zaznaczyć opcję Automatically write changes into XMP. Od tej chwili, każda zmiana metadanych zostanie od razu zapisana w pliku XMP. Tę zmianę Bridge wychwytuje natychmiast bez problemu (trzeba przełączyć się na okno Bridga; czasami konieczne jest też odświeżenie [F5]).

Pozostał tylko jeden problem -- synchronizacja zdjęć oznaczonych jako 'Rejected'. Bridge przypisuje do takich zdjęć ocenę -1 (xap:rating) w pliku XMP. Lightroom wcale nie umieszcza informacji o fladze "rejected" w tym pliku. Flagi trzymane są jedynie w bazie danych LR.

Najprostszym rozwiązaniem jest rezygnacja ze stosowania oceny (w Bridge) lub flagi (w lightroom) "Rejected" na rzecz oznaczeń kolorami. Można też każdorazowo przeprowadzać ręczną synchronizację opisaną poniżej. (BR→LR) Zdjęcia które zostały już oznaczone jako odrzucone, można jednym kliknięciem odfiltrować, zaznaczyć wszystkie i zmienić kolor (np. na fioletowy; Label>To Do). Teraz zostaje tylko odświeżenia metadanych w LR (Metadata▸Read Metadata from File). Dodatkowo można teraz oflagować zdjęcia jako Rejected i usunąć kolor (UWAGA - patrz niżej). Synchronizację LR→BR przeprowadzamy analogicznie. W przypadku braku wolnego koloru, można posłużyć się słowem kluczowym, np. 'rejected'.

Zważywszy na fakt, iż synchronizacja musi być wykonywana ręcznie, dość łatwo doprowadzić do niespójności w oznaczeniach plików odrzuconych w LR i BR. Trzeba też uważać na sytuację, gdy wcześniej odrzucony plik "przywracamy do życia", tj. zmieniamy jego stan z "rejected" na inny. W LR ocena zdjęcia jest niezależna od flag, można zatem odrzucony plik ocenić np. na 3 gwiazdki (zakładamy, że wcześniej nie był wcale oceniany). Spowoduje to w BR ustawienie oceny na 3, a co za tym idzie usunięcie oznaczenia "rejected". Jeśli w BR zmienimy ocenę 'rejected' na 0..5 gwiazdek, analogiczna zmiana w ocenie nastąpi w LR. Jednak flaga odrzucenia pozostanie ustawiona. Ten przypadek łatwo wykryć, jeśli przyjmiemy zasadę, iż wszystkie odrzucone w LR pliki powinny posiadać ocenę 0 gwiazdek.

Biorąc pod uwagę powyższe spostrzeżenia, najbezpieczniej jest zrezygnować ze stanu 'rejected' na rzecz koloru, mając nadzieję, że przy następnym uaktualnieniu Adobe wymyśli sposób na rozwiązanie problemu synchronizacji odrzuconych zdjęć.

Jest jeszcze drugie potencjalne rozwiązanie. Baza danych LR zapisywana jest w formacie SQL Light 3 (rozszerzenie lrcat), można zatem, bazując na ocenie zapisanej w pliku XMP, zmodyfikować flagi odrzucenia bezpośrednio w bazie i vice versa. Problem w tym, że LR (dokładniej: SQL Lite) nie zmienia pliku bazy danych zaraz po zmianie oceny (ani w bliskiej przyszłości). Nie udało mi się zmusić LR do zapisania pliku z bazą danych "na żądanie". Zmiany można zatem wprowadzać/odczytywać, tylko wtedy, gdy LR nie jest uruchomiony.

Można napisać narzędzie, które przeskanuje bazę danych LR i odpowiednie pliki XMP (informacje o ich lokalizacji są w bazie). Na podstawie zebranych danych zsynchronizuje obie lokacje. Decyzję w którą stronę synchronizować można podjąć bazując np. na czasie ostatniej modyfikacji.

Jeszcze lepiej by było, gdyby dało się odczytywać i zapisywać dane z bazy podczas działania LR. Mam klika pomysłów na osiągnięcie tego :) Bazę eksplorowałem za pomocą programu SQLiteSpy, który może mieć ograniczone możliwości w kwestii blokad i współdzielenia bazy. Możliwe, że da się osiągnąć to, o czym pisałem wyżej za pomocą API albo wstrzyknąć wątek do procesu LR i użyć SQLite Shared-Cache Mode. Możliwe, że trzeba będzie trochę pogrzebać w części kodu odpowiedzialnej za łączenie się z bazą.

Życie było by o wiele piękniejsze, gdyby wszystkie programy były Open Source (przynajmniej w części UI i logiki). Z drugiej strony -- nie było by wtedy zabawy przy Reverse Engineeringu ;)

Na koniec zapytanie SQL pokazujące jak można wyciągnąć z bazy LR flagę (0 - brak flagi, 1 - oflagowane (flagged), -1 - odrzucone (rejected)) dla pliku o danej nazwie:

SELECT ai.pick 
FROM
   Adobe_images ai
   JOIN AgLibraryFile alfi ON (ai.rootfile=alfi.id_local)
WHERE
   alfi.baseName = 'NazwaPlikuBezRozszerzenia'
   AND alfi.folder=(
                SELECT alfo.id_local
                FROM
                    AgLibraryFolder alfo
                    JOIN AgLibraryRootFolder alrf ON (alfo.rootFolder=alrf.id_local)
                WHERE absolutePath='C:/ścieżka/do/pliku/'
                );

Ćwiczenia czas zacząć!

Witajcie na moim blogu poświęconym efektywnej pracy w Photoshopie Edytorze Graficznym Adobe® Photoshop® [http://www.adobe.com/misc/trade.html]. Aby uczynić zadość regułom używania nazwy tegoż edytora, jako stary programista C, pozwolę sobie na zdefiniowanie pewnych symboli preprocesora:

#define Photoshop PS
#define PS Edytor Graficzny Adobe® Photoshop®

Uff.. teraz mogę już spać spokojnie ;)

Jak już wspomniałem, ten blog będzie poświęcony technikom czyniącym pracę w edytorze graficznym pewnej znajej firmy na literę A szybką, łatwą i przyjemną. Oczywiście stanie się to zaraz po tym, jak wdrożymy pewne czasochłonne, skomplikowane a czasami nawet zagmatwane rozwiązania. IMHO warto jednak poświęcić nawet sporą porcję czasu, aby ułatwić sobie przyszłe życie, w zgodzie ze wzorem:

t_saved = t_noopt * n - (t_impl + t_opt * n),

gdzie: t_saved - czas oszczędzony, t_noopt - czas potrzebny na wykonanie czynności przed usprawnieniem, t_opt - czas potrzebny na wykonanie czynności po wprowadzeniu usprawnienia, t_impl - czas potrzebny na naukę i wdrożenie, n - liczba powtórzeń czynności. Rzecz jasna śmiało zakładam, że t_opt < t_noopt, oraz że t_impl jest mniejszy od nieskończoności. W tych niezwykle sprzyjających warunkach optymalizacja często powtarzanej czynności (kiedyś w końcu) przyniesie nam wymierną oszczędność czasu :)

Co dokładnie na blogu będzie? To się okaże. Przewiduję wpisy z zakresu:

• Usprawniania pracy poprzez akcje
• Automatyzowania pracy z wykorzystaniem skryptów w języku JavaScript w odmianie Adobe
• Wyjaśnienie działania często źle lub nie do końca rozumianych operacji (np. zmiana trybów mieszania)
• Prezentacja technik, które używam podczas obróbki fotografii
• Ergonomii pracy

Wiem jednak czego na pewno tu nie będzie. Nie będzie powielania bezsensownych totoriali z innych źródeł. Nie będzie bezwartościowej paplaniny (poza tym postem ;)). Zagadnienia edycji grafiki i workflow będę opisywał patrząc okiem informatyka i matematyka. Nie będę powstrzymywał się od wzorów i teorii! Postaram się jednak ładnie je wydzielić, aby normalni czytelnicy też mieli jakiś pożytek i nie uciekali z tych stron z krzykiem.

W założeniu mam prowadzenie dwujęzycznego blogu: wersja polska pod tym adresem (http://PhotoshopWorkoutPL.blogspot.com), a angielska pod: http://PhotoshopWorkout.blogspot.com. Będę starał się utrzymywać synchronizację zawartości, jednak nie zawsze będzie to możliwe w czasie rzeczywistym. Nie jestem w stanie przewidzieć, na którym z nich będę umieszczał posty w pierwszej kolejności.

Zapraszam do eksploracji! :)