HDR "kaszalota"

[milo_ja]

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.

[milo_ja]

Znalazłem taką stronkę: http://www.cdrom.pl/index.php?title=...ych_ekspozycji 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.

[milo_ja]

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]

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

[milo_ja]

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.

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

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. Co ty na to?

Pozdrawiam
AK

[milo_ja]

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

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

[tzk]

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

[milo_ja]

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