"Eneuel Leszek Ciszewski" i6jhm3$csa$...@i...gazeta.pl

> Nie oznacza to rzecz jasna możliwości kontrastu luminancji na 16 bitach. :)

Bo ten już na 1 bicie sięga nieskończoności, ;) gdyż 1 dzielona przez
zero tam właśnie sięga. :) Problemem rzecz jasna jest odwzorowanie
zera, czyli pełnej ciemności. ;)


Innym problemem w tym ogromnym kontraście jest oddanie wartości leżących
pomiędzy 0 i 1 -- i gęstość/rozdzielczość nie zależy od tego, czy nasze
16 bitów potraktujemy jako liczbę integer, czy jako liczbę real. W obu
wypadkach mamy do dyspozycji około 2^16=65536 stanów pośrednich. :) Niby
nie musimy dawać pomiędzy nimi tyle samo przerwy, czyli możemy liczyć
nieliniowo, możemy liczyć liniowo, ale ze skokiem co 5 czy co 13, jednak
rozdzielczość takiej reprezentacji możemy tylko zmniejszyć -- musimy
albowiem część bitów poświęcić ;) (?wodą święconą?) na zapisanie
sposobu liczenia tej ,,odległości'' międzystanowej. :)

Możemy uznać, że rozumiemy jakoś tak:

001 --> 1
010 --> 2
011 --> 3
100 --> 4

lub tak:

001 --> 10
010 --> 20
011 --> 30
100 --> 40

czy jakoś nieliniowo tak:

001 --> 1
010 --> 2
011 --> 4
100 --> 8

albo tak:

001 --> 10
010 --> 20
011 --> 40
100 --> 80

czy jakoś inaczej, ale nie zapiszemy więcej możliwości niż około 2^16. :)


Na szczęście naszemu oku starczy w zupełności rozdzielczość
rzędu 2^7 na 3 kolorach -- RGB właśnie. :) A owe 32 bity
na subpikselu potrzebujemy dopiero wtedy, gdy chcemy coś
przerabiać. :) Nie jest obojętna kolejność:

-- zamiana kolorowego zdjęcia na czarnobiałe
(czarnobiałe, czyli ciemnobiałe lub jasnoczarne ciapki;
nie zaś czarno-białe, czyli w czarne i białe ciapki)

-- obróbka krzywymi (?curwami?)

co chyba każdy pojmuje. Zamiana w BW zabiera nieodwracalnie część
informacji -- i tę część, którą widzi oko, i tę, której oko nie
widzi, ale którą widzi obrabiarka typu fotoszop. :) Dokładnie
tak samo jest z 8/16/32 bitami na subpiksel. :) Oku jest obojętne,
jak gęsto (8/16/32) pokazuje monitor czy papier, lecz do obróbki
8 to za mało i okazuje się, że obrabianie z rozdzielczością 8 bitów
na subpiksel może prowadzić (ponoć zawsze prowadzi -- ja na swoim
monitorze tego nie zobaczę, a na analizowanie fotki nie mam ochoty)
do utraty informacji na wyjściu ośmiobitowym. :)

W skrócie:

-- w kolorze (RGB) możemy zmniejszyć ilość czerwonego niezależnie
od ilości zielonego (jakkolwiek pojmujemy określenie 'ilość')

-- w BW już taka sztuczka nie jest możliwa, gdyż nie pamiętamy, która
sukienka miała kolor czerwony a która zielony (obie są jakoś szare)

-=-

Inną sprawą jest pytanie -- czy naprawdę potrzeba aż 32 bitów na subpiksel
(4 bajtów -- w JPG mamy jeden bajt na subpiksel a potrzebujemy najwyżej
7 bitów na subpiksel do poprawnego widzenia, co wykorzystujemy w kompresji
do JPG) dla oddania HDR? Jeśli matryca aparatu fotograficznego daje normalnie
tylko 12 bitów to zapis na 16 zwykle powinien wystarczyć, ale być może czasami
potrzebujemy aż 32...


