eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.rec.foto.cyfrowahdr a Jpg › Re: hdr a Jpg
  • Data: 2009-03-12 15:07:15
    Temat: Re: hdr a Jpg
    Od: Mateusz Ludwin <n...@s...org> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    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

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: