Mateusz Ludwin pisze:
>> No cóż - nie ma hadeera, zatem fotograf jest po prostu zdolny :)
> Może sobie kupił filtry...?

A może po prostu pozazdrościł, że mi bez filtrów wychodziło? :)
Hadeery są przereklamowane i w klasycznych ujęciach pod słońce wystarczy
po prostu poruszać suwakami.
--
pozdrawia Adam
różne takie tam: www.smialek.prv.pl
/tak, proszę państwa, wygląd też się liczy.../

do góry

>> private int getColour(double cIn, double lIn, double lOut,
>> double s) { double tmp = cIn / lIn;
>> tmp = Math.pow(tmp, s);
>> tmp *= lOut;
>> if (tmp > 1.0) {
>> tmp = 1.0;
>> }
>
> Ja też chcę, ja też!
>
> clr a
> movc a, @a+dptr
> cjne a, #2, m191
> sjmp m15
> m191:
> cjne a, #1, m13
> acall selmel
> clr a
> movc a, @a+dptr
> mel13:
> mov rcap2h, a
> inc dptr
> clr a
> movc a, @a+dptr
> mov rcap2l, a
> inc dptr
> setb tr2
> sjmp m16
> (moje co prawda wygrywa melodyjki, ale też jest ładne :)

Taaa to ide poszukac mojego kodu w archiwum!

Ma ktos stacje dyskietek 5.25"?

q

do góry

Użytkownik <j...@a...at> napisał w wiadomości
news:9bef8d57-253b-440f-8665-b009631c4b1c@w35g2000yq
m.googlegroups.com...
On 12 Mrz., 14:31, "Stefan Nawrocki" <o...@3...com.pl> wrote:

> zakres tonalny jest zawsze ten sam od bieli do czerni powiedzmy
> monitora lub papieru tak jak obserwujemy obraz.
> Dla slowa 12 bitowego zostanie on podzielony na wiecej stopni niz dla
> slowa 8 bitowgo - , beda one wezsze - odwzorowanie bedzie
> subtelniejsze .

Dokładnie tak to widzę.


Stefan Nawrocki

do góry

Użytkownik "Mateusz Ludwin" <n...@s...org> napisał w wiadomości
news:gpb4p0$ds9$1@inews.gazeta.pl...
> Jakub Jewuła wrote:
>
> > Mateuszu, czekamy na blyskotliwa ropiste ;))))))
>
> Jadziem:

(...)

Jeśli jesteś autorem - to pogratulować :-).


Stefan Nawrocki

do góry

Jakub Jewuła napisał(a):
>>> private int getColour(double cIn, double lIn, double lOut,
>>> double s) { double tmp = cIn / lIn;
>>> tmp = Math.pow(tmp, s);
>>> tmp *= lOut;
>>> if (tmp > 1.0) {
>>> tmp = 1.0;
>>> }
>> Ja też chcę, ja też!
>>
>> clr a
>> movc a, @a+dptr
>> cjne a, #2, m191
>> sjmp m15
>> m191:
>> cjne a, #1, m13
>> acall selmel
>> clr a
>> movc a, @a+dptr
>> mel13:
>> mov rcap2h, a
>> inc dptr
>> clr a
>> movc a, @a+dptr
>> mov rcap2l, a
>> inc dptr
>> setb tr2
>> sjmp m16
>> (moje co prawda wygrywa melodyjki, ale też jest ładne :)
>
> Taaa to ide poszukac mojego kodu w archiwum!
>
> Ma ktos stacje dyskietek 5.25"?
>

A nie chcesz magnetofonu? Ja mam część listingów na kasetach ;)

wer

P.S. Mam też trochę kart i taśm perforowanych

do góry

Stefan Nawrocki wrote:

>> 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ą.
>
> http://www.optyczne.pl/125-s%C5%82ownik-Zakres_tonal
ny.html
> Punkt 2 w uwagach na dole.

Zgadzam się, ale jak to się ma do tego co siedzi w JPG? Z doświadczenia widzę,
że JPG jest w body zwykle tworzony na zasadzie wycięcia 8EV ze środka, żeby
wszystko było kontrastowe. Dopiero niedawno "wymyślono" coś takiego jak
D-Lightning co bierze cały zakres i silniej podbija cienie.