--
450-600 to (60-80)% . . .
749 .
VV Ventolin u . .
. 739 . 26 .
^ . . lipiec 25 . .01 . . .12 .
20 729 . . . 02 . .
. . . . . . 26 . . . g 03040506 .09 . 14 . 19
719 .25 27 04 06 08
P VVVV VV .19 . . . . r02VV . 13 .
21 709 . . 05
E 101112 17 20 VV . 2728 31 . 08 16VV
699 VV .
F . 16 VV23 29 m sierpień 1011 15 VV
690 2324 2829 .01 07 09
09 13 18 22 24 u 1718
680 22 30 wrzesień
l_' 21 30 c VV
670 31
/., 1415 h 07
660 VV
m/.. ......... ........ ..... ..................y................,,,,,,....;;;;..,
,;;..,,.654...,,..,,..,,..,,..,,..,,03..,,,,..,,..


Postscriptum... Na górze PEF, na dole kwiatki. ;)


tysiąc na tysiąc pikseli w TIFF8, TIFF16, TIFF32 to odpowiednio
milion pikseli z 1 bajtem na subpiksel, 2 i 4 bajtami na subpiksel
czyli 3 miliony bajtów, 6 milionów bajtów i 4 miliony bajtów.
Jak ktoś chce, nie zapisze taki plik PSem piątym lub czymś innym. :)
Ja zapisałem -- 3021796 6020948 12018188 -- czyli OK. :)

Gdy HaDRujemy Słoneczko i ciemną plamę pod samochodem, możemy mieć
niebotyczną różnicę jasności pomiędzy słoneczkiem i plamą, ale być
może do zapisania takiego zdjęcia nie potrzebujemy aż 32 bitów per
subpiksel, gdyż pomiędzy jasnym słoneczkiem i ciemna plamą być może
niczego nie ma. :) TIFF nie zezwala (bez kompresji) na pominięcie
części bitów. RAWki pozwalają, JPG wymusza wręcz i każdy format
z kompresowaniem daje tę możliwość, dlatego po skompresowaniu
tak zHaDRowane słoneczko z plamą może zająć bardzo mało miejsca
pomimo oddawania szczegółów słonecznych plamistych. :)



Czy my (lub PeeS albo inny Corel) uznamy w wiadomych 32 bitach
liczbę ineteger czy cokolwiek innego -- nie ma to tutaj żadnego
znaczenia. :)

Jeśli chcemy zapisać (do obróbki, gdyż do oglądania nam to nie
jest potrzebne, bo ani oko nie widzi, ani ucho nie słyszy, ani
ludzki umysł nie pojmuje, ;) jak to wiele te 32 bity) wszelkie
stany pośrednie pomiędzy maksymalną ciemnością każdego naszego
subpiksela i jego maksymalną jasnością, musimy mieć do naszej
dyspozycji te 32 bity. :)

Później i tak to zapiszemy na 6 bitach. :)

To tak, jak z obrabianiem przez zdrowego fotek kolorowych oglądanych
finalnie przez daltonistów któregoś stopnia, widzących tylko w B&W. :)
Zdrowy grafik oddzielnie obrabia spódnice Zuzi i spodnie Ziutka
(różniące się kolorem, nie tylko jasnością) po to, aby w efekcie
dostać szarości oglądane przez ślepawego odbiorcę finalnego.
(ślepak widzi tylko różnicę okołojasnościową, nie widzi
żadnej różnicy okołokolorystycznej)

PS czy inny Corel jest tym widzącym kolory zaś zwykły
odbiorca jest tym ślepawym daltonistą. :)

-=-

I chyba wyczerpałem temat rozdzielczości liczby oraz potrzeby
obróbki na 16 czy nawet na 32 bitach -- kwestionowanej przez
wiadomego ,,guru'' tej grupy. :)