Rzecze Andrzej Popowski:

> Twój gradient ma wpisaną krzywą gamma.

Tzn. gdzie ma wpisaną?

A co się dzieje kiedy uruchamiam emulator Amigi i w Personal Paint generuję
taki sam gradient, który nikgdy nie słyszał o Adobe? A mimo to nadal mam
naturalnie, ergo - to karta załatwia sprawę koniecznej korekcji.
--
Omniscient, omnipotent, omnipresent, without judgment

Mateusz Ludwin mateuszl [at] gmail [dot] com

do góry

On Thu, 12 Mar 2009, "Paweł W." wrote:

> Ludzie zlitujcie się. To grupa o fotografii cyfrowej, a nie o programowaniu!
> :(

"Lekarzu lecz się sam".
Takie czasy, że nie tylko opisanie, ale również *pokazanie* czegoś
tam najprościej zrobić programem (ale to "składowych" potrzeba
zanalizować w pierwszym dowodzie na "problem 4 kolorowych map",
coś koło 1030?) i nie zawsze jest taki pod ręką :]
Nie mówię o ostatnich latach - jedna z całkiem sprawnych "płaskich" baz
danych ("motoru" jak to niektórzy mawiają) czyli GTM została stworzona
przez ekipę... szpitalną.
Krótko mówiąc, zastrzeżenia rozumiem, ale na .programming bym ich
nie wyrzucał, bo tam ich dla odmiany wyrzucą za posługiwanie się
chińszczyzną pt. "tonemapping" :D

pzdr, Gotfryd

do góry

Thu, 12 Mar 2009 20:26:37 +0100, Mateusz Ludwin <n...@s...org>
pisze:

>> Twój gradient ma wpisaną krzywą gamma.
>
>Tzn. gdzie ma wpisaną?

W definicji przestrzeni sRGB, tam jest podany jest sposób kodowania
jasności koloru.

>A co się dzieje kiedy uruchamiam emulator Amigi i w Personal Paint generuję
>taki sam gradient, który nikgdy nie słyszał o Adobe? A mimo to nadal mam
>naturalnie, ergo - to karta załatwia sprawę koniecznej korekcji.

Nie myślisz logicznie. Liniowy zapis w pliku i nieliniowa gamma w
tablicy LUT da ten sam efekt, co nieliniowy zapis w pliku i liniowa
tablica LUT. Więc to żaden argument rozstrzygajacy.

Przejrzałeś opis sRGB?
Zajrzałeś do kodu dcraw?
Próbowałeś popracować z liniowymi tiffami?
--
Pozdrawiam,
Andrzej Popowski

do góry

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.googlegroups.com...
>
> > matryca o duzej dynamice zagospodaruje ten obszar gesciej ,
> > odwzorowanie bedzie subtelniejsze .
>
> Mam wrażenie, że powtarzamy w kółko to samo :-). Tak właśnie będzie -
> odwzorowanie będzie subtelniejsze. Nie oznacza to jednak, że będzie mogła
> przyjąć więcej światła (lub że będzie miała mniejsze szumy).


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

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 .

Nie wiem gdzie widzisz tutaj problem ?

.



>
> No tak, tylko problemem jest uzyskanie dobrego "źródła" (które potem poddamy
> temu mapowaniu). To źródło przy dzisiejszym poziomie technologicznym nas nie
> zadowala i dlatego kombinujemy z HDR. I to "niezadowolenie" nie wynika z
> faktu 8, czy 12 bitów.

Tak
ale zauwaz :

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

Gdyby tak było, to wystarczyłoby zapisywać pliki
> 12-bitowe i za pomoca odpowiedniego oprogramowania "mapować" je na pliki
> 8-bitowe. Tymczasem - to nie wystarcza. Nadal trzeba mieć dwa lub trzy pliki
> 12-bitowe (naświetlone z przesunięciem), żeby dostać zadawalajacy efekt.

sens HDR latwo mozna wyjasnic opisujac jak sie zmieni krzywa
desynsometryczna - tak trzebaby powiedziec .

ale to latwiej narysowac niz opisac.
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.


XXX

do góry

Użytkownik "Mateusz Ludwin" <n...@s...org> napisał w wiadomości
news:gpbr30.70k.1@teren.hamstera.pl...
> Rzecze Stefan Nawrocki:
>
> > Daj spokój - to tak nie działa :-). Nie uzyskasz "dodatkowego bitu bez
> > szumu" przez proste zagęszczenie kwantyzacji. Żeby uzyskać "bit bez
szumu"
> > musisz podnieść jakość matrycy, a nie zwiększyć rozdzielczość
próbkowania.
>
> Ale właśnie chodzi o to, że nowe matryce mają dużo więcej niż 8 bitów bez
> szumu!


To nie wypada nic innego - tylko kupować :-) . Zauważ tylko, że jeśli mają
więcej niż 8 bitów bez szumu - to i przy 8 bitach szumu też nie będzie :-).
Inaczej - to że mają mniejsze szumy nie wynika z większej liczby bitów - co
najwyżej jest odwrotnie :-).
Jeszcze inaczej - oczywiście jest postęp w technologii produkcji matryc.
Maleją szumy, a co za tym idzie - jak pisałeś - zwiększa się zakres tonalny.
Ale - to nie rozdzielczość (liczba bitów przetwornika) o tym decyduje. Rzecz
jasna, że jeśli matryca jest lepsza (mniej szumi, ma większy zakres
tonalny), to stosowanie przetwornika o większej liczbie bitów ma sens (bo
"schodki" między kolejnymi poziomami szarości są mniejsze), ale jest to
skutek, a nie przyczyna (to nie zwiększenie liczby bitów w przetworniku
podnosi jakość matrycy, ale lepsza jakoś matrycy wymusza większą liczbę
bitów).
Jeszcze inaczej :-) podłączanie do tej samej matrycy raz przetwornika
8-bitowego i za chwilę 16-bitowego nie spowoduje, że matryca będzie
zmieniała swoje fizyczne wlaściwości.


Stefan Nawrocki

do góry

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

do góry

Rzecze Stefan Nawrocki:

> Ale - to nie rozdzielczość (liczba bitów przetwornika) o tym decyduje. Rzecz
> jasna, że jeśli matryca jest lepsza (mniej szumi, ma większy zakres
> tonalny), to stosowanie przetwornika o większej liczbie bitów ma sens (bo
> "schodki" między kolejnymi poziomami szarości są mniejsze), ale jest to
> skutek, a nie przyczyna (to nie zwiększenie liczby bitów w przetworniku
> podnosi jakość matrycy, ale lepsza jakoś matrycy wymusza większą liczbę
> bitów).

Nigdy tak nie twierdziłem.
--
Omniscient, omnipotent, omnipresent, without judgment

Mateusz Ludwin mateuszl [at] gmail [dot] com

do góry

Rzecze Andrzej Popowski:

> Nie myślisz logicznie. Liniowy zapis w pliku i nieliniowa gamma w
> tablicy LUT da ten sam efekt, co nieliniowy zapis w pliku i liniowa
> tablica LUT. Więc to żaden argument rozstrzygajacy.

No ale moment moment...

Załóżmy że napiszę sobie program który wyświetli mi:

- gradient o szerokości 256 pikseli z 0..255
- poniżej zdjęcie wywołane z raw bez żadnej korakcji

Gradient będzie OK, zdjęcie nie będzie OK. Dlaczego?

> Przejrzałeś opis sRGB?
> Zajrzałeś do kodu dcraw?
> Próbowałeś popracować z liniowymi tiffami?