>> Mapowanie tonów to każde odwzorowanie z przestrzeni tonalnej w przestrzeń
>> tonalną.
>
> Jeśli "mapowaniem" nazwiemy każde odwzorowanie - to rzeczywiście, jakieś tam
> mapowanie jest. W programamch do obrobki HDR przyjęło się jednak rozdzielać
> dwie fazy. W pierwszej fazie - tworzony jest obraz "surowy" i w drugiej -
> zachodzi właśnie owo mapowanie, W Photomatixie są np. dwie metody mapowania
> (Details Enhancer i Tone Compressor) i są one niezależne od piewszej fazy -
> tworzenia obrazu "surowego".

Dokładnie to napisałem. Obraz HDR powstaje po pierwszej fazie, druga faza to
tonemapping żeby wyświetlić go na ekranie. I tonemapping nie wymaga wcale żeby
przetwarzać nim HDRI.

> Jeśli obraz "surowy" (w którym czarny odpowiada wartości 0, a biały -
> wartości X) znormalizujemy (liniowo) do takiej postaci, w której czarnemu
> odpowiada 0, a białemu 255 - to obraz taki możemy wyświetlić wprost na
> monitorze. Jeśli przekształcenie nie jest liniowe - to też jest (w sensie
> ogólnym) jakieś mapowanie, ale to jest tak samo jakby przekształcić liniowo,
> a potem pokręcić gammą, jasnością i kontrastem. Takie przeksztalcenie działa
> globalnie na cały obraz gdzie każdy piksel jest przetwarzany wg tej samej
> reguły.

To jest jak najbardziej tonemapping. Nawet taki zwykły liniowy do 8bitów też
jest tonemappingiem. A kręcenie gammą i kontrastem to już w ogóle.

Co do liniowego wyświetlania to problem jest taki, że cienie stają się zbyt
ciemne jeżeli wyświetli się tak zdjęcie na monitorze. Zdjęcie JPG z body ma je
już podbite za pomocą gammy.

> Istotą "mapowania" (takiego jak np. Details Enhancer w Photomatixie) jest
> badanie otoczenia każdego piksela (budowana jest tzw. "maska" i
> przekształcenie jest uzależnione od nasycenia tej maski) i zastosowanie
> innego przekształcenia w zależności od sąsiedztwa. W tym rozwiązaniu piksel
> o jakimś nasyceniu może być inaczej zmapowany w zależności od tego gdzie się
> znajduje na obrazie. W tym sensie mój przykład (i algorytm) tego nie robi.

To też jest tonemapping, tylko że działający lokalnie. Są dwie główne grupy
tonemapperów - globalne i lokalne. Globalne operują na poziomie każdego piksela
z osobna, a lokalne także na jego sąsiedztwie (ogólnie na całym obrazie
jednocześnie). Te pierwsze często nazywa się tone reproduction curves, bo prawie
zawsze jest to jakaś krzywa aplikowana wszystkim pikselom. I jedne i drugie mogą
dawać realistyczne rezultaty, nie ma tu żadnej zależności, że te lokalne są lepsze.

>> OK, a możesz jakoś opisać to przekształcenie matematycznie, bo ciężko coś
>> wydobyć z tak "ciężkiego" kodu?
>
> W najprostszym rozwiązaniu dla trzech zdjęć ustalamy dwa poziomy (granice).
> W ostatnim przykładzie granice były ustawione na 150, i 250.
> Tzn. wszystko co jest wewnątrz tej granicy jest brane ze zdjęcia "dobrego".
> Wszystko co powyzej - z niedoświetlonego, wszystko co poniżej - z
> prześwietlonego. Tak wygląda to przeksztacenie:
> http://www.3n.com.pl/Nikon/wynik_2.jpg
> Oczywiście - widać "ostre" granice przejść. Trzeba więc obliczyć "odchyłkę"
> od granicy i w obszarze granicznym połączyć płynnie piksele z obu zdjęć w
> stosunku proporcjonalnym do tej odchyłki. Taka jest idea zaprezentowanego
> algorytmu. Nie ma w nim uzależnienia koloru piksela od koloru sąsiednich
> pikseli, a więc nie ma lokalnego pdobijania (lub zmniejszania) kontrastu
> celem uwypuklenia pewnych obszarów.

Czyli to jest takie uproszczone HDRI, w którym wpleciono tonemapping w fazę w
której oblicza się średnie ważone dla każdego piksela. Jest o tym praca (zamiast
robić HDRI i potem mapować do 8 bitów, oblicza się za pomocą odpowiedniego
algorytmu wagi pomiędzy obrazami), tylko nie pamiętam teraz tytułu, potem znajdę.
--
Mateusz Ludwin mateuszl [at] gmail [dot] com

