#22 Liniowość matrycy i co z tego wynika

[Tomasz Golinski]

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.

[Tomasz Urbanowicz]

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.

[Tomasz Golinski]

Wszystko prawda, z wyjątkiem tego, że 18% jasności w jpgu zapisze się jako 50% RGB=128,128,128. Z powodów antropicznych.

[minek]

Minek namieszałeś strasznie.

Tak, Tobie w głowie (-:

Po pierwsze założenie jest że matryca jest liniowa

To nie jest założenie. To jest fakt.

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.

Ale oczy nie widzą liniowo, i to jest drugi fakt.
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 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%".

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

Jeśli nadal będziesz się przy tym upierał, pokaż mi w jakimś algorytmie RAW -> JPG taką nieliniową konwersje.

Proszę: (fragment dcraw.c, komentarze moje)

/* 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);
  }

  }

FORCC to po prostu define robiący for() dla wszystkich kolorów czyli najprawdopodobniej 3.
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ć (-:

Trzecia sprawa to ta gamma. Wypadkowa monitor-system (...) luminancja wskazywana jest na 50%.

Wszystko prawda. Ale przy luminancji 50% monitor emituje przy tym 18% światła.

Pomijamy fakt jak widzą nasze oczy, bo to w zasadzie nieistotne.

W zasadzie to ogromnie zajebiście bardzo cholernie mocno istotne.

(...)
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.

Oczywiście, ze krowa.
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.

(...)
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.

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!

[Tomasz Golinski]

To nie jest założenie. To jest fakt.

Nie, to przybliżenie tylko.

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.

O, i to jest podstawa wszystkiego.

W zasadzie to ogromnie zajebiście bardzo cholernie mocno istotne.

Zupełnie nie istotne. Ważne jest tylko to, że ktoś tak sobie wymyślił. Oczy są tylko motywacją,

[Tomasz Urbanowicz]

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

[Tomasz Golinski]

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.

[czornyj]

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:

źródło

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?:

źródło

[Tomasz Urbanowicz]

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

[Tomasz Urbanowicz]

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?