Użytkownik <j...@a...at> napisał w wiadomości
news:5d9afbd6-cdbb-4c19-9f4a-e2c123c79d9e@b16g2000yq
b.googlegroups.com...
On 12 Mrz., 20:20, "Stefan Nawrocki" <o...@3...com.pl> wrote:
> Użytkownik <j...@a...at> napisał w
wiadomościnews:b91aad58-3cbb-40a4-9b8e->07305b13e7cf
@d19g2000yqb.googlegroup
s.com...

> nie oczywiscie ze nie ma to z szumami nic wspolnego.wogole do tej
> pory slowa "szumy" nie uzywalem.

Prawda - Ty nie - jakoś w dyskusji pojawił się motyw "jednego dodatkowego
bitu bez szumu" :-).

> ilosc przyjetego swiatla nie zalezy od przetwornika A/C czyli dlugosci
> slowa - to sie dzieje po stronie wyjscia.
> nie zwiekszamy w ten sposob dynamiki wejscia czyli zakresu tonalnego
> jaki matryca moze przyjac - absolutnie nie .

Dokładnie.

> Nie wiem gdzie widzisz tutaj problem ?

Nie - ja nie widze - mówię to samo, dlatego napisałem, że powtarzamy w kółko
to samo :-)

> mapujesz czyli dokonujesz przeliczen juz po stronie wyjscia , czyli
> znaczenie ma i sama matryca - jej zakres tonalny i dlugosc slowa czyli
> pojemnosc tonalna

Tak, ale długość słowa - w mniejszym stopniu niz matryca :-). Tzn. mniejsza
liczba bitów pogarsza dokładność obliczeń, ale nie powoduje przepałów, czy
szumów, które dyskwalifikują zdjęcie.


> HDR to w zasadzie manipulowanie na krzywej:
> dzilimy ja na 3 czesci - lewa ktora nie miesci sie w zakres tonalny
> monitora bo za ciemno - srodkowa , ktora sie miesci , i prawa , ktora
> sie nie miesci w zakres tonalny monitora bo za jasna.

> i teraz lewa czesc przesuwamy na srodek w prawo i prawa czesc na
> srodek w lewo teraz wszystkie trzy czesci znajduja sie w zakresie
> tonalnym monitora - trzeba tylko jakos wyliczyc krzywa wypadkowa - i
> to robi tonmaping na 100 mozliwych algorytmow.

No tak - to właśnie robi mój przykładowy algorytm, który zademonstrowałem
:-).


Stefan Nawrocki