"Sergiusz Rozanski" s...@d...media-lab.com
.pl

>>>> Zmienność ta coś dodaje w rozdzielczości liczby? ;)
>>>> Raczej nie. :)

>>> A kto mówi o rozdzielczości?

>> Więc co za różnica -- zmienno- czy stałopozycyjne reprezentowanie? :)
>> Na 16 bitach nie umieścisz więcej niż 2^16 różnych możliwości. :)

> Różnica w nieliniowej 'gęstości'. Mogę to rozrysować :)

To rozrysuj. :)

--
.`'.-. ._. .-.
.'O`-' ., ; o.' e...@e...comyr.com '.O_'
`-:`-'.'. '`\.'`.' ~'~'~'~'~'~'~'~'~ o.`.,
o'\:/.d`|'.;. p \ ;'. . ;,,. ; . ,.. ; ;. . .;\|/....

do góry

"Mateusz Ludwin" i...@t...hamstera.pl

>> Więc po co ta zmienność przecinkowania? :) Co ona daje?

> No przecież napisałem, że zwiększenie zakresu. HDRI nie zapisuje się nigdy w
> fixed pointach, nawet 32bit, tylko na zmiennym przecinku.

Ty też rozrysuj. :)

--
.`'.-. ._. .-.
.'O`-' ., ; o.' e...@e...comyr.com '.O_'
`-:`-'.'. '`\.'`.' ~'~'~'~'~'~'~'~'~ o.`.,
o'\:/.d`|'.;. p \ ;'. . ;,,. ; . ,.. ; ;. . .;\|/....

do góry

On Sep 12, 10:06 pm, Mateusz Ludwin <n...@s...org> wrote:
> Rzecze limies:
>
> > z mojej strony ? - Hobby . Ze strony autora - mysle, ze duzo
> > wiecej :-)
> > stronahttp://www.radiance-online.org/
>
> Nie no, nie pytałem o Warda. Interesuje mnie skąd masz tyle wiedzy na temat
> HDRI. Twoje posty to chyba jedyne takie wypowiedzi w internecie, pod którymi
> mógłbym się w 100% podpisać.
> Jakiejś pracy nie piszesz...?
> --
> Omniscient, omnipotent, omnipresent, without judgment
>
> Mateusz Ludwin                             mateuszl [at] gmail [dot] com

Nie, nie piszę. jestem fizykiem wiec stąd róznorakie zainteresowania.
wiedzą raczej mało praktyczną :-(

do góry

"limies" f...@v...goo
glegroups.com

: Pojawia sie problem zapisu obrazu o duzej rozpietosci tonalnej.
: Historia jest taka, ze startowano od 8-bitów (photoshop pierwsze
: wersje bodajże do 6-tej, w 7-mej dopiero bylo 16bit i to nie w pelni)
: Wiadomo, ze 8 bitow to za mało posteryzacja 256 wartosci - to troche
: za mało idzmy dalej 16 bit duzo lepiej tiffy 16 bitowe
: z posteryzacja w zasadzie problemow nie ma, ale dla duzej rozpietosci
: tonalnej to trochę za mało - aczkolwiek głębia kolorów
: jest słabym wskaźnikiem rozpietosci tonalnej
: Ludzkie oko widzi w rozpietosci 14EV

Tyle można uzyskać skrajnie dzięki źrenicy czy taka
jest pojemność pręcików lub czopków? :)

: Rozpietosc w przyrodzie ponad 44EV
: 44EV = słabe swiatło gwiazd - światło Słońca

A w noc pochmurną i bezksiężycową? :)
No i to światło słoneczne gdzie i kiedy? :)

: Jak zapisac obrazy o takiej rozpietosci tonalnej ? Jak to rozwijało
: sie historycznie ?
: Zaczynano od integerów niech to bedzie nawet 16 bit miedzy wartoscia
: 20 a 21 nie ma nic - liczby zmiennoprzecinkowe pozwalają na wstawienie
: tam 25,5 - to własnie lezy u podstaw hdri.

Problem w tym, że rozdzielczość rzeczywistych jest mniejsza niż całkowitych. :)

: Odpada w ten sposob wspolczynik gamma poniewaz mozemy kodowac detale.
: Pozbywamy sie tez górnych ograniczen w przypadku zmiennego przecinka
: jasnosc piksela 20000 ? Żaden problem !!! w formacie integer - kicha !
: W prypadku float zaden piksel nie jest wyrzucany poza przeciał
: zakresu .

Niby tak, ale nie można na 16 bitach zapisać liczby 20000 z rozdzielczością
lepszą wówczas, gdy jest to real zamiast integer. :) Naprawdę to ani
real, ani integer, ale jakieś ułożenie bitów. :)

Nie jest to żadna kicha -- wystarczy liczyć co 10 (zamiast co 1) i mamy liczby
całkowite od 0 do ponad 655 tysięcy na 16 bitach liczby integer. :) De facto tak
właśnie liczone są liczby real -- część tych 16 bitów idzie (w pewnym sensie) na
zapisanie mnożnika. :) A że ten mnożnik może być różny, trzeba część tych 16 bitów
zabrać na określenie wielkości tego mnożnika. :)

-=-

16 bitów na subpisel w xRGB to bagatela 256 bilionów możliwości. :)

2^(16*3)/(1024^4)=256

przy założeniu, że 1024^4 to bilion, czyli milion milionów, zaś milion to tysiąc
tysięcy. :)

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

--
.`'.-. ._. .-.
.'O`-' ., ; o.' e...@e...comyr.com '.O_'
`-:`-'.'. '`\.'`.' ~'~'~'~'~'~'~'~'~ o.`.,
o'\:/.d`|'.;. p \ ;'. . ;,,. ; . ,.. ; ;. . .;\|/....

do góry

Rzecze Eneuel Leszek Ciszewski:

>>> Więc po co ta zmienność przecinkowania? :) Co ona daje?
>
>> No przecież napisałem, że zwiększenie zakresu. HDRI nie zapisuje się nigdy w
>> fixed pointach, nawet 32bit, tylko na zmiennym przecinku.
>
> Ty też rozrysuj. :)

Co znowu mam rysować?

Jesli wiesz czym jest zapis zmiennoprzecinkowy, to wiesz jak się różni jego
zakres od stałego przecinka. Jeśli nie wiesz, doczytaj sobie.
--
Omniscient, omnipotent, omnipresent, without judgment

Mateusz Ludwin mateuszl [at] gmail [dot] com

do góry

