Wersja do druku
Tomasz: Udowadniasz, że wszystko po kolei jest liniowe - to dlaczego 18% światła jest zapisane jako 50%?
Jest tak (w przybliżeniu) - ze źródła dane trafiają na matrycę i do rawa - liniowo. Potem są upychane nieliniowo do jpga (tu się robi z 18% wspomniane 50%). Następnie przy wyświetlaniu jpga następuje kolejna nieliniowa transformacja - aby odkręcić tą poprzednią.
PS. W przeciwieństwie do tego, od czego zaczął Janusz, jest zupełnie nieistotne jak działają nasze oczy.
Pomijamy fakt jak widzą nasze oczy, bo to w zasadzie nieistotne.
Zanim przejdę do matrycy, przyjrzyjmy się monitorowi. Monitory CRT miały charakterystykę odwrotną w zakresie od y=x^1/1,8 do y=x^1/2,5 - tak z grubsza. M$ przyjął za średnią 2,2 i tak dobrał charakterystykę systemu, aby wypadkowa była liniowa czyli x=y. Jak wiemy gamma dla Windows jest 2.2 tj. y=x^2.2.
Apple chciałbyć oryginalny i tak produkował monitory aby miały charakterystykę zbliżoną do y=x^1/1,8 więc gamma dla systemu była 1.8 - aby nie pasowały monitory z PC itp.
Czyli wypadkowa system-monitor w każdym przypadku ma być/powinna być liniowa.
(jeśli co do tego macie wątpliwości proszę zajrzeć do x-rite i dokumentówy wystawionych na ich stronie w postaci pdf).
Skoro na tym etapie mamy zachowaną liniowość, wszystko to co trafi musi być już liniowe czyli np. JPG z aparatu - nie może być inaczej. Nie może ten JPG być jakoś ponaginany jeśli zależy nam na wierności.
Jeśli robimy zdjęcie dobierając odpowiednio ekspozycje, to to ile światła odbija jakaś tam szarość w ogóle nas nie obchodzi, bo tyle światła trafia do naszych oczu, jak i na matryce. I niech sceną będą 3 prostokąty: czerń, szarość 18%, biel 100%. Do naszych oczu trafi więc 0, 18% odbitego światła i 100% odbitego światła.
Chcemy, aby wyświetlone zdjęcie na monitorze też tak "świeciło". Matryca liniowo zarejestruje scene i to 3 prostokąty przekarze liniowo dalej do JPG, którego następnie wyświetlimy na monitorze. W JPG będziemy widzieli czarny RGB=000, szary 18% RGB=46.46.46 i biały 100% RGB=255.255.255.
Po co komplikować sprawe? Żeby zachować wierność musi być zachowana w miarę liniowość - nie ma innej możliwości.
Wszystko prawda, z wyjątkiem tego, że 18% jasności w jpgu zapisze się jako 50% :) RGB=128,128,128. Z powodów antropicznych.
Tak, Tobie w głowie (-:Cytat:
Zamieszczone przez Tomasz Urbanowicz
To nie jest założenie. To jest fakt.Cytat:
Po pierwsze założenie jest że matryca jest liniowa
Ale oczy nie widzą liniowo, i to jest drugi fakt.Cytat:
Skoro tak, to szarość 50% trafi na matryce tak samo jak do naszego oka tj. 18% odbitego światła. Dlaczego ma do matrycy trafić inaczej?? Trafi tak samo: czy zarówno do nas, jak i do matrycy będzie przy szarości 50% - 18% odbitego światła.
Zacznijmy może dla utrudnienia odróżniać % dla człowieka (w tych samych zapisywać będziemy sygnał) i % natężenia światła odbitego (względnie, dla danej sceny oczywiście).
%c(złowieka) i %s(wiatła)
szarość 50%s trafi na matrycę jako 50%s, ale dla nas to będzie bardzo jasny szary, tak około 75%c.
BARDZO JASNY ODCIEŃ ZOSTANIE ZAPISANY ZALEDWIE JAKO ŚREDNI!
Po to, by lepiej wykorzystać dostępną przestrzeń w pliku graficznym. Nie pytaj mnie dlaczego tak jest, ale tak jest od bardzo dawna, że informacja w pliku graficznym odpowiada mniej więcej temu, co widzi oko.Cytat:
Po co więc ma być przekształcenie nieliniowe przy konwersji? Nie ma IMO czegoś takiego, bo to byłoby bez sensu. Sens by był wtedy, gdyby matryca wyłapała więcej niż 18% światła, ale przecież nie wyłapie, bo 50% szarość odbija tylko 18%, a matryca jest liniowa więc na "wyjśćiu" matrycy będzie również "18%".
I to bardzo dobrze, bo po co marnować miejsce na rejestrowanie tysięcy zmian natężenia światła w jasnych partiach obrazu, skoro normalnie nikt ich nie widzi?
Teraz pewnie znowu Ci trochę zamieszam, ale trudno. Posłużę się mianowicie liniową skalą pomiaru natężenia światła, Luxami.
Między 0 z 1EV jest 2.5Lux, między 1 a 2EV - 5 lux, między 2 a 3 EV - 10lux, zaś między 13 a 14 EV (słoneczny dzień) jest już około 20000 luxów różnicy. Lux to skala liniowa, w takiej rejestruje matryca. Ma to sens? Nie ma, bo dla nas zmiana o 1EV to dwukrotnie jaśniej / ciemniej.
Dlatego dawno temu ktoś mądry wymyślił, że informacja w pliku graficznym jest zgodna z tym co widzi człowiek a nie sensor zliczający fotony.
Dlatego potrzebna jest ta konwersja.
Proszę: (fragment dcraw.c, komentarze moje)Cytat:
Jeśli nadal będziesz się przy tym upierał, pokaż mi w jakimś algorytmie RAW -> JPG taką nieliniową konwersje.
FORCC to po prostu define robiący for() dla wszystkich kolorów czyli najprawdopodobniej 3.Kod:/* przygotowanie tablicy konwersji, fragment */
white *= 8 / bright;
for (i=0; i < 0x10000; i++) {
r = i / white;
val = 256 * ( !use_gamma ? r :
#ifdef SRGB_GAMMA
r <= 0.00304 ? r*12.92 : pow(r,2.5/6)*1.055-0.055 );
#else
r <= 0.018 ? r*4.5 : pow(r,0.45)*1.099-0.099 );
#endif
if (val > 255) val = 255;
lut[i] = val;
/* (...) */
/* konwersja gamma tylko podczas zapisu 8 bit: */
for (row=0; row < height; row++, soff += rstep) {
for (col=0; col < width; col++, soff += cstep)
if (output_bps == 8)
FORCC ppm [col*colors+c] = lut[image[soff][c]];
else FORCC ppm2[col*colors+c] = image[soff][c];
if (output_bps == 16 && !output_tiff && htons(0x55aa) != 0x55aa)
swab (ppm2, ppm2, width*colors*2);
fwrite (ppm, colors*output_bps/8, width, ofp);
}
}
To jest fragment odpowiedzialny za konwersję do 8 bitowego wyjścia z _gammą_ czyli dla ludzi. Można też bez tego zapisać jako liniowy 16 bit. Sam sobie wtedy podciągniesz krzywą krzywymi.
Mam też inne, ale tamtych nie mogę tu wklejać (-:
Wszystko prawda. Ale przy luminancji 50% monitor emituje przy tym 18% światła.Cytat:
Trzecia sprawa to ta gamma. Wypadkowa monitor-system (...) luminancja wskazywana jest na 50%.
W zasadzie to ogromnie zajebiście bardzo cholernie mocno istotne.Cytat:
Zamieszczone przez Tomasz Urbanowicz
Oczywiście, ze krowa.Cytat:
(...)
Czyli wypadkowa system-monitor w każdym przypadku ma być/powinna być liniowa.
(jeśli co do tego macie wątpliwości proszę zajrzeć do x-rite i dokumentówy wystawionych na ich stronie w postaci pdf).
Skoro na tym etapie mamy zachowaną liniowość, wszystko to co trafi musi być już liniowe czyli np. JPG z aparatu - nie może być inaczej. Nie może ten JPG być jakoś ponaginany jeśli zależy nam na wierności.
Tzn, tak, ma być liniowa. Liniowa względem naszej percepcji. Liniowy sygnał, tak ma być, tak jest w pliku, tak i już. Masz rację.
Gamma monitora (nie systemu! Ona w monitorze jest i nic o niej nie wiesz, możesz ją tylko zmierzyć fikuśnym xritem lub innym szitem) ma za zadanie pocichutku i nic Ci nie mówiąc wyemitować tyle energii, abyś ów sygnał zobaczył tak, jak był zapisany.
Można by tak zrobić, ale kiedyś nie było takich ilości pamięci ani mocy obliczeniowych jak dziś, i wymyślono, że po co marnować miejsce, lepiej po prostu olać informację która dla nas nie istnieje - czyli zapisujmy informację tak jak ją widzimy. Patrz wyżej. Dlatego szary 50%, czyli odbijający 18% światła zapisany jest jako 50%. Bo tak widzisz, koniec, korpka!Cytat:
(...)
Chcemy, aby wyświetlone zdjęcie na monitorze też tak "świeciło". Matryca liniowo zarejestruje scene i to 3 prostokąty przekarze liniowo dalej do JPG, którego następnie wyświetlimy na monitorze. W JPG będziemy widzieli czarny RGB=000, szary 18% RGB=46.46.46 i biały 100% RGB=255.255.255.
Po co komplikować sprawe? Żeby zachować wierność musi być zachowana w miarę liniowość - nie ma innej możliwości.
Nie, to przybliżenie tylko.Cytat:
Zamieszczone przez minek
O, i to jest podstawa wszystkiego.Cytat:
Dlatego dawno temu ktoś mądry wymyślił, że informacja w pliku graficznym jest zgodna z tym co widzi człowiek a nie sensor zliczający fotony.
Dlatego potrzebna jest ta konwersja.
Zupełnie nie istotne. Ważne jest tylko to, że ktoś tak sobie wymyślił. Oczy są tylko motywacją,Cytat:
W zasadzie to ogromnie zajebiście bardzo cholernie mocno istotne.
@minek:
Chwilka, chwilka....
Zatrzymajmy się jeszcze na samym początku tego całego procesu tj. tej liniowej rejestracji przez matrycę. Weźmy taki przykład z 3 prostokątami: czarny, szary 50% i biały 100% (scena oczywiście jest oświetlona jakoś). Od czarnego (zakładam idealny czarny) nie odbije się światło, od szarego odbije się 18%, od białego odbije się 100% padającego światła. Pomijając całkowicie fakt jak widzimy (na tym etapie) i przyjmując że nie ma żadnego przekształcenia nieliniowego, do naszych oczu jak i na matryce wpada to odbite światło od sceny: 0%, 18%, 100%. Matryca zarejestruje to liniowo (i chwała jej za to), następnie przetwornik przetworzy to na plik np. JPG który sobie wyświetlimy. Plik ten wyświetlony na monitorze wyświetli nam 3 prostokąty, które będą odpowiednio świeciły: 0%, 18%, 100% jasności monitora.
I teraz patrzymy na scenę jak i na wyświetlony plik. Do naszych oczu ze sceny docierają 3 prostokąty (z odbicia światła): 0%, 18%, 100%, a z monitora dociera "świecący" już plik: 0%, 18%, 100%. A jak człowiek widzi jest IMO mało istotne, bo oba przypadki zobaczy/zarejestruje/przetworzy przecież TAK SAMO.
TomaszU: Właśnie tak. Ale plik jpg będzie miał 0,0,0; 128,128,128; 255,255,255. Z powodu takiej właśnie konwencji. Ktoś sobie to tak wymyślił, że będzie lepiej i dzięki temu 255 poziomów na kanał będzie lepiej rozdysponowane.
Monitory, drukarki i wszelkie piździastwo jest kalibrowane nieliniowo, stąd liniowo rejestrowany obraz z aparatów, skanerów i inszych przetworników musi być poddawany stosownej korekcji:
Przy 128,128,128 mamy ok. 22% jasności, bo standardowo kalibruje się monitory do gamma 2,2 i popularne przestrzenie zakładają prekompensację danych do gammy 1/2,2, gdybyśmy jednak skalibrowali monitor do TRC L* (z modelu ludzkiej percepcji CIE L*a*b), to oczywiście przy 128,128,128 dostalibyśmy nasze 18%.
Dowód: mamy monitor skalibrowany do gamma 2,2, zatem połowa zakresu jasności - 0,5 jest zatem podnoszona do potęgi 2,2 co wynikowo daje wartość 0,218. I teraz pytanie - ile cd/m^2 daje monitor skalibrowany do gamma 2,2/100cd/m^2?:
Hmm... Macie racje jakoś :)
Zrobiłem test EyeOne i wyszło mi, że przy RGB=128.128.128 jest ok. 18% z jasności monitora - muszę to sobie jakoś poukładać w głowie :)
OK, chyba powoli wszystko staje się jasne.
Proszę mi na koniec wytłumaczyć jak to jest, iż wielu fotografów obrabia swoje zdjęcia pod OsX, który raczej powinien być skalibrowany na gamme 1.8, (Windowsy na 2.2).
Wynika z tego, że inaczej ten sam JPG będzie wyglądał pod OsX a inaczej pod Windowsem i to dość znacznie. Gdzie tu jest psina pogrzebana? :)
@czornyj:
Pod Windowsem proponujesz kalibrować na gamme: L, sRGB czy też 2.2?
Zdjęcie zapisane w RAW zapisane jest w sposób liniowy, tj. gamma=1.0. Wywołując RAW dane są renderowane do jednej z syntetycznych przestrzeni edycyjnych, gdzie dane są już kodowane nieliniowo, tj:Cytat:
Zamieszczone przez Tomasz Urbanowicz
dla sRGB - gamma ~2.2
dla AdobeRGB gamma 2.2
dla ProPhoto gamma 1.8
dla ECI v.1 gamma 1.8
dla ECI v.2 L*
Każda sytetyczna przestrzeń edycyjna zawiera tagi TRC, w których zawarta jest informacja, do jakiej gradacji zostały wyrenderowane dane naszego zdjęcia.
Kalibrując i oprofilowywując monitor również uzyskujemy profil zawierający informację o tym, jaka jest gradacja naszego monitora.
I teraz - moduł zarządzania barwą otwierając dane zdjęcie porównuje TRC przestrzeni zdjęcia z TRC przestrzeni monitora, a następnie dokonuje stosownych kompensacji.
Ogólnie zatem niezależnie od tego, przy pomocy jakiej gammy zakodujemy gradację jasności naszego zdjęcia, CMS zadba o to, by zostało ono poprawnie wyświetlone.
Oczywiście - w przypadku środowiska pozostającego poza CMS-em jasność zdjęcia wyrenderowanego do przestrzeni o TRC odmiennej od TRC, do której skalibrowaliśmy nasz monitor będzie zafałszowana.
Gamma 1.8 już dawno nie jest "natywną" gammą dla OS X - to pozostałość po czasach przedCMS-owych, gdy monitory Apple były kalibrowane do gamma 1.8, bo taka TRC odpowiadała TRC drukarki Apple LaserWriter. Współczesne monitory ACD są już kalibrowane do gamma 2.2. Niezależnie jednak od tego z uwagi na sposób działania współczesnych systemów CMS nie ma to większego znaczenia (przynajmniej w aplikacjach wyposażonych w moduł zarządzania barwą).
Dawno, dawno temu próbowałem znaleźć odpowiedź na filozoficzne pytanie, do której gradacji najlepiej kalibrować monitor - przeczytałem na ten temat całkiem sporo, stoczyłem wiele interesujących dyskusji i jestem jeszcze głupszy, niż byłem. Ma to mz. jednak znaczenie na bardzo wysokim poziomie abstrakcji i dla sprzętowo kalibrowanych paneli z >8 bitową matrycą i programowalną, 12-14 bitową LUT. W przypadku monitorów "cywilnych" i pracy w aplikacjach z zarządzaniem barwą kalibracja monitora do zadanej gradacji jest bez większego znaczenia, równie dobrze można go kalibrować do gradacji natywnej (tj. po prostu oprofilować bez wprowadzania korekty do LUT karty graficznej), CMS tak czy owak dokona podczas wyświetlania stosownej korekty.
przepraszam, a czy z tego wątku nie wynika przypadkiem, że nie należy niedoświetlać scen ciemniejszych niż 18%, bo tracimy dane? taka próba przełożenia akademickiej dyskusji na praktykę...
Trochę tak, ale nie do końca. Ważna jest rozpiętość sceny. Grunt to nie prześwietlić świateł. Ale jeśli to nie grozi, to właśnie warto prześwietlać ciemne zdjęcia - jest to tak zwane ustawianie ekspozycji (lub histogramu ;) ) do prawej.Cytat:
Zamieszczone przez airhead
acha... czyli stara zasada, że czarne niedoświetlamy nie ma zastosowania na cyfrze? a te mdłe czernia trzeba potem malować na kompie?
I tak i nie. Korygować na kompie to trzeba każde zdjęcie, inaczej nie warto kupować lustrzanki. W takiej sytuacji poprawienie jasności całego zdjęcia jest naturalnym krokiem przy wywoływaniu rawa lub obróbce jpga.
Zasada o niedoświetlaniu często musi być jednak uwzględniana. Ponieważ mało które zdjęcie jest całe czarno-ciemne, to trzeba uważać na światła. Naświetlenie czerni jak szarości często wyjara światła.
To ustawiać aparat przed zrobieniem zdjęcia trzeba, bo inaczej to nie ma sensu kupować żadnego. A tak w ogóle najlepiej powiedz to reporterom ;]Cytat:
Zamieszczone przez Tomasz Golinski
Da też paskudną, burą czerń. Nie wiadomo nawet, które gorsze. Wynikają jakieś wnioski z tej technicznej dyskusji? Bo za zasadę prześwietlania czerni to dziękuję :PCytat:
Zasada o niedoświetlaniu często musi być jednak uwzględniana. Ponieważ mało które zdjęcie jest całe czarno-ciemne, to trzeba uważać na światła. Naświetlenie czerni jak szarości często wyjara światła.
Jest rzeczą oczywistą, że ETTR jest techniką wymagającą późniejszej obróbki i optymalne rezultaty daje tylko w przypadku rejestracji zdjęć w RAW. Dla reportera, który rąbie w jpegu i nawet nie ogląda rezultatu przed wysłaniem do redakcji technika ta jest może bez znaczenia (choć graficy z przygotowalni otrzymujący potem ten materiał mogliby już mieć inne zdanie). Wysycenie czerni to kwestia przesunięcia jednego suwaczka w ACR czy innym konwerterze - trwa to 0,5 sekundy.Cytat:
Zamieszczone przez airhead
Wnioski z tej dyskusji są proste - wystarczy mieć elementarną wiedzę nt. fotografii i obróbki cyfrowej, uważnie wszystko przeczytać i sobie je wyciągnąć, ale podsumuję jeszcze raz:
- Matryca optymalnie rejestruje dane w zakresie świateł i półtonów. Jeśli rozpiętość tonalna sceny jest mniejsza niż rozpiętość tonalna matrycy, to należy dążyć do tego, by jak najwięcej danych zostało zarejestrowane w zakresie odpowiadającym światłom i półtonom. Metoda ta pozwala na forsowniejszą obróbkę zarejestrowanego materiału. W praktyce jej stosowanie sprowadza się do obserwacji histogramu zarejestrowanego zdjęcia i dążenia do tego, by wykres rozpoczynał się możliwie blisko prawej jego strony - stąd nazwa ETTR (Exposure To The Right - ekspozycja na prawą stronę (histogramu) ).
Oczywiście - nie dla każdego i nie zawsze jest sens ją stosować, ale np. HDR też nie (szczególnie w reportażu), a jakoś dlaczegoś HDR nikomu nie jest dziwny.
Cytat:
Zamieszczone przez airhead
Wynikają. I nawet są opisane :)
http://www.canon-board.info/showthread.php?t=25632
zastanawia mnie czy w praktyce po naswietleniu histogramu do prawej - powiedzmy, ze cala scena miesci sie na zakresie i zostaje nawet miejsce, ok 1EV po prawej i lewej, a po naswietleniu na"do prawej" mamy okolo 1.75EV 'wolne' po lewej stronie - pozniej, przywywolaniu rawa powinienem skorygowac ekspozycje na ok. -1.75 czy raczej pociagnac to levelami (tudziez blacks'ami)?
rozumiem, ze po naswietleniu do prawej i pozniejszym obnizeniu ekspozycji w wywolywarce niejako "spycham" dane na strone cieni (lacznie z danymi o poltonach i swiatlach).
ja wiem,ze to pytanie jest na poziomie przedszkola foto, tym nie mniej jestem ciekaw jak to powinno wygladac, a chyba sam tego nie wydedukuje.
klade nacisk na 'powinno', bo po czesci zdaje sobie sprawe, ze "to zalezy".
jak wywolywac takiego 'naswietlonego do prawej' rawa?
Wywoływać normalnie. :) Można "obciąć" od dołu na krzywych (jeszcze w ACR) co zwiększy wydatnie kontrast. Można pociągnąć w dół krzywą (też jeszcze w ACR) w jej "lewej" części czyli w cieniach. Ogólnie to tak jak piszesz... to zależy... ale też zasada ogólna przy obróbce (każdej) to jak najdłużej trzymać jak największą ilość danych.Cytat:
Zamieszczone przez spoon
Serdecznie polecam używanie Curvesów. O levelsach można zapomnieć - przydają się w mniej niż 1% okazji. Wszystko można zrobić krzywymi.
Ciekawy wywiad na DPreview, myślę że w tym wątku powinien się znaleźć.
przeczytałem ten watek od początku do końca i mam pytanie.
Mozę ktoś na prostych rzeczywistych przykładach zdjęciowych pokazać i opisać jak dokładnie się wykonuje ten pomiar .