O kurczę, nie będę zaglądać do kodu. Przecież mówię że liniowy TIFF ze
zdjęciem to to samo co mój liniowy gradient. I to wskazuje na to, że ten
obraz jest naprawdę taki ciemny w rzeczywistości, tylko nasze oczy inaczej
reagują przy większej jasności.
Podejrzewam, że wyświetlając taki liniowy TIFF ze zdjęciem na ekranie
wyświetlacza o 100x razy większej jasności, uzyskalibyśmy naturalnie
wyglądające odcienie, bez żadnej korekcji gamma wprowadzanaje w
wywoływaczce.
--
Omniscient, omnipotent, omnipresent, without judgment

Mateusz Ludwin mateuszl [at] gmail [dot] com

do góry

Użytkownik "Mateusz Ludwin" <n...@s...org> napisał w wiadomości
news:gpbsnr.75s.1@teren.hamstera.pl...
> Rzecze Stefan Nawrocki:
>
> > Ale - to nie rozdzielczość (liczba bitów przetwornika) o tym decyduje.
Rzecz
> > jasna, że jeśli matryca jest lepsza (mniej szumi, ma większy zakres
> > tonalny), to stosowanie przetwornika o większej liczbie bitów ma sens
(bo
> > "schodki" między kolejnymi poziomami szarości są mniejsze), ale jest to
> > skutek, a nie przyczyna (to nie zwiększenie liczby bitów w przetworniku
> > podnosi jakość matrycy, ale lepsza jakoś matrycy wymusza większą liczbę
> > bitów).
>
> Nigdy tak nie twierdziłem.

13 listów wyżej. Cytuję:
----------------------------------------------------
------------------------
> Ten fragment nie byl o HDR, ale o tym, że niektórzy sądzą, że zmiana
liczby
> bitów (jpg - 8, RAW - 12) zmienia w istotny sposób zakres tonalny. Tak nie
> jest.

Zmienia - te dodatkowe bity w RAW idą w zakres a nie rozdzielczość. JPG z
aparatu ma zwykle 8bitów wyciętych ze środka 12bitowego rawa, a nie
obciętych
przez odrzucenie najmniej znaczących bitów. Dopiero jeśli użyje się różnych
fill
light i recovery, to mamy do czynienia z faktyczną kompresją.
----------------------------------------------------
-----------------------

No cóż - jeśli źle zrozumiałem - to przepraszam :-). Ale piszesz wyraźnie:
"Zmienia - te dodatkowe bity w RAW idą w zakres a nie rozdzielczość.", więc
tak to zrozumiałem.


Pozdrawiam
Stefan Nawrocki

do góry

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


to jest prawda ale przy krotszym slowie mamy juz biel , tam gdzie przy
dluzszym slowie pojawilyby sie jeszcze delikatne szczegoly /
odcienie.
i analogicznie dla cieni - przy krotszym slowie bedzie juz czern ,
gdy przy dluzszym slowie bylby jeszcze jakies tam szarosci.

przyrownujac do szachownicy dwubitowej - biale pole to jakby przepal
a gdyby byla to szachownica np 8 bitowa to tam gdzie dla dwubitowej
jest jedna biala plama , mielibysmy dla 8 bitowej szereg walorow.

Jesli rzeczywiscie przeswietlimy zdjecie to dlugosc slowa nie bedzie
miec zadnego znaczenia tzn w jednym wypadku przepal zostanie zapisany
slowem 8 bitowym - powiedzmy wszedzie jedynki a wdrugim przypadku
slowo 24 bitowe tez bedzie wypelnione tylko jedynkami tak dla
przakladu , przepal moznaby zapisac slowem jednobitowym , czyli jego
dlugosc nie ma znaczenia.


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

te indywidualnie pisane algorytmy maja te zalete ze nie sa popularne ,
czyli masowo uzywane , dziki czemu pozwalaja na uzyskanie oryginalnych
wynikow.
moze pokazesz jakas skladanke liczona tym algorytmem ?

XXX

do góry