On Sep 12, 11:45 pm, "Eneuel Leszek Ciszewski"
<p...@c...fontem.lucida.console> wrote:
> "limies" f...@v...goo
glegroups.com
>
> : Pojawia sie problem zapisu obrazu o duzej rozpietosci tonalnej.
> : Historia  jest taka, ze startowano od 8-bitów (photoshop pierwsze
> : wersje bodajże do 6-tej, w 7-mej dopiero bylo 16bit i to nie w pelni)
> : Wiadomo, ze 8 bitow to za mało posteryzacja 256 wartosci - to troche
> : za mało idzmy dalej 16 bit duzo lepiej tiffy 16 bitowe
> : z posteryzacja w zasadzie problemow nie ma, ale dla duzej rozpietosci
> : tonalnej to trochę za mało - aczkolwiek głębia kolorów
> : jest słabym wskaźnikiem rozpietosci tonalnej
> : Ludzkie oko widzi w rozpietosci 14EV
>
> Tyle można uzyskać skrajnie dzięki źrenicy czy taka
> jest pojemność pręcików lub czopków? :)
>
> : Rozpietosc w przyrodzie ponad 44EV
> : 44EV = słabe swiatło gwiazd - światło Słońca
>
> A w noc pochmurną i bezksiężycową? :)
> No i to światło słoneczne gdzie i kiedy? :)
>
> : Jak zapisac obrazy o takiej rozpietosci tonalnej ? Jak to rozwijało
> : sie historycznie ?
> : Zaczynano od integerów niech to bedzie nawet 16 bit miedzy wartoscia
> : 20 a 21 nie ma nic - liczby zmiennoprzecinkowe pozwalają na wstawienie
> : tam 25,5 - to własnie lezy u podstaw hdri.
>
> Problem w tym, że rozdzielczość rzeczywistych jest mniejsza niż całkowitych. :)
>
> : Odpada w ten sposob wspolczynik gamma poniewaz mozemy kodowac detale.
> : Pozbywamy sie tez górnych ograniczen w przypadku zmiennego przecinka
> : jasnosc piksela 20000 ? Żaden problem !!! w formacie integer - kicha !
> : W prypadku float zaden piksel nie jest wyrzucany poza przeciał
> : zakresu .
>
> Niby tak, ale nie można na 16 bitach zapisać liczby 20000 z rozdzielczością
> lepszą wówczas, gdy jest to real zamiast integer. :) Naprawdę to ani
> real, ani integer, ale jakieś ułożenie bitów. :)
>
> Nie jest to żadna kicha -- wystarczy liczyć co 10 (zamiast co 1) i mamy liczby
> całkowite od 0 do ponad 655 tysięcy na 16 bitach liczby integer. :) De facto tak
> właśnie liczone są liczby real -- część tych 16 bitów idzie (w pewnym sensie) na
> zapisanie mnożnika. :) A że ten mnożnik może być różny, trzeba część tych 16 bitów
> zabrać na określenie wielkości tego mnożnika. :)
>
> -=-
>
ale nie o zadna rozdzielczosc tu chodzi. Chodzi o zapis kolorow i
mozliwie duzego zakresu ekspozycji.
Na ogół jedno odbywa sie kosztem drugiego. Wykladnik jest potrzebny
byy zwiekszyc zakres ev - mowiac w duzym skrócie
kosztem glebi kolorow

do góry

Rzecze Eneuel Leszek Ciszewski:

> Nie jest to żadna kicha -- wystarczy liczyć co 10 (zamiast co 1) i mamy liczby
> całkowite od 0 do ponad 655 tysięcy na 16 bitach liczby integer. :)

Przecież to nic nie daje.

Zastanów się choć przez chwilę czym jest kontrast między pikselami.

Wartość piksela naprawdę nie ma żadnego znaczenia dla tych wszystkich zabaw
z HDRI. Znaczenie ma kontrast jaki możesz zapisać, a kontrast to różnica
między poziomami pikseli. Jak byś się nie namęczył, nie zapiszesz na 16
bitach stałego przecinka rozpiętości większej niż 16 (15?) EV.

Przy czym "dolne" EV będą zapisane na bardzo niewielu bitach i przez to
składać się z placków o stałym poziomie jasności, co raczej nie wygląda za
dobrze.

Uzyskasz sukces nie wtedy, kiedy będziesz mieć piksele 0, 10, 20, 30, tylko
kiedy będziesz w stanie dołożyć do nich piksele 1, 2, 3.

> De facto tak
> właśnie liczone są liczby real -- część tych 16 bitów idzie (w pewnym sensie) na
> zapisanie mnożnika. :) A że ten mnożnik może być różny, trzeba część tych 16 bitów
> zabrać na określenie wielkości tego mnożnika. :)

To co według ciebie może być różne, jest istotą floating point.
--
Omniscient, omnipotent, omnipresent, without judgment

Mateusz Ludwin mateuszl [at] gmail [dot] com

do góry

"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. :)

do góry

"limies" 6...@t...goog
legroups.com

: ale nie o zadna rozdzielczosc tu chodzi.
: Chodzi o zapis kolorow i mozliwie duzego zakresu ekspozycji.

Co Ci po tej dużości, jeśli ją będziesz mógł
wyrażać na przykład ze skokiem co milion. :)

jeden milion, dwa miliony, trzy miliony...