do góry

On 12 Mrz., 15:48, "Stefan Nawrocki" <o...@3...com.pl> wrote:
> Użytkownik <j...@a...at> napisał w
wiadomościnews:9bef8d57-253b-440f-8665-b009631c4b1c@
w35g2000yqm.googlegroups.com...
> On 12 Mrz., 14:31, "Stefan Nawrocki" <o...@3...com.pl> wrote:
>
> > zakres tonalny jest zawsze ten sam od bieli do czerni powiedzmy
> > monitora lub papieru  tak jak obserwujemy obraz.
> > Dla slowa 12 bitowego zostanie on podzielony na wiecej stopni niz dla
> > slowa 8 bitowgo - , beda one wezsze - odwzorowanie bedzie
> > subtelniejsze .
>
> Dokładnie tak to widzę.
>
> Stefan Nawrocki

qrcze to pierwszy przypadek , ze sie ktos ze mna zgadza tutaj :-)
i do tego nie padly zadne epitety czy inne nieprzyjemne slowa :-)
otwieram z tej okazji butelke champignione dzisiaj .

jak widac fachowiec z fachowcem zawsze sie dogada ;-)))

XXX

do góry

Janko Muzykant wrote:
> Mateusz Ludwin pisze:
>>> No cóż - nie ma hadeera, zatem fotograf jest po prostu zdolny :)
>> Może sobie kupił filtry...?
>
> A może po prostu pozazdrościł, że mi bez filtrów wychodziło? :)
> Hadeery są przereklamowane i w klasycznych ujęciach pod słońce wystarczy
> po prostu poruszać suwakami.

Chyba że chcesz faktycznie wykorzystać takie HDRI do czegoś więcej niż
wyświetlenia na WWW...
--
Mateusz Ludwin mateuszl [at] gmail [dot] com

do góry

Stefan Nawrocki wrote:

>>> Mateuszu, czekamy na blyskotliwa ropiste ;))))))
>> Jadziem:
>
> (...)
>
> Jeśli jesteś autorem - to pogratulować :-).

Pomysł na algorytm niestety nie mój, a Fattala :<
--
Mateusz Ludwin mateuszl [at] gmail [dot] com

do góry

Użytkownik "Mateusz Ludwin" <n...@s...org> napisał w wiadomości
news:gpb8f3$265$1@inews.gazeta.pl...
> Stefan Nawrocki wrote:
>

> Zgadzam się, ale jak to się ma do tego co siedzi w JPG? Z doświadczenia
widzę,
> że JPG jest w body zwykle tworzony na zasadzie wycięcia 8EV ze środka,
żeby
> wszystko było kontrastowe. Dopiero niedawno "wymyślono" coś takiego jak
> D-Lightning co bierze cały zakres i silniej podbija cienie.

To kwestia jakości softu, a nie 8, czy 12 bitów. I na to zwróciłem uwagę
(ten argument liczby bitów często pada na grupie).


>
> To jest jak najbardziej tonemapping. Nawet taki zwykły liniowy do 8bitów
też
> jest tonemappingiem. A kręcenie gammą i kontrastem to już w ogóle.

Jeśli tak (tonemappingiem) chcesz nazywać "kręcenie" gammą, itp. - to ok.
Pamietaj jednak, że "kręcenie" było przed HDR-em (i tak tego nie nazywano -
po prostu jest to korekcja gammy, kontrastu, nasycenia, itp.), a pojęcie
"tonemapping" wiąże się z wprowadzeniem techniki HDR.


>
> To też jest tonemapping, tylko że działający lokalnie. Są dwie główne
grupy
> tonemapperów - globalne i lokalne.

No ta ja - dla odróżnienia - te "globalne" nazywam "korekcją" :-), a te
lokalne - "mapowaniem tonów".

> I jedne i drugie mogą
> dawać realistyczne rezultaty, nie ma tu żadnej zależności, że te lokalne
są lepsze.

Różnica jest taka, że "globalne" znane są od lat i można było z nich
korzystać róznież w fotografii analogowej (twardość papieru, obróbka
chemiczna, itp. - ale to działało globalnie). Rewolucją jest przetwarzanie
cyfrowe, gdzie operator może działać lokalnie.


Stefan Nawrocki

do góry