Szukaj
Do tego akurat jestem przekonany. Mi raczej chodziło o nieliniowość TIFFa (może dokładniej: o nieliniowość tej wersji TIFFa, którą produkują popularne programy do obróbki RAW).Zamieszczone przez Andy_O
W specyfikacji nic na ten temat nie ma. Jednak można wysnuć pewne wnioski.
Skoro pracując w PS-ie pracujemy na wersji nieliniowej, a TIF z RAW-a miałby być liniowy, to otworzenie go PS-ie byłoby jednoznaczne ze stratą części danych. Czyli PS obcinałby część danych bez ostrzeżenia. Nieumieszczenie odpowiedniego ostrzeżenia przez twórców PS-a byłoby sporym błędem w który jakoś nie chce mi się wierzyć.
To oczywiście nie jest dowód na nieliniowość TIF-a, ale dowodów na liniowość też brak.
Nie zdziwiłbym się, gdyby w PSie pracowało się po prostu na nieliniowych danych, a potem następowałaby konwersja do formatu liniowego. Przecież taki sposób postępowania jest dużo lepszy jeśli chodzi o obróbkę. Nie tracisz dużo informacji, gdy przyciemniasz pewne partie zdjęcia jedną operacją, a drugą je w jakiś sposób rozjaśniasz.
A tak wogóle, to skąd wiadomo na jakiej reprezantacji danych pracuje PS (chodzi mi o liniowość-nieliniowość)?
Wszelkie numeryczne ustawienia w LEVELS są oparte na skali liniowej ale wyniki ich działania są zgodne z postrzeganiem człowieka. Poza tym jak sobie wyobrazić sytuację, gdy w cieniach mamy 2^16 bitów, a w światłach więcej, np. 2^24 ? Na pionowej osi w curves byłby inny zakres dla cieni a inny dla świateł?
Wykresy w levels i curves są reprezentacją nieliniowej tonalności (bo zgodne z naszym postrzeganiem) ale skonwertowanej do liniowej skali (bo w światłach i cieniach mamy taką samą ilość poziomów).
Wydaje mi się, że wewnętrzna reprezentacja danych (czyli na jakiej postaci danych program operuje), a ich wizualizacja w różnych narzędziach (np. levels) to 2 zupełnie różne sprawy i na tej podstawie nie można wyciągać żadnych wniosków. To tak, jakby ktoś oglądając datę w jakimś programie stwierdził, że musi być ona reprezentowana jako napis (ew. jako rok+miesiąc+dzień+godzina+minuta+sekuna+setne_cz ęści), co jest totalnym rozminięciem się z prawdą (zwykle jest to liczba milisekund od 1970 roku).
Zauważ że wszystkie formaty dat to formaty względem siebie liniowe. Tzn we ewszystkich sposobach kodowania dat "odległość" miedzy 1 stycznia 1980, 1 stycznia 1985 a 1 stycznia 1990 to 5 lat.
Tymczasem odległość między początkiem i końcem pierwszej działki przysłony (tej lewej) na histogramie a początkiem i końcem ostatniej działki (tej z prawej) to zupełnie inna ilość poziomów z RAW.
A więc jeśli założymy, że w PS pracujemy i obserwujemy postać nieliniową ("ludzką") a mimo to PS wewnętrznie wszystko przetwarza na liniową (jak w RAW) to pojawiałyby się kłopoty z zaokrąglaniem i co za tym idzie, błędami w przetwarzaniu. Czyli np. rozjaśnienie cz/b obrazka o 1 poziom ("ludzki") a potem przyciemnienie o jeden poziom ("ludzki") już wprowadzałoby błędy wynikające z 2 konwersji nieliniowe-> liniowe. Po kilku takich operacjach błędy nakładałyby się na siebie i byłoby to widoczne zwłaszcza w cieniach, gdzie nie mamy tyle informacji co w światłach.
Ale łatwo sprawdzić, że przyciemnienie i rozjaśnienie o jeden poziom wykonane tysiąc razy nie zmieni nic w obrazie.
Więc PS nie dokonuje konwersji. Więc przechowuje dane "po ludzku" w formie liniowej uzyskanej z RAW przez przekształcenie nieliniowe (zamiana z RAW na postać "ludzką" i potem obróbka liniowa tej postaci).
Czyli wnioski są takie: zamiana postaci RAW (liniowej, nieludzkiej) na TIF (liniową, ludzką) poprzez funkcję nieliniową pociaga za sobą stratę wielu informacji o światłach. Czyli Al miał rację - jedyną metodą na oszukanie tego mechanizmu i przemycenie do PS wikszej ilości informacji o światłach jest wywołanie RAW z korekcjami -1, -2, -3 ... dzięki temu duża ilość informacji z prawej strony histogramu zostaje rozciagnięta w lewo i uratowana przez zniszczeniem.
Drugi wniosek jest taki, że robienie korekcji "na plus" (przy konwersji 1klatka RAW -> HDR ) nie ma sensu, bo w ten sposób nie uratujemy informacji w cieniach.
Ja piszę o tym, że PS może wewnętrznie pracować na danych zmiennopozycyjnych i dzięki temu kolejne rozjaśnianie i przyciemnianie nie będzie pociągało za sobą daleko idących konsekwencji, bo w cieniach będzie tyle samo informacji co w światłach. Gdyby PS przechowywał dane liniowo, to właśnie powstałby efekt, o którym piszesz.
No ale możesz krzywymi określić sposób tej konwersji. Ponieważ masz "zapas" w światłach, to co stoi ma przeszkodzie, aby krzywymi "przenieść" je do cieni? Wywołanie RAW na kilka różnych sposobów to nic innego jak pewna złożona funkcja nieliniowa. Jaki problem zaplikować ją przy wowoływaniu i już?
A jakby wogólne nie stosować konwersji, to przecież dostaniemy tyle samo informacji. A potem w PS sobie tego TIFFa "uczłowieczyć".
Zapomnijmy na chwilę o linio-nielinio-wości, gdyż w tej kwestii wole się nie wypowiadać.
Wydaje mi się, że stosowanie liczb zmiennoprzecinkowych w trybie 8 i 16 bitowym ma dwie zasadnicze wady:
1. Zwiększone zużycie pamięci, gdyż taka reprezentacja przy rozsądnej dokładności wymaga większej liczby bitów.
2. Operacje arytmetyczne za liczbach zmiennopozycyjnych są bardziej procko-chłonne, co bezpośrednio przekłada się na szybkość obróbki dokumentów.
W związku z tym wątpie, aby autorzy PSa zdecydowali się na coś takiego.
Na 100% liczb zmiennoprzecinkowych używamy w reprezentacji 32 bitowej. (z racji na zwiekszoną dynamike - idealny kompromis pomiedzy zakresem a dokładnością)
Pozdrawiam
AK
Ostatnio edytowane przez akrzykalski ; 13-08-2007 o 20:25
=> całe życie zastanawiam się co tutaj umieścić <=
No nic.
Dziękuję za pobudzenie mnie do ruszenia głową i zastanowienia się nad tą całą tonalnością RAW-ów. Niby się o tym wie, ale jakoś sobie człowiek tego nie uświadamia.
Teraz jestem bogatszy o nowe przemyślenia, a że CS3 wkońcu zawitał na desktopie (razem z nowymi suwaczkami w ACR) - obiecuję wiekszą uwagę przykładać od tej pory do pierwszego etapu obróbki, czyli konwersji RAW-ów.
No i Al - przyznaję Ci rację.
Uprawnienia umieszczania postów
Odpowiedz z cytatem
Skontaktuj się z nami