: Na ogół jedno odbywa sie kosztem drugiego.

Na ogół zapis jest prosty do bólu -- w RGB mamy trzy składowe
(trzy subpiksele) i trzy liczby (każdą z nich zapisujemy na 8 bitach,
lub na 16 bitach, albo na 32 bitach itd.) mówiące nam o jasności tego
każdego subpiksela. Co prawda jasność rejestrowana przez ludzkie oko
nie jest prostą sumą jasności subpikseli, ale jednak jednoznacznie
zależy od tej [sub]jasności. :)

Oko ludzkie też patrzy na świat poprzez ,,pryzmat'' RGB. :)
Stąd właśnie pomysł rozbijania wszystkiego na RGB, a nie na
przykład na 7 kolorów tęczy. ;)

: Wykladnik jest potrzebny
: byy zwiekszyc zakres ev - mowiac w duzym skrócie
: kosztem glebi kolorow

Wykład uczyniony -- jasność każdego subpiksela przekłada się na jasność
całości, czyli na jasność całego piksela złożonego z tychże trzech subpikseli.
Nie przekłada się ona w prosty sposób (na przykład: ,,suma jasności subpikseli
daje w efekcie jasność całego piksela'') ale jednak przekłada się. :)


Proporcje jasności subpikseli dają wrażenie koloru. :)

Nie jest jednak prawdą, że jeśli jakieś (rgb) postrzegamy jako
jakiś kolor, to i (nrngbb) będziemy widzieli jako ten sam kolor,
lecz w jaśniejszym wydaniu. :) Na przykład (30,40,50) i (60,80,100)
czy (120,160,200) to nie są dla oka identyczne kolory różniące się
jedynie innej jasnością. :)

--
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
E101112 17 20 VV . 2728 31 . 08 16VV
695 VV .10
F . 16 VV23 29 m sierpień 1011 15 VV
690 2324 2829 .01 07 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..,,,,..,,..,,

do góry

"Mateusz Ludwin" i...@t...hamstera.pl

>> Ty też rozrysuj. :)

> Co znowu mam rysować?

> Jesli wiesz czym jest zapis zmiennoprzecinkowy, to wiesz jak się różni
> jego zakres od stałego przecinka. Jeśli nie wiesz, doczytaj sobie.

Wiem, ;) dlatego wiem, że Ty nie wiesz. :)
(albo udajesz, że nie wiesz)

Co więcej -- Ty na pewno nie wiesz, co to jest zapis stałopozycyjny.
Co procesor to inne widzenie takiej liczby? Oczywiście nie, ale nie
ma jednoznaczności w postrzeganiu liczy integer.

Tym bardziej nie ma jednoznaczności w postrzeganiu liczy real. :)

W integer obowiązuje ,,wolna amerykanka'' zaś w real są standardy
(różne na które nakłada się owa ,,wolna amerykanka''. :)

Napisałem wyżej, że wiem, ale dodałem przymrużenie oka -- nie mogę znać
każdej reprezentacji, choć imo ich liczba musi być skończona, choćby
komuś przyszło do głowy, że bitem określającym znak (toż integer może
przybierać także wartości ujemne) jest bit znajdujący się nie na zewnątrz,
ale wewnątrz danych nam do dyspozycji 16 bitów. :) (jak znam ten temat,
to chyba często jest wewnątrz)

Kiedyś CPU operował na 8 bitach (było i gorzej!) później wygrywać zaczęły
CPU liczącymi naraz na 16 bitach (i trzeba było jakoś to pogodzić z historią
oraz z fantazją nowych projektantów) ale pojawiły się CPU liczące nie na
8, nie na 16, lecz na większej liczbie bitów... A bywało, że naraz CPU
miał różne cosie na różnej liczbie bitów. :)

--
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
E101112 17 20 VV . 2728 31 . 08 16VV
695 VV .10
F . 16 VV23 29 m sierpień 1011 15 VV
690 2324 2829 .01 07 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..,,,,..,,..,,

do góry