Zobacz pełną wersję : HDR "kaszalota"
akrzykalski
03-08-2007, 23:06
Greetings 4 all!
Tematem dzisiejszej lekcji jest: Reanimacja "niewystarczająco dobrze" naświeltonej fotografi przy pomocy technik związanych z przetwarzaniem obrazów High Dynamic Range (dalej HDR). :)
Na wstępie wyjaśnijmy sobie ogólnikowo czym jest HDR - otóż pod pojęciem tym najczęsciej kryją się metody obróbki obrazów, w których dynamika pomiędzy światłami, a cieniami znacząco przekracza to z czym mamy do czynienia w tradycyjnej obróbce. Innymi słowy odległość pomiędzy czarnym, a białym punktem jest zbyt duża, aby możliwe było wyświetlenie na jednym obrazie wszystkich wartości pośrednich (nie mylmy tego z 16 bitowym przetwarzaniem, gdzie odległość jest taka sama jak w 8 bitowym, natomiast różnice pomiędzy sąsiadującymi tonami są znacznie mniejsze).
Cały misz masz z tego typu obrazami polega na tym, że zawierają one znacznie więcej informacji niż jest w stanie wyświetlić monitor, zarejestrować aparat czy oko ludzkie. Na szczęście ludzkość, zmyślna rasa wymyśliła coś takiego jak mapowanie tonalne. Polega to mniej więcej na spłaszczaniu wielkiego zakresu tonalnego HDRa do przestrzeni widzianej w tradycyjnej obróce. Problem w tym, że ta druga przestrzeń jest mniejsza, heh a my wpychamy w nią coś większego, więc mamy pierwszy sygnal mówiący o tym, że tracimy jakieś informacje o obrazie. Spokojnie, właśnie o to nam chodzi, z tym że trzeba zrobić to z głową (czytaj: przy pomocy odpowiedniego softu).
To tyle tematem wstępu i obiecuję koniec zanudzania!
Na tapętę wrzucę takie zdjęcie:
https://forum.nikoniarze.pl//brak.gif
źródło (http://wrzaski.z-krakowa.pl/misc/hdr/hdr1.jpg)
Fotka została strzelona do RAWa. Robiona była pod światło, przez radosnego pstrykacza, który w chwili zachwytu pięknym widokiem na Pieniny .... prześwietlił niebo! :D
Chwila zabawy z suwakiem ekspozycji i wyszło, że nie wszystko jeszcze stracone - przy odpowiednim ustawieniu widać chmury i niebo:
https://forum.nikoniarze.pl//brak.gif
źródło (http://wrzaski.z-krakowa.pl/misc/hdr/hdr2.jpg)
No tak, w RAWie jakieś tam ekstra informacje jeszcze mamy, ale jak je wydobyć aby to co jest poniżej lini horyzontu nie zostało zrujnowane?? Tada... "zrobimy sobie HDRa". :)
PRZEPIS NA HDRa => Z KALENDAŻA BABCI MALINY
0. Nie każda fotka, scena nadaje się do tego typu zabawy! Taka obróbka opłaca się szczególne, w przypadku gdy godzimy się podnieść kontrast sceny - kosztem posteryzacji.
1. Jak jeszcze zdjęcia nie "pykneliśmy", a widzimy, że dynamika sceny jest zbyt duża robimy bracketing co 1EV przy stałej przesłonie (GO pozostaje niezmienna)
2. Jeżeli już "po ptokach" i mamy tylko jednego rawa to sprawdzamy przy pomocy suwaka ekspozycji czy jest jeszcze coś do wyciągnięcia. Jeżeli tak to wywoływujemy sobie zestaw TIFFów z ekspozycją zmienianą co 1EV. I tak ja z przykładowego zdjęcia utworzyłem 5 plików (EV: -2, -1, 0, 1, 2). Następnie pozbywamy się danych EXIF z nowo utworzonych plików (np poprzez wklejenie do nowego dokumentu w PSie)
3. Otwieramy PSa i z menu File->Automate wybieramy opcję Merge to HDR. Następnie wybieramy uprzednio utworzone pliki i klikamy OK. Teraz w zależności od ilości RAMu i szybkości procka idzimy na kawkę, z psem na spacer etc.. ;) Jak program skończy sklejać zdjęcia zostaniemy zapytani o parametry ekspozycji poszczególnych plików źródłowych. Proponuję wpisać tutaj to co widniało obok suwaka ekspozycji podczas wywoływania. Następnie klikamy OK... eee i jeszcze raz OK.
4. "I ich oczom ukazał sie las..." No tak, w tym momencie to wyblakłe coś co wyskoczyło nam na ekran to photoshopowa interpretacja HDRa. Wygląda to mniej więcej tak:
https://forum.nikoniarze.pl//brak.gif
źródło (http://wrzaski.z-krakowa.pl/misc/hdr/hdr3.jpg)
5. W kolejnym kroku dokonujemy tonalnego mapowania. Można próbować majstrować coś ręcznie, lub użyć dedykowanej wtyczki. Ja preferuje tą drugą metodę. Z kilku zabawek jakie widziałem najbardziej przypadł mi do gustu ToneMapping firmy Photomatix (http://www.hdrsoft.com/, 55 euro, można ściągnąc pieczątkowego triala).
Wtyczka po uruchomieniu wygląda mniej więcej tak:
https://forum.nikoniarze.pl//brak.gif
źródło (http://wrzaski.z-krakowa.pl/misc/hdr/hdr4.jpg)
Wnikanie w dostępne opcje przerasta możliwości tego tutka, proponuję poeksperymentować troszkę. Na początek można kliknąć po prostu OK.
Po zaaplikowaniu pluginu nasz obrazek zmienia się nie do poznania:
https://forum.nikoniarze.pl//brak.gif
źródło (http://wrzaski.z-krakowa.pl/misc/hdr/hdr5.jpg)
6. Praktycznie już dobrneliśmy do końca. W tym kroku dokonamy tylko konwersji na standardowy obrazek. Z menu Image->Mode wybieramy 8 lu 16 bitów. Wyskakuje nam okienko dialogowe, w którym przy zastosowaniu ToneMapping najistotniejsze są suwaki Exposure i Gamma. Dobieramy je tak, aby uzyskany w podglądzie obraz był dla nas jak najbardziej zadawalający. Klikamy OK i gotowe. :)
--------------------
7. Dalej to już zwykła zabawa w PSie. Robimy, co lubimy... :)
Moje pierwsze podejście wyglądało tak:
https://forum.nikoniarze.pl//brak.gif
źródło (http://wrzaski.z-krakowa.pl/misc/hdr/hdr6.jpg)
Jednakże nie udało mi się wyciągnąć z RAWa dostatecznych informacji o kolorze nieba, więc niestety wyszło ono monochromatycznie. Przy bracketingu taki problem by nie wystąpił. Po chwili namysłu doszedłem do wniosku, że BW będzie wyglądało najlepiej...
https://forum.nikoniarze.pl//brak.gif
źródło (http://wrzaski.z-krakowa.pl/misc/hdr/hdr7.jpg)
--------------------
I to już jest koniec.
Powyższy tutorial jest tekstem czysto amatorskim. Mam nadzieje, że udało mi się przybliżyć Wam tematykę zagadnienia. Z ewentualne błędy... z góry sorki!
Pozdrawiam
AK
dzieki - pewnie skorzystam
Ja także się pobawię:) THX
Zabiłeś mnie tym efektem, jak takie zdjęcie mogło nagle przepoczwarzyć się w pięknego motyla ehh i jeszcze konkurosowego :) szok ;) Napewno się pobawie. THX pozdrawiam, AMI
Sebastiann
07-08-2007, 09:44
Świetna robota ,dzięki za tutka!
Przydatna lekcj :) Dzięki
Tak mnie nurtuje pytanie..
Czy jeśli mamy tylko jedną klatkę, to zamiast wołać z NEF-a z różnymi korektami okspozycji i potem łączyć jak HDR-a.. nie prościej jest zapisać do 16-to bitowego tiff-a i w PS-ie zamienić na 32bity? Przecież przy pierwszej metodzie i tak "z pustego nie nalejemy" czyli obraz nie będzie zawierał więcej informacji niż w przypadku drugim..
Wejściowy obraz (w przypadku posiadania tylko jednej klatki) ma 12 bitów i więcej nie wyciśniemy..
Al Bundy
07-08-2007, 22:36
Bity bitami - biel to też bity - podobnie chmurki zamiast plamy więc raczej efekt ten sam nie będzie ;)
dzieki, trzeba sprobowac :)
raczej efekt ten sam nie będzie ;)
Wg mnie konwersja
RAW 12bit -> kilka TIF-ów 16 bit -> łączenie TIF-ów -> obraz 32 bit
jest bardziej stratna niż
RAW 12bit -> TIF 16 bit -> obraz 32 bit
Po prostu omijamy dwa przeształcenia - rozbicie i zcalenie obrazu. Oczywiście mówię o jednej klatce, czyli jeśli za wczasu nie zrobiliśmy BKT.
Al Bundy
09-08-2007, 19:37
W teorii może i tracimy jakieś bity ale moim zdaniem wywołanie tego samego nefa a później jego "klejenie" da nam więcej szczegółów. Nie rozważam tego od strony matematycznej a czysto "ocznej " :D
Poproszę o przykład ;)
W teorii może i tracimy jakieś bity ale moim zdaniem wywołanie tego samego nefa a później jego "klejenie" da nam więcej szczegółów. Nie rozważam tego od strony matematycznej a czysto "ocznej " :D
Poproszę o przykład ;)
Oto przykład ;-)
Ze słoika litrowego rozlewamy wodę do 10 menzurek, a potem ich zawartość wlewamy spowrotem do innego litrowego słoika. Czy w tym drugim słoiku będzie litr wody? ;-)
Al Bundy
10-08-2007, 11:10
Nie do końca jest jak mówisz :D Klejenie z jednego nefa odbywa się bez zapisywania i ponownego otwierania jpga - kleimy dwa zdjęcia zaraz po otwarciu więc nie mam mowy o utracie czegokolwiek ;) Musimy usiąść przy kompie a udowodnię swoją tezę ;)
Klejenie z jednego nefa odbywa się bez zapisywania i ponownego otwierania jpga
Jakiego jpega?
NEF-a zwykle konwertujemy do TIF-a 16bit, żeby nic nie stracić.
Ale sama operacja rozbicia i późniejszego zcalania przecież nie doda nam informacji, których w pliku nie ma. W najlepszym wypadku nic nie wniesie.
Stąd moja konkluzja, żeby w przypadku posiadania tylko jednej klatki bezpośrednio ją skonwertować na 32 bity.
Al Bundy
10-08-2007, 13:25
No nic - podeślę Ci wieczorem nefa a jak mi go pokażesz - ja pokażę swoją wersję i ocenimy efekt końcowy bez liczenia bitów ;)
Mój przykład niewiele będzie się różnił od tego powyżej - nie masz szans jednorazowo wyciągnąć tyle detali co przy dwukrotnym otwarciu nefa z róźnymi EV - chyba że lubisz ostrą długą jazdę na oklep :D
No nic - podeślę Ci wieczorem nefa a jak mi go pokażesz - ja pokażę swoją wersję i ocenimy efekt końcowy bez liczenia bitów ;)
Mój przykład niewiele będzie się różnił od tego powyżej - nie masz szans jednorazowo wyciągnąć tyle detali co przy dwukrotnym otwarciu nefa z róźnymi EV - chyba że lubisz ostrą długą jazdę na oklep :D
A czy przypadkiem dwukrotnie otawarcie nefa z różnymi EV nie działa tak samo, jak odpowiednia modyfikacja krzywych (w porywach użycie highlight/shadow)? Bo jakoś nie za bardzo mogę zrozumieć, czemu nie miałoby się dać to zrobić w 1 kroku.
A czy przypadkiem dwukrotnie otawarcie nefa z różnymi EV nie działa tak samo, jak odpowiednia modyfikacja krzywych (w porywach użycie highlight/shadow)? Bo jakoś nie za bardzo mogę zrozumieć, czemu nie miałoby się dać to zrobić w 1 kroku.
Własnie - wg mnie to jest to samo.
Ale mam wrażenie, ze Al mówi o czymś innym - o technikach wyrównywania ekspozycji z obrazów HDR.
Czyli Al chce złączyć kilka obrazków (uzyskanych z tej samen klatki) w HDR i potem użyć swoich umiejętności do wyciagniecia detali.
Ja piszę o czymś innym - o surowym obrazie HDR, czyli obrazie 32-bitowym który dopiero potem jest dzięki umiejętnościom operatora komputera odpowiednio obrabiany. Nie piszę więc o obróbce (nie wątpię, że Al umie wyciągać detale w ten sposób) ale o zawartości pliku 32bit przed obróbką.
Uważam, że rozbijanie i zcalanie nie wpłynie na ilość detali tam umieszczonych. Proste przekonwertowanie obrazu 12 na 32 bity powino być najprostszym rozwiązaniem.
Obawiam się, że nie dam rady tego dzisiaj udowodnić organoleptycznie, bo zbliża się ciężka sesja czyli "nadciąga totalny kataklizm" ;-)
Proste przekonwertowanie obrazu 12 na 32 bity powino być najprostszym rozwiązaniem.
Obawiam się, że nie dam rady tego dzisiaj udowodnić organoleptycznie, bo zbliża się ciężka sesja czyli "nadciąga totalny kataklizm" ;-)
To chyba nie jest tak prosto, bo ten obraz (NEF) 12 bitowy ma zupełnie inną strukturę niż ten 32 (TIFF). Chodzi o to, że w NEFIe 12 bity są na każdy piksel i ten może być tylko 1 koloru, a w TIFFie są 32 bity na składową, a takowych jest 3 na piksel (zakładam, że alfy nie ma). Tak więc dochodzi tu jeszcze algorytm demozaikowania, od którego wiele może zależeć.
Al Bundy
10-08-2007, 14:55
Machanie krzywymi czy cieniami i światłami w surowym nefie to nie to samo. Pamiętajcie że miksujecie wtedy każdym pikselkiem na zdjęciu - mimo iż niektóre chcielibyscie zostawic w spokoju. Klejenie róźnych wersji właśnie uwalnia nas od tego problemu. Nie mówię tutaj o HDR bo prawdziwy HDR nie jest pochodną jednej i tej samej klatki. Nadal twierdzę że czasem daje to lepszy efekt ;) Widać to zwłaszcza na fotach krajobrazowych - zakładam że chcecie rozjaśnić delikatnie cienie trawy - machacie krzywymi ale pamiętajcie że mimo iż niebo z założenia jest jaśniejsze to na nim też znajdą się pikselki ciemne które rozjaśnicie - tracąc szczegóły właśnie...
Nadal twierdzę że czasem daje to lepszy efekt ;) Widać to zwłaszcza na fotach krajobrazowych - zakładam że chcecie rozjaśnić delikatnie cienie trawy - machacie krzywymi ale pamiętajcie że mimo iż niebo z założenia jest jaśniejsze to na nim też znajdą się pikselki ciemne które rozjaśnicie - tracąc szczegóły właśnie...
To chyba zaczynamy już mówić o DRI. Wycinamy dolny kawałek z trawą i zastępujemy go jaśniejszym. No ale to to samo, co zamiana na oraz 32 bitowy. Nałożenie maski i .... rozjaśnienie. Dobrze mówię?
Al Bundy
10-08-2007, 19:39
Szczerze wątpię - poproszę o dowody ;)
Pamiętajcie że miksujecie wtedy każdym pikselkiem na zdjęciu - mimo iż niektóre chcielibyscie zostawic w spokoju.
Nie nie nie, tu się nie zgodzę. W shadow/highlight są jeszcze dwa magiczne suwaczki "radius" dzięki którym nie pracujesz na każdym pikselu zdjęcia, tylko na ich "skupiskach".
Analogicznie jak w USM - nie musisz wyostrzać pojedyńczych pixeli ale odpowiednio duże ich skupiska.
Ale nie o tym tutaj mówimy. Mówimy o informacjach zawartych w pliku 32-bitowym przed wyciąganiem świateł i cieni.
To co napisał milo_ja jest ciekawe - 12 bitów na pojedyńczą komórkę matrycy? Czyli tiff 16bitowy jest stratny..
Jeszcze inaczej: RAW jest 12bit, owszem, ale liniowe 12bit. Czyli po zdekodowaniu z jednej strony histogramu jest bardzo dużo informacji, a z drugiej znacznie biedniej.
To co napisał milo_ja jest ciekawe - 12 bitów na pojedyńczą komórkę matrycy? Czyli tiff 16bitowy jest stratny..
Trochę mieszają się tu "bitowości". RAW ma 12 bit na każdego piksla matrycy, który jest monochromatyczny. Więc de facto można policzyć mniej więcej rozmiar pliku w bitach mnożąc 12 * ilość komórek. To, że tiff jest szesnastobitowy (podobnie jak JPEG 8) oznacza, że na KAŻDY kanał jest 16 (8) bitów. A że kanałów jest 3 (R, G, B), to plik zajmie (zakładając, że nie ma kompresji) 16 * ilość piksli * 3 bitów (dla JPEGa 8 * ilość piksli * 3 bitów). Tak wiec w 16 bitowym TIFFie jest aż nadto "miejsca", żeby "łyknąć" RAW oczywiście, po wcześniejszej konwersji po postaci 3 kanałów na piksel (RAW ma 1).
Al Bundy
10-08-2007, 23:24
Zakręciliście to tak że ja już nic nie rozumiem :D Ja nie sprowadzam tego to iloścu bitów - dla mnie liczy się efekt końcowy a nie matematyka. Do tego nie wiem na czym chcecie te bity oglądać skoro nie mamy takich monitorów a skoro ich nie ma i tego nie widać to jak to obrobić ? hehehehe...
akrzykalski
11-08-2007, 00:10
O... koledzy Andy i Bundy (heh czlowiek nawet nie czuje jak mu sie rymuje) ;)
Moim zdaniem All ma racje. Chyba pomyliliście tutaj bity, a dokładniej to co one reprezentują. W przypadku 16 bitowego przetwarzania mamy do czynienia ze zwiększoną rozdzielczością tonalną. Innymi słowy w zakresie od czerni do bieli mamy znacznie więcej poziomów pośrednich. Tego typu obrazy oferują nam znacznie większą precyzję podczas dokonywania późniejszej obróbki. Niestety według mnie ma się to nijak to zakresu na jakim pracujemy w przestrzeni 32 bitowej.
Tak abstrakcyjnie troszkę: załóżmy ze 32 bitowa reprezentacja obejmuje zakres od 5 - 25. Pojedyńczy obraz 8 lub 16 bitowy będzie zawierał tylko wycinek tej przestrzeni np od 10 - 15. Różnić się tylko będą dokładnością odwzorowania. Widzicie różnice??
Przed chwilą wywołałem 16 bitowego tiffa. Przerobiłem go na łobrazek 32 bitowy... i co?? I kupa... Nic ekstra niestety nie zobaczyłem.
Wniosek jaki przychodzi mi do głowy: fakt, że matryca ma przetwarzanie 12-bitowe ma się raczej nijak do bitowości otrzymanego po wywołaniu tiff'a, jakby była to zupełnie inna metoda reprezentacji danych.
PS.
Dopiero wrocilem do kraju i wątek przeczytalem tak na szybkiego, więc sorki jak nie na temat.
Pozdrawiam
AK
Momencik - RAW ma 12bit na kanał, ale TIF ma 16 bit na kanał.
Ale RAW jest liniowy a TIF nieliniowy jak oko ludzkie.
Więk być może tu jest pies pogrzebany - po konwersji RAW na TIF w zakresie świateł uzyskujemy znacznie więcej poziomów niż jest w stanie pomieścić 16bit TIF.
Jeśli więc potwierdzi się, że konwertując RAW na TIF 16bit tracimy część informacji, implikacje będą następujące:
-jak najwiecej operacji korygujących (kolory, jasność) należy wykonywać na etapie obróbki RAW a nie w PS-ie
- Al ma rację, sposobem na nie-stracenie tego dodatkowego zakresu tonów jest rozbicie na kilka TIF-ów.
- a co z konwersją w ACR bezpośrednio do PS-a jako obraz 32-bit? Obędzie się bez rozbijania obrazu, w jednym kroku..
Do tego nie wiem na czym chcecie te bity oglądać skoro nie mamy takich monitorów a skoro ich nie ma i tego nie widać to jak to obrobić ? hehehehe...
oczywiście że extra-zakres nie jest widoczny. Ale bezcenny podczas ratowania świateł i cieni.
akrzykalski
11-08-2007, 10:31
Momencik - RAW ma 12bit na kanał, ale TIF ma 16 bit na kanał. Ale RAW jest liniowy a TIF nieliniowy jak oko ludzkie.
Więk być może tu jest pies pogrzebany - po konwersji RAW na TIF w zakresie świateł uzyskujemy znacznie więcej poziomów niż jest w stanie pomieścić 16bit TIF.
Chyba masz racje stawiając tę tezę. Pogrzebałem przed momentem w kilku fotkach i nie udało mi się wyciągnąć większej ilości informacji w cieniach z RAWa w stosunku do TIFFa. Co ciekawe nie zauważyłem praktycznie żadnej różnicy w pracy na 8 i 16 bitowych plikach, co chyba sugeruje odpowiedź na pytanie kiedy używać 16 bitowego formatu. Twoje powyższe twierdzenie wyjaśnia chyba wszelkie zawiłości. ;)
Jeśli więc potwierdzi się, że konwertując RAW na TIF 16bit tracimy część informacji, implikacje będą następujące:
-jak najwiecej operacji korygujących (kolory, jasność) należy wykonywać na etapie obróbki RAW a nie w PS-ie
- Al ma rację, sposobem na nie-stracenie tego dodatkowego zakresu tonów jest rozbicie na kilka TIF-ów.
- a co z konwersją w ACR bezpośrednio do PS-a jako obraz 32-bit? Obędzie się bez rozbijania obrazu, w jednym kroku..
1. No to chyba już się potwierdziło?? Jakby co to mogę wystawić kilka fotek w których ewidetnie widać, że gubimy informacje w jadnych partiach...
2. Reczywiście, skoro formaty raw i tiff nie mają przełożenia 1:1 to wychodzi na to, że jak najbardziej opłaca się obrabiać surowe pliczki. Na przykładzie Camera RAW mogę napisać, że ta opłacalność kończy się tylko na zakładce "Basic". Na moje oko suwaczki z pozostałych zakładek pracują już tylko na standardowym zakresie oferowanym przez 8/16 bit, więc tutaj nic więcej niż w samym PS nie wyczarujemy. Qurcze, a szkoda... :(
3. Nie wiem, może nie potrafię, ale nie udało mi się bezpośrednio z ACRa wydobyć 32-bitowych obrazów. Jesteś pewien, że w ogóle się da?? Heh, była by to całkiem fajna funkcja!
Pozdrawiam
AK
Momencik - RAW ma 12bit na kanał, ale TIF ma 16 bit na kanał.
Ale RAW jest liniowy a TIF nieliniowy jak oko ludzkie.
Tiff jest takim śmiesznym formatem, że nie można powiedzieć jednoznacznie, czy jest liniowy czy nie, bo to zależy od tego, jak został użyty. W porywach w TIFFie można trzymać JPEGa.
Specyfikację można znaleźć tu: http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf
Generalnie jednak w TIFFie informacje o kolorach przechowywane są jako 16 albo 32 bitowe liczby całkowite bez znaku.
Więk być może tu jest pies pogrzebany - po konwersji RAW na TIF w zakresie świateł uzyskujemy znacznie więcej poziomów niż jest w stanie pomieścić 16bit TIF.
W związku z powyższym nie jest to prawda. TIFF jest bardziej pojemny niż RAW jeśli chodzi o ilość informacji w dowolnym zakresie.
Tiff jest takim śmiesznym formatem, że nie można powiedzieć jednoznacznie, czy jest liniowy czy nie, bo to zależy od tego, jak został użyty. W porywach w TIFFie można trzymać JPEGa.
Specyfikację można znaleźć tu: http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf
W specyfikacji nie ma nic na temat obrazów nieliniowych w sensie upakowania informacji. Oczywiście, można w 16bit TIF zapisać obrazek z kolorem 8-bitowym, ale nie o tym tutaj rozmawiamy. Chodzi o maksymalne pojemności formatu w zakresie ilości poziomów poszczególnych kanałów.
Generalnie jednak w TIFFie informacje o kolorach przechowywane są jako 16 albo 32 bitowe liczby całkowite bez znaku.
Sposób kodowania ma znaczenie drugorzędne.
W związku z powyższym nie jest to prawda. TIFF jest bardziej pojemny niż RAW jeśli chodzi o ilość informacji w dowolnym zakresie.
No właśnie nie bardzo. Jeśli np. w ostatnim poziomie TIF-a czyli między jasnością 2^16 a 2^16-1 pożna pomieścić zakres RAW-a między, załóżmy 2^12 a 2^12-8 to mimo mniejszej ilosci bitów na kanał, RAW 12bit zawiera znacznie więcej detali w światłach niż TIF 16bit. Właśnie przez nieliniowość.
W specyfikacji nie ma nic na temat obrazów nieliniowych w sensie upakowania informacji.
Ale jest o przechopwywaniu licz całkowitych bez znaku. Raczej bym się nie spodziewał, że któś przechowywałby liczbę zmiennopozycyjną jako całkowitą (choć oczywiści bity to bity i ich znaczenie zależy tylko od "umowy").
No właśnie nie bardzo. Jeśli np. w ostatnim poziomie TIF-a czyli między jasnością 2^16 a 2^16-1 pożna pomieścić zakres RAW-a między, załóżmy 2^12 a 2^12-8 to mimo mniejszej ilosci bitów na kanał, RAW 12bit zawiera znacznie więcej detali w światłach niż TIF 16bit. Właśnie przez nieliniowość.
Jeśli faktycznie informacje przechowywane są w sposób nieliniowy, to jest to prawda. Możesz podać konkretne miejsce w specyfikacji (ew. jakiś innych źródłach), które o tym mówi? To pewnie rozwiązałoby wszelkie wątpliwości przynajmniej w tej kwesti.
O liniowości RAW-ów mozna przecztać tutaj (http://downloads.indesignmag.com/cp/raw_getting_started.pdf) oraz tutaj (http://www.dpreview.com/learn/?/Glossary/Camera_System/sensor_linearity_01.htm).
O liniowości RAW-ów mozna przecztać tutaj (http://downloads.indesignmag.com/cp/raw_getting_started.pdf) oraz tutaj (http://www.dpreview.com/learn/?/Glossary/Camera_System/sensor_linearity_01.htm).
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).
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.
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ść)?
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).
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).
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.
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).
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.
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.
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ć". :)
akrzykalski
13-08-2007, 20:08
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.
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
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ę.
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.
Z tego, co się orientuję, to 16 bitowa liczba zmiennoprzecinkowa zajmuje dokładnie tyle samo miejsca co 16 bitowa liczba całkowita. :) A co do dokładności to są 2 strony medalu: masz większą dokładność dla małych wartości i mniejszą dla dużych. Przy liczbach całkowitych dokładność jest taka sama w całym zakresie.
2. Operacje arytmetyczne za liczbach zmiennopozycyjnych są bardziej procko-chłonne, co bezpośrednio przekłada się na szybkość obróbki dokumentów.
No to się jaknajbardziej zgadza.
W związku z tym wątpie, aby autorzy PSa zdecydowali się na coś takiego.
Autorzy gier 3D od wielu lat się na to decydują, więc czemu nie PSa? :) A tak poważnie, to nie wiem jak to jest, ale nie byłby dla mnie zaskoczeniem taki sposób postępowania.
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
Co do trybu 32 bitowego to jedyne, co mnie po części przekonuje, to rozmiat typu float w większości języków programowania: 32 bity.
Znalazłem taką stronkę: http://www.cdrom.pl/index.php?title=%C5%81%C4%85czenie_forsowanych_eks pozycji opisującą technikę wielokrotnego wywoływania. I w sumie to potwierdziło się to, co myslałem. Przy "bezmózgowym" używaniu jej efekty są takie, jak highlight/shadow (a może nawet gorsze). Żeby uzyskać lepsze efekty, trzeba się trochę pobawić maskami i poziomami na poszczególnych warstwach.
Co do liniowości i nieliniowości TIFFa, to polecam ostatni akapit na stronie 74 specyfikacji TIFFa, do której link podawałem. W skrócie to, czy TIFF ma zapisane informacje w sposób liniowy, czy nie zależy od piszącego, czyli w tym wypadku programu, który wowołuje RAW.
akrzykalski
14-08-2007, 14:29
Z tego, co się orientuję, to 16 bitowa liczba zmiennoprzecinkowa zajmuje dokładnie tyle samo miejsca co 16 bitowa liczba całkowita. :) A co do dokładności to są 2 strony medalu: masz większą dokładność dla małych wartości i mniejszą dla dużych. Przy liczbach całkowitych dokładność jest taka sama w całym zakresie.
No tak ... ale tylko w wypadku, gdy 16 bitow pójdzie na mantyse, a 0 bitow na wykladnik. ;) Tylko wtedy uzyskamy dokladnosc 16 bitowego integera. Jezeli chcemy miec wiekszą dokładność przy zachowaniu tego samego zakresu to bedzie kiepsko bo brakuje nam miejsca na dane. Przyzam się, że nie słyszałem nigdy, aby na x86 używano 16 bitowego "float'a" (tymbardziej ze komprocesory pracują na conajmniej 32 bitkach).
Autorzy gier 3D od wielu lat się na to decydują, więc czemu nie PSa? :) A tak poważnie, to nie wiem jak to jest, ale nie byłby dla mnie zaskoczeniem taki sposób postępowania.
To jak najbardziej zgadza się. Pewnie główną przyczyną takiego stanu rzeczy jest ograniczona dokładność jaką oferują liczby całkowite. Dodatkowo przy wielokrotnych transformacjach scena mogła by się delikatnie rozjechać. Poza tym i tak większość liczymy w koprocesorze a on na takich liczbach własnie pracuje.
W QIII dokonano optymalizacji polegającej na rownoległym liczeniu sceny w procku i koprocesorze. Nie zdziwiło by mnie gdyby w PSie było podobnie. To znaczy część operacji na obrazie liczy procesor, a część komprocesor po dokonaniu odpowiedniego rzutowania. Ale to wcale nie znaczy, że do opisu obrazu stosujemy zmienno przecinkową reprezentacje obrazów. Po prostu zdjęcia i tak już zajmują za dużo pamięci, więc po co jeszcze ją marnotrawić - problem skali.
Co do trybu 32 bitowego to jedyne, co mnie po części przekonuje, to rozmiat typu float w większości języków programowania: 32 bity.
To chyba taki dowód nie wprost. To co mnie przekonuje to wielokrotnie wiekszy zakres funkcjonalny float'a jeśli chodzi o dokładność. Dzieki temu łatwiej jest nam opisać całą dynamikę sceny. Na dole w "absolutnych" cieniach mamy najwięcej poziomów. Na górze natomiast najmniej. Gdybyśmy użyli stałoprzecinkowych liczb dystrybucja pamięci była by mniej optymalnie wykorzystana, bo po cholere nam aż tyle danych w światłach.
Tak na chłodno przeczytałem jeszcze raz Wasze wypowiedzi i mam ochote zadać jedno pytanie: co ma piernik do wiatraka?? :)
Analitycznie dowiedliście, że liniowy 12 bitowy RAW może zawierać więcej informacji w światłach niż jest w stanie pomieścić 16 bitowy nieliniowy obrazek. Później dowiedliście, że tiff jest w stanie przenieść te informacje. A ja zapytam i co z tego? Przecież ustawiając w RAWie ekspozycje na minus nie wykonujemy triku, w którym obniżając "poprzeczke" powodujemy, że jasne partie opisane są przy użyciu większej ilości poziomów. Powodujemy to, że w ogóle one mogą załapać sie na jakikolwiek poziom, gdyż wcześniej wychodziły poza zakres LDR'a (low dynamic range - czyli zwykle 8 lub 16 bitowe łobrazki). Gdybyście mieli rację, to część chmur była by cały czas widoczna a obniżając "E" zyskiwali byśmy na szczegółowości (dzięki liniowości RAWa)!!! Jak dla mnie matryce aparatów mają wiekszą dynamikę na górze niż jesteśmy w stanie zmieścic w zwyczajnym obrazku.
No chyba, że z góry założyliście, że dokumenty 8 i 16 bitowe nie są LDRami - wtedy przyznam, że wymiękam. ;)
Stwierdzam, że muszę updatować tutka gdyż wywałowanie RAWa z ekspozycja na + rzeczywiście nie ma sensu. Nie zgodze się jednak w kwesti Waszej motywacji tego (napisaliście mniej więcej, że ciemne partie zawierają więcej pioziomów i liniowy RAW sie po prostu w całości tam mieści).
Analizując, wiele zdjęć doszedłem do wniosku, że obecne matryce aparatów nie oferują wystarczającej dynamiki aby przekroczyć od dołu zakres LDRa. Heh co więcej powszechnie wiadomo, że nawet w standardowym zakresie w cieniach nie radzą sobie najlepiej. Zastanawiam się tylko czy ta reguła obowiązuje zawsze? Hmmm może S5Pro stanowi wyjątek?
PS.
Nikogo bynajmniej nie atakuje, chciałem tylko umieścic swoje przemyślenia, gdyż uważam, że wpuściliście się troszkę w malinki... :)
Pozdrawiam
AK
Tylko wtedy uzyskamy dokladnosc 16 bitowego integera.
Tak. Ale gbydyśmy patrzyli na dokładność w sensie percepcji, to wystarczy mniej bitów i nieliniowość.
Przyzam się, że nie słyszałem nigdy, aby na x86 używano 16 bitowego "float'a" (tymbardziej ze komprocesory pracują na conajmniej 32 bitkach).
A to inna bajka. :D
To chyba taki dowód nie wprost. To co mnie przekonuje to wielokrotnie wiekszy zakres funkcjonalny float'a jeśli chodzi o dokładność. Dzieki temu łatwiej jest nam opisać całą dynamikę sceny. Na dole w "absolutnych" cieniach mamy najwięcej poziomów. Na górze natomiast najmniej. Gdybyśmy użyli stałoprzecinkowych liczb dystrybucja pamięci była by mniej optymalnie wykorzystana, bo po cholere nam aż tyle danych w światłach.
Wniosek z tego taki, że ewentualne "straty" w światłach przy ewentualnym nieliniowym formacie (bo możliwa jest opcja liniowa) są zaniedbywalne z punktu widzenia ludzkiej percepcji.
Tak na chłodno przeczytałem jeszcze raz Wasze wypowiedzi i mam ochote zadać jedno pytanie: co ma piernik do wiatraka?? :)
Analitycznie dowiedliście, że liniowy 12 bitowy RAW może zawierać więcej informacji w światłach niż jest w stanie pomieścić 16 bitowy nieliniowy obrazek. Później dowiedliście, że tiff jest w stanie przenieść te informacje. A ja zapytam i co z tego?
Ano to, że jeśli w TIFFie informacje przechowywane są w sposób liniowy i TIFF jest 16 bitowy (tudzież 32), to operacja wywoływania RAW z różną korekcją EV ma sens wątpliwy. To samo można osiągnąć z TIFFa manipulując krzywymi, a w porywach warstwami dla lokalnej aplikacji efektu.
Przecież ustawiając w RAWie ekspozycje na minus nie wykonujemy triku, w którym obniżając "poprzeczke" powodujemy, że jasne partie opisane są przy użyciu większej ilości poziomów. Powodujemy to, że w ogóle one mogą załapać sie na jakikolwiek poziom, gdyż wcześniej wychodziły poza zakres LDR'a (low dynamic range - czyli zwykle 8 lub 16 bitowe łobrazki).
Chyba mi nie powiesz, że plik 16 bitowy mą większą rozpiętość tonalną niż 8 bitowy? :) To wszystko zależy od krzywych gamma, które to wpływają na interpretację danych. Oczywiście plik 16 bitowy ma większą dokładność, niemniej nie ma problemu z zapisaniem całego zakresu tonalnego RAWa w TIFFie (16 czy 32 bitowych) czy też JPEGu. W końcu HDRy można oglądać w JPEGach. :)
Gdybyście mieli rację, to część chmur była by cały czas widoczna a obniżając "E" zyskiwali byśmy na szczegółowości (dzięki liniowości RAWa)!!! Jak dla mnie matryce aparatów mają wiekszą dynamikę na górze niż jesteśmy w stanie zmieścic w zwyczajnym obrazku.
Raczej większą dokładność, którą i tak oko ludzkie pomija, gdyż działa logarytmicznie (wykładniczy przyrost ilości światła powoduje liniowy wzrost obserwowanej jasności). Stąd stosuje się korekcję gamma, żeby na mniejszej liczbie bitów zmieścić to, co w liniowej reprezentacji zajmuje więcej.
No chyba, że z góry założyliście, że dokumenty 8 i 16 bitowe nie są LDRami - wtedy przyznam, że wymiękam. ;)
No to wymiękaj. :mrgreen: A poważnie, to zakres tonalny w obrazac nie zależy od ilości bitów, tylko ich interpretacji przez urządzenie docelowe (monitor, drukarka, rzutnik itp.). Od ilości bitów zależy natomiast dokładność odwzorowania przejść tonalnych co ma znaczenie dla urządzeń, które są w stanie je oddać (ew. w trakcie obróbki aby zminimalizować artefakty powstałe w trakcie przekształceń).
Nikogo bynajmniej nie atakuje, chciałem tylko umieścic swoje przemyślenia, gdyż uważam, że wpuściliście się troszkę w malinki... :)
Takowe i ja zamieszam. Oczywiście nie roszczę sobie praw wyroczni i byćmoże w którmyś punkcie się mylę. Jak tak, to mówcie.
akrzykalski
14-08-2007, 16:32
Ano to, że jeśli w TIFFie informacje przechowywane są w sposób liniowy i TIFF jest 16 bitowy (tudzież 32), to operacja wywoływania RAW z różną korekcją EV ma sens wątpliwy. To samo można osiągnąć z TIFFa manipulując krzywymi, a w porywach warstwami dla lokalnej aplikacji efektu.
Przy założeniu, że TIFF jest liniowy, ma zwiększoną dynamikę oraz oprogramowanie do obróbki tą liniowość wykorzystuje musiałbym jak najbardziej przyznać Ci rację. Problem w tym, że otwierając 16 bitowego TIFFa w PSie nie wiem jakbyś suwakami nie kręcił to pewnych rzeczy nie wyciągniesz. Empiryczny dowód na to że przyjęte załóżenie jest błędne (nie wiem która część). Jakby co to służe przykładami... :)
Chyba mi nie powiesz, że plik 16 bitowy mą większą rozpiętość tonalną niż 8 bitowy? To wszystko zależy od krzywych gamma, które to wpływają na interpretację danych. Oczywiście plik 16 bitowy ma większą dokładność, niemniej nie ma problemu z zapisaniem całego zakresu tonalnego RAWa w TIFFie (16 czy 32 bitowych) czy też JPEGu. W końcu HDRy można oglądać w JPEGach.
No właśnie cały czas próbuje powiedziec ze i 8 i 16 bitowe obrazy w PS mają taką samą rozpiętość tonalną, inaczej dynamikę. Co więcej dlatego mają wspólną nazwę LDR. Oczywiście, że różnią sie dokładnościa (rozdzielczością).
Chyba mi nie powiesz, że plik 16 bitowy mą większą rozpiętość tonalną niż 8 bitowy? To wszystko zależy od krzywych gamma, które to wpływają na interpretację danych. Oczywiście plik 16 bitowy ma większą dokładność, niemniej nie ma problemu z zapisaniem całego zakresu tonalnego RAWa w TIFFie (16 czy 32 bitowych) czy też JPEGu. W końcu HDRy można oglądać w JPEGach.
Otóż jest problem! :) Przyjmijmy ze 0 oznacza zgaszony punkt. Zaś 1 zaświecony na maksa. To czy mamy 8 czy 16bitów w TIFFe, jak opiszemy wartości pośrednie (liniowo czy inaczej) kompletnie tutaj nie ma znaczenia. Wywołując z RAWa zdarzają sie sytuacje, gdy otrzymujemy punkty dla których wartości "po przetłumaczeniu" są większe od 1. Są one poza dostępną dynamiką. Obniżanie ekspozycji powoduje to, że te punkty zaczynają mieć mniejsze wartości od 1 i mogą być rozróżnialne. Wszystko przez to, że matryca ma większą rozpiętość tonalną, niż jesteśmy w stanie upchać do LDR.
Z tymi JPEGami, heh to żart? Przecież oglądamy HDR'a ale po zmapowaniu tonalnym. Czyli mamy do czynienia z sytuacją gdy wszystko zostało spłaszczone do LDR'a.
Zupełnie inna sytucja jest z 32 bitowymi TIFFami (floating point tiff). Tutaj spokojnie jesteśmy w stanie upchać całego RAWa z powodu zwiększonej dynamiki. Tak naprawde to są to HDRy. :) Hmmm jedyny soft jaki znam, który wywółuje 32 bitowego tiffa bezpośrednio z RAWa to Photomatrix Pro (niestety z różną jakością).
No to wymiękaj. A poważnie, to zakres tonalny w obrazac nie zależy od ilości bitów, tylko ich interpretacji przez urządzenie docelowe (monitor, drukarka, rzutnik itp.).
Śmiem twierdzić, że zakres tonalny w strukturze danych obrazów właśnie jest z góry ograniczony. To podstawa do moich wniosków. W LDRach (czyli JPEG, TIFF 8Bit i 16Bit) jest znacznie mniejszy niz w HDRach (np Floating Point TIFF). Nawet te ostatnie mają ten zakres gdzieś tam ograniczony.
OK, ale żeby nie było tak gołosłownie. Mogę podesłać Ci RAW'a ze zdjęciem z mojego tutoriala. Wywołasz sobie bez modyfikowania ekspozycji z niego TIFFa 16 bitowego. Skoro według Ciebie nie posiada on ograniczonej dynamiki (czyli wszystko z RAWa można wepchać) to niezależnie od "liniowości" ;) powinieneś móc wyciągnąć przynajmniej namiastkę przepalonych chmurek. Jak ci się uda - przyznam, że się myliłem. :D Co ty na to?
Pozdrawiam
AK
Wywołując z RAWa zdarzają sie sytuacje, gdy otrzymujemy punkty dla których wartości "po przetłumaczeniu" są większe od 1. Są one poza dostępną dynamiką.
?? Może przykład, bo jakoś nie za bardzo jestem sobie w stanie to wyobrazić. Czyżby w RAW było zapisane więcej, niż widzi ludzkie oko? Każdy domknięty zakres można przetłumaczyć na przedział [0,1]. Oczywiście jak sobie zdefiniujesz przekształcenie, które pobcina ci górę, czy dół pasma za pomocą krzywych (może to być użyteczne) to już twoja sprawa. No ale powiedzenie, że w RAW są jakieś informacje, które można wydobyć jedynie poprzez obniżenie ekspozycji jest dla mnie jakąś herezją. No chyba, że czegoś nie wiem.
Z tymi JPEGami, heh to żart? Przecież oglądamy HDR'a ale po zmapowaniu tonalnym. Czyli mamy do czynienia z sytuacją gdy wszystko zostało spłaszczone do LDR'a.
Ja bym to nazwał zmniejszeniem rozdzielczości tonalnej. Oczywiście jest to stratne. Niemniej istniejące urządzenia wyświetlające póki co nie są w stanie oddać rzeczywiście zarejestrowanych jasności, więc to nie problem. Chodzi mi o to, że to nie kwestia zakresu, który jest umowny, tylko rozdzielczości. I do tego dochodzi jeszcze rozkład tej rozdzielczości, który jest inny dla RAW (liniowy), a inny dla JPEG (linowy z korekcją gamma, czyli de facto logarytmiczny).
Śmiem twierdzić, że zakres tonalny w strukturze danych obrazów właśnie jest z góry ograniczony. To podstawa do moich wniosków. W LDRach (czyli JPEG, TIFF 8Bit i 16Bit) jest znacznie mniejszy niz w HDRach (np Floating Point TIFF). Nawet te ostatnie mają ten zakres gdzieś tam ograniczony.
Ja uważam, że zakres nie jest wogóle ograniczony. Nawet 1 bitowy, monochromatyczny obraz mnoże mieć zakres 20EV. To kwestia umowy. Z pewnością zaś jest ograniczona rozdzielczość.
OK, ale żeby nie było tak gołosłownie. Mogę podesłać Ci RAW'a ze zdjęciem z mojego tutoriala. Wywołasz sobie bez modyfikowania ekspozycji z niego TIFFa 16 bitowego. Skoro według Ciebie nie posiada on ograniczonej dynamiki (czyli wszystko z RAWa można wepchać) to niezależnie od "liniowości" ;) powinieneś móc wyciągnąć przynajmniej namiastkę przepalonych chmurek. Jak ci się uda - przyznam, że się myliłem. :D Co ty na to?
To zarzuć. Może się czegoś nauczę. :) Na PW podeślę maila. Nie wiem tylko, czy mój software pozwoli na obsługę 16 bitowych TIFFów (DxO Optics + GIMP). W każdym razie spróbuję osiągnąć podobny efekt (znaczy wyciągnąć szczegóły z chmur bez korekcji ekspozycji RAWa). Z tym, że może to trochę to może potrwać, bo mam na karku pojedynek, a i urop tuż tuż i będę poza "zasiągiem" internetu. :)
akrzykalski
15-08-2007, 12:29
Kolego milo_ja przemyślałem sobie na spokojnie jeszcze raz wszystko i muszę przyznać, że w kilku kwestiach się myliłem. :(
Oto takie podsumowanie na krótko mojego aktualnego stanowiska:
1. Jako postawę do moich wniosków przyjąłem, że zakres tonalny LDRa jest ograniczony. Muszę jednak zgodzić się z Tobą, że jest to nieprawdą! Zakres na jakim pracujemy jest rzeczywiście rzeczą umowną. Sposobem opisu obrazu ograniczamy natomiast maksymalną dynamikę. W przypadku 12 bitowego CCD teoretyczny maksymalny zakres dynamiki obrazu wynosi 4096:1. W praktyce ze względu na szumy jest to mniej, pewnie coś ok 1024:1. 16 bitowy TIFF posiada maksymalną dynamikę 65 536:1, tak więc możemy wykonać liniowe przekształcenie które wszystko co mamy w RAWie zapakuje nam do TIFFa. Tutaj miałeś 100% racje.
2. Cała kość niezgody pomiędzy nami wynika z tego, że ja poparty empirycznymi doświadczeniami nie mogłem zaobserwować tego co Ty głosiłeś. Nie udało mi się stworzyć bez majstrowania suwakami takiego 16 bitowego tiffa, który zawierałby wszystkie dostępne informacje. Na szczęscie udało mi się na sieci znaleźć odpowiedz na przyczynę takiego stanu rzeczy. Zacytuje tutaj wyjaśnienie:
› Can't I just create the exposures from one RAW file?
Not really. Your RAW file contains data captured by the sensors for only one exposure. The total dynamic range you can reconstruct from one photo converted with different exposure settings can never be more than the dynamic range captured by your camera, and this is rather limited (see above).
When you are using only one exposure to capture the scene, your RAW file is already your HDR image.
Converting the RAW file to images with different exposure levels is a bit like slicing the dynamic range of the RAW into several parts. Combining the parts back into an HDR image will at best re-produce the dynamic range of the initial RAW file.
That said, if you are using a good RAW converter to derive fake exposures from a single RAW file, you will probably notice that the HDR image created from the fake exposures shows more dynamic range than the pseudo-HDR image obtained by converting the single RAW file directly. This is because your RAW converter includes a good noise reduction function, and this has an important effect on the dynamic range. You RAW converter may also include the ability to continue to retrieve highlights details when one or two of the color channels have already reached saturation.
So, a good RAW converter includes functions designed to optimize the dynamic range retrieved from the raw sensor data, but this does not change the fact that the dynamic range of a RAW file is limited to one exposure only. Unless the dynamic range of your scene is low, you will need to take more than one exposure to create an HDR image of the scene.
Tak więc podsyłam ci RAWika. Mi ani w CaptureNX, ani w ACR nie udało się bez kręcenia suwakami(exposure, recovery itp) stworzyć TIFFka, który zawierałby wszystko. Oczywiście w ACR mogłem przy pomocy recovery to odzyskać, no ale to już jest ingerowanie w ekspozycje (recovery robi to o czym mowa w ostatnim pogrubionym zdaniu). Używasz innego softu, ciekaw jestem czy tam ci się uda. Tylko pamiętaj - nic nie kręcimy przy rawie, tylko zapisujemy 16 bitowego TIFFa i dopiero tam zaczynamy czarować.
Btw. dla zainteresowanych, sporo odpowiedzi na poruszane tutaj zagadnienia uzyskałem na stronie: http://www.hdrsoft.com/resources/dri.html
Tak więc póki co podsumowywując:
Kolego milo_ja, w teoretycznej części zwracam ci honor. Poczyniłem błąd w założeniach - pisałem o tym na początku posta. Nadal jednak uważam, że znane mi wywoływaczki RAW tworząc 16 bitowego TIFFa nie przenoszą wszystkich informacji z RAWa (pomimo tego, iż tak naprade mogły by tak robić, gdyż format jest wystarczająco pojemny).
Pozdrawiam
AK
A może takie przyziemne pytanie: Jaką wersją PS trzeba miec aby korzystac z HDR bo ja mam CS i nie bardzo widzię opcję Marge to HDR
Tak więc póki co podsumowywując:
Kolego milo_ja, w teoretycznej części zwracam ci honor. Poczyniłem błąd w założeniach - pisałem o tym na początku posta. Nadal jednak uważam, że znane mi wywoływaczki RAW tworząc 16 bitowego TIFFa nie przenoszą wszystkich informacji z RAWa (pomimo tego, iż tak naprade mogły by tak robić, gdyż format jest wystarczająco pojemny).
Pewnie jest to spowodowane tym, że te informacje są zdegradowane i to, co z nich idzie odzyskać to obraz monochromatyczny. Taką mam przynajmniej koncepcję. :)
Co do wywoływania, to niestety obiłem się o mur: GIMP nie obsługuje trybu 16 bitowego. W 8 bitowym to mi się udało odzyskać jakąś purpurową poświatę w prawym górnym rogu i zarys chmur w tym rogu. :( Jakby nie patrzeć sprawdza się stara zasada: nie licz na RAW, licz na siebie, bo nie zawsze RAW może ci d.... uratować. ;)
akrzykalski
16-08-2007, 21:45
A może takie przyziemne pytanie: Jaką wersją PS trzeba miec aby korzystac z HDR bo ja mam CS i nie bardzo widzię opcję Marge to HDR
O ile pamiec mnie nie myli to od CS2 masz ta opcje.
O ile pamiec mnie nie myli to od CS2 masz ta opcje.
Tak myślałem ale się jeszcze łudziłem :(
akrzykalski
16-08-2007, 22:08
Pewnie jest to spowodowane tym, że te informacje są zdegradowane i to, co z nich idzie odzyskać to obraz monochromatyczny. Taką mam przynajmniej koncepcję. :)
Mniej wiecej to chcialem przekazac umieszczajac wczesniej angolojezyczny cytat (w szczegolnosci ostatnie wyboldowane zdanie).
Co do wywoływania, to niestety obiłem się o mur: GIMP nie obsługuje trybu 16 bitowego. W 8 bitowym to mi się udało odzyskać jakąś purpurową poświatę w prawym górnym rogu i zarys chmur w tym rogu. :( Jakby nie patrzeć sprawdza się stara zasada: nie licz na RAW, licz na siebie, bo nie zawsze RAW może ci d.... uratować. ;)
No tak - w tym przypadku z GIMPem bedzie sciana.
Rozumiem, ze nadal podtrzymujesz stanowisko ze z 16 bitowego TIFFka w odpowiednim sofcie to wyciagniesz. Ja cos tam jeszcze kombinowalem w temacie i kicha, namiastka chmur to az nadto powiedziane. Moze wystawisz gdzies swojego tiff (16 bits) - sprobuje to u siebie ogladnac - jakby cos tam rzeczywiscie bylo to oznaczalo by, ze wywolywaczka wywolywaczce wybitnie jest nierowna. ;)
Co moze wydac sie ciekawe.... w ACR i CNX mamy do podgladu histogram, w ktorym dopoki nie uzyjemy recovery lub ekspozycji na minus mamy ewidentne przepaly (uciecie) z prawej strony. Dopiero po zjechaniu suwaczkami zaczyna on zmieniac ksztalt i lagodnie opadac. To kolejny "dowod nie wprost" na poparcie mojej tezy. ;)
nie patrzeć sprawdza się stara zasada: nie licz na RAW, licz na siebie, bo nie zawsze RAW może ci d.... uratować.
Ja po calym tym watku, ech i przemyslaniach na temat magii rawa stwierdzilem, ze przecenialem ten format. Do porzadnego HDRa bez bracketingu ani rusz. Na fuksa nie ma co liczyc - lepiej wczesniej sie zastanowic, niz pozniej kitwasic sie obrobka, heh... ;)
Pozdrawiam
AK
akrzykalski
16-08-2007, 22:10
Tak myślałem ale się jeszcze łudziłem :(
Zawsze moze na trialu sie pobawic. Ewentualnie uzyc innego softu do tworzenia HDRow - np Photomatix.
Pozdrawiam
AK
Moze wystawisz gdzies swojego tiff (16 bits) - sprobuje to u siebie ogladnac - jakby cos tam rzeczywiscie bylo to oznaczalo by, ze wywolywaczka wywolywaczce wybitnie jest nierowna. ;)
To jest ponad 50MB :-? Chyba prościej bedzie, jak obsłużysz się sam i ściągniesz DxO Optics. Można go legalnie używać w pełnej wersji przez 21 dni (jak zmieniasz datę systemową przed uruchomieniem, to jeszcze dłużej ;) ), a jest naprawdę niezły.
Co moze wydac sie ciekawe.... w ACR i CNX mamy do podgladu histogram, w ktorym dopoki nie uzyjemy recovery lub ekspozycji na minus mamy ewidentne przepaly (uciecie) z prawej strony. Dopiero po zjechaniu suwaczkami zaczyna on zmieniac ksztalt i lagodnie opadac. To kolejny "dowod nie wprost" na poparcie mojej tezy. ;)
Też to zauważyłem. A swoją drogą, to jak chciałem poprzez nagięcie krzywych uzyskać chmurki (gamma 0.1), to histogram wyglądał jak armia pikienierów. :)
Ja po calym tym watku, ech i przemyslaniach na temat magii rawa stwierdzilem, ze przecenialem ten format. Do porzadnego HDRa bez bracketingu ani rusz. Na fuksa nie ma co liczyc - lepiej wczesniej sie zastanowic, niz pozniej kitwasic sie obrobka, heh... ;)
:)
BlingBling
23-08-2007, 22:39
''Tematem dzisiejszej lekcji jest'' uhh wakacje jeszcze mamy :]]]]
poradnik fajny na pewno sie pobawie w PS :))
Wielkie dzięki akrzykalski. Tutorial napisany przejrzystym językiem. A oto efekt dzięki Twoim poradom.
Before:
http://img102.imageshack.us/img102/9986/beforebz4.jpg
After:
http://img122.imageshack.us/img122/6325/afterur9.jpg
Jeszcze raz fęks.
akrzykalski
01-09-2007, 12:28
O... miło, że moja gwara mokradłowa komuś sie przydała.
A co do zdjęcia ... heh widze, że linie wysokiego napięcia na ktoryms etapie obróbki wcielo?? :)
IMO niebo wygląda sympatycznie natomiast cały dół jakby nie był prawny w perwolu. Proponuje nałożyć pierwotne zdjęcie na fotke after i maską wyeksponować tylko HDRowe niebo. Powinno wtedy wyglądać lepiej!
Pozdro
AK
... heh widze, że linie wysokiego napięcia na ktoryms etapie obróbki wcielo?? :)
Może miała za wysoką dynamikę. ;)
akrzykalski
01-09-2007, 21:03
Może miała za wysoką dynamikę. ;)
Eeee, ja raczej starał bym się doszukać tutaj jakiegoś świstaka ze sreberkiem. :lol:
AK
Podobno świstaki już nie zawijają w sreberka... tak słyszałem.
Ja tam jestem stwór oczny dlatego lubie sobie czasami sobie coś strzelić ;)
Ostatnio też się zacząłem bawić HDR'em. Znalazłem tutka ja do tego wykorzystac Photomatic Pro za jedyne 400 zł i dożywotnia zabawa gra.
Zawsze jednak przy obróbce fotek mam dylemat. Czy to co ja sobie widze i jak sobie przy tej fotce pogrzebie to jest to jak to powinno wyglądać. Najchętniej to podesłał bym 3 RAW'y jednemu z wyżej wypowiadających się speców i poczekał aż prześle mi swój rezultat dla porównania z tym co mi wyszło, pożniej ewentualna korekta tego co zrobiłem źle zgodnie ze wskazaniami mastera i był bym szczęśliwy. Coż tak słodko pewnie to się nie da.
Więc dla przykładu ładuje tu 3 fotki bazowe narodzone z 3 raw'ów wygenerowane przez plug'in z PS CS2 oczywiście z synchronizacją, pożniej załadowałem do Photomatica, wygenerowałem HDR'a z moimi widzimisie modyfikacjami, no i na koniec to co juz obrobiłem w PS (maski etc bo spory ruch był w jednym miejscu i zdecydowałem się nałożyć jedną fotke z mniej poruszonymi elementami czyli wysoką trawą rosnącą z niba do ziemi). Oto efekt:
https://forum.nikoniarze.pl//brak.gif
źródło (http://www.2see.pl/images/forum_nikon/potok/DSC_8215.jpg)
https://forum.nikoniarze.pl//brak.gif
źródło (http://www.2see.pl/images/forum_nikon/potok/DSC_8216.jpg)
https://forum.nikoniarze.pl//brak.gif
źródło (http://www.2see.pl/images/forum_nikon/potok/DSC_8217.jpg)
to była baza, teraz czas na photomatic
https://forum.nikoniarze.pl//brak.gif
źródło (http://www.2see.pl/images/forum_nikon/potok/DSC_8217_5_6_tonemapped.jpg)
i wersja ostateczna z PS'a
https://forum.nikoniarze.pl//brak.gif
źródło (http://www.2see.pl/images/forum_nikon/potok/DSC_8217_5_6_ready.jpg)
i teraz poprosze o rade co jest źle... :mrgreen:
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.