Sns-hdr

[PiKa]

Czy można prosić o listę zmian?

[Pebal]

Ta wersja nie jest jeszcze kompletna, więc trudno pisać o zmianach w porównaniu do poprzednich wersji. Wersja ta ma zaimplementowane nowe algorytmy i posiada całkowicie nowy, znacznie szybszy interfejs graficzny. Najlepiej zainstalować i sprawdzić samemu.

[igsux3]

Pisać tu uwagi, czy szkoda strzępić języka?

Już na starcie, czym są pierwsze ustawienia? Align exposures i priority brighter exposures? (przy okazji to powinno być "bright exposures priority" albo "prioritize brighter exposures")

Na plus:

+ tempo łączenia, tone mappingu. Widać, że CPU i GPU pracują na pełnych obrotach. Brawo.
+ nareszcie rednerowanie podglądu na GPU. Wreszcie płynne przewijanie i zoomowanie. (sam to sugerowałem w tym wątku, bardzo mnie cieszy ta zmiana )
+ znowu można przerzucić panele na inny ekran
+ ogólna prędkość działania programu.

Na minus:
- deghosting dalej działa tak sobie. Ludzie i liście zwykle skutecznie pokonują algorytm.
- w światłach przydałaby się jakaś opcja jak automatycznej maski luminancji. Niestety praktycznie zawsze we wnętrzach to co jest za oknem trzeba robić na osobnej warstwie.


Sugestie:
- kiedy będzie można rozciągać panele? operowanie na krzywych przy tak malutkim rozmiarze potrafi być irytujące
- czy pojawi się opcja usuwania aberracji chromatycznej?


Oczywiste braki, ale chyba też oczywiste, że wrócą?
- historia
- maski
- łączenie paneli

[Pebal]

Już na starcie, czym są pierwsze ustawienia? Align exposures i priority brighter exposures? (przy okazji to powinno być "bright exposures priority" albo "prioritize brighter exposures")

Wyrównanie to wyrównanie a co do priorytetu to niestety, orłem z angielskiego nie jestem i nie bardzo wiedziałem jak napisać "priorytet jaśniejszych ekspozycji".

+ nareszcie rednerowanie podglądu na GPU. Wreszcie płynne przewijanie i zoomowanie. (sam to sugerowałem w tym wątku, bardzo mnie cieszy ta zmiana )

To cię zaskoczę, bo podgląd nie jest jeszcze renderowany na GPU, ten jest dopiero w planach. Mocno popracowałem nad optymalizacją zarządzania pamięcią obrazu i stąd to przyspieszenie.

- deghosting dalej działa tak sobie. Ludzie i liście zwykle skutecznie pokonują algorytm.

Nie wiem czy kiedykolwiek ten algorytm będzie działał inaczej, bo nie jestem przekonany do tego aby go zmieniać. Dużo pracowałem nad nowym algorytmem usuwania duchów i doszedłem do jednego wniosku - nie ma złotego środka. Usuwanie duchów wymaga kopiowania fragmentów ciemniejszych ekspozycji do jaśniejszych a to drastycznie zwiększa poziom szumu. Chcę dodać narzędzie do ręcznego usuwania duchów, ale na razie ma ono niski priorytet.

- w światłach przydałaby się jakaś opcja jak automatycznej maski luminancji. Niestety praktycznie zawsze we wnętrzach to co jest za oknem trzeba robić na osobnej warstwie.

Tutaj żadna opcja poza fizyczną maską raczej niewiele zdziała. Trzeba pamiętać, że program nie wie gdzie jest okno i gdy poleci po światłach to wszędzie, a wraz z nimi poleci lokalny kontrast.

- kiedy będzie można rozciągać panele? operowanie na krzywych przy tak malutkim rozmiarze potrafi być irytujące

Nie widziałem potrzeby aby rozciągać panele, jakiej wielkości byś oczekiwał?

- czy pojawi się opcja usuwania aberracji chromatycznej?

Tak.

Oczywiste braki, ale chyba też oczywiste, że wrócą?
- historia
- maski
- łączenie paneli

To czego brakuje pojawi się w niedługim czasie, choć akurat łączenia paneli nie bardzo rozumiem. Co masz na myśli?

[igsux3]

Wyrównanie to wyrównanie a co do priorytetu to niestety, orłem z angielskiego nie jestem i nie bardzo wiedziałem jak napisać "priorytet jaśniejszych ekspozycji".

To bym raczej napisał align images, a nie align exposures Bo z tego wynika, że dopasowuje się ekspozycje jako jasności, a nie poszczególne zdjęcia.

To cię zaskoczę, bo podgląd nie jest jeszcze renderowany na GPU, ten jest dopiero w planach. Mocno popracowałem nad optymalizacją zarządzania pamięcią obrazu i stąd to przyspieszenie.

Gratulacje bo naprawdę przyspieszenie jest potężne. Aż sprawdziłem w diagnostyce - faktycznie, program w ogóle nie zajmuje vramu. Ale co ciekawe, przy przesuwaniu obrazu obciążenie GPU wskakuje na okolice 10%, więc coś tam jest akcelerowane.

Nie wiem czy kiedykolwiek ten algorytm będzie działał inaczej, bo nie jestem przekonany do tego aby go zmieniać. Dużo pracowałem nad nowym algorytmem usuwania duchów i doszedłem do jednego wniosku - nie ma złotego środka. Usuwanie duchów wymaga kopiowania fragmentów ciemniejszych ekspozycji do jaśniejszych a to drastycznie zwiększa poziom szumu. Chcę dodać narzędzie do ręcznego usuwania duchów, ale na razie ma ono niski priorytet.

Doskonale to rozumiem i się wcale nie dziwię. Tak tylko mówię, że na pierwszym zdjęciu które wrzuciłem do programu miałem przekłamania na liściach i osobie, która przechodziła pod drzewem. Adobe ma ghost reduction z podziałem na none, low, medium, high. Zawsze jakiś parametr.

Tutaj żadna opcja poza fizyczną maską raczej niewiele zdziała. Trzeba pamiętać, że program nie wie gdzie jest okno i gdy poleci po światłach to wszędzie, a wraz z nimi poleci lokalny kontrast.

To też doskonale rozumiem i niestety jest z tym trochę zachodu. Zawsze jeden tiff idzie na wnętrze, a drugi na to, co za oknem. Na szczęście okna mają przeważnie geometryczne kształy, więc pen tool w photoshopie pozwala całkiem szybko sobie z problemem poradzić Jednak coś na wzór masek luminancji z jak z Easy Panelem, które pozwalałyby jednym kliknięciem zaznaczyć okno, na pewno by pomogły. No ale przecież to nie jest program do wszystkiego, więc póki znam sposób żeby poradzić sobie z problemem to nie ma tragedii

Nie widziałem potrzeby aby rozciągać panele, jakiej wielkości byś oczekiwał?

W SNS wygląda to tak :

źródło

To jest 200x100 px, czyli do precyzyjnej roboty tyle co nic.

W wielu programach można sobie taki panel dowolnie powiększyć, na przykład w Capture NX-D domyślnie jest taki:

źródło

Ale po rozciągnięciu może być i tego rozmiaru:

źródło

To czego brakuje pojawi się w niedługim czasie, choć akurat łączenia paneli nie bardzo rozumiem. Co masz na myśli?

W starym SNS można było panele łączyć w grupy jak się przyciągnęło je do śodka, to można było wybrać w które miejsce ma się on "przykleić". Podobnie jest w PS czy CNX-D, panele można "sklejać" w grupy. Z angielskiego windows snapping, nie wiem jak to po polsku nazwać

Przy okazji zauważłem, że po restarcie programu wszystkie panele wróciły na swoje domyślne miejsce, pierwszy bug do naprawy

Aaa jeszcze sobie przypomniałem, lata temu pisałeś na forum kkm, że masz możliwość wykorzystania algorytmu, który całkowicie eliminuje efekt halo, ale kosztem zapotrzebowania na olbrzymią moc obliczeniową. Może udostępniłbyś to jako eksperymentalny ficzer? A możę przy obliczeniach na GPU ma to już rację bytu?

[Pebal]

W wielu programach można sobie taki panel dowolnie powiększyć, na przykład w Capture NX-D domyślnie jest taki:

Trudno mi sobie wyobrazić do czego taki olbrzym byłby mi potrzebny. Napisz proszę co takiego na tym obszarze chcesz robić, że potrzebujesz takiej precyzji. Ja, szczerze mówiąc, nigdy takiej precyzji nie potrzebowałem.
Trzeba także wziąć pod uwagę kwestie techniczne. Gdy powiększę obszar krzywej to trzeba będzie dodać do panela pasek przewijania, a tego za wszelką cenę staram się w moim programie uniknąć. Rozwiązaniem byłoby może osobne okno dla krzywych.

W starym SNS można było panele łączyć w grupy jak się przyciągnęło je do śodka, to można było wybrać w które miejsce ma się on "przykleić". Podobnie jest w PS czy CNX-D, panele można "sklejać" w grupy. Z angielskiego windows snapping, nie wiem jak to po polsku nazwać

Niestety, zmieniłem biblioteki graficzne i one nie udostępniają mechanizmu sklejania paneli w grupy. Trzeba by to oprogramować ręcznie.

Przy okazji zauważłem, że po restarcie programu wszystkie panele wróciły na swoje domyślne miejsce, pierwszy bug do naprawy

Konfiguracja okien nie jest jeszcze zapisywana.

Aaa jeszcze sobie przypomniałem, lata temu pisałeś na forum kkm, że masz możliwość wykorzystania algorytmu, który całkowicie eliminuje efekt halo, ale kosztem zapotrzebowania na olbrzymią moc obliczeniową. Może udostępniłbyś to jako eksperymentalny ficzer? A możę przy obliczeniach na GPU ma to już rację bytu?

Ten algorytm aby działał w akceptowalnym czasie musiałby być wykonywany w całości na GPU. Wymaga to załadowania całego obrazu do pamięci karty graficznej, a to niestety kłopot, bo nie każda karta potrzebną ilość pamięć ma. Będę o tym myślał, gdy standardem na rynku będzie 4GB pamięci.

[igsux3]

Trudno mi sobie wyobrazić do czego taki olbrzym byłby mi potrzebny. Napisz proszę co takiego na tym obszarze chcesz robić, że potrzebujesz takiej precyzji. Ja, szczerze mówiąc, nigdy takiej precyzji nie potrzebowałem.
Trzeba także wziąć pod uwagę kwestie techniczne. Gdy powiększę obszar krzywej to trzeba będzie dodać do panela pasek przewijania, a tego za wszelką cenę staram się w moim programie uniknąć. Rozwiązaniem byłoby może osobne okno dla krzywych.

Nie podam teraz konkretnego przykładu, ale zdarzało mi się, że walczyłem o piksel w te i wewte, aż wkurzony korzystałem z windowsowej lupy... Nie rozumiem, po co pasek przewijania? W powyższym przykładzie takiego nie ma i nie widzę zastosowania. Mógłbyś po prostu zrobić 8 okienek dla każdego typu krzywych w programie (bo akurat jest ich w SNS i każdy by je sobie rozmieścił i powiększył na ile potrzebuje. Przy pełnym ekranie 1920x1200 tylkop na narzędzia jest na to spokojnie miejsce, a mnóstwo ludzi korzysta już z 1440p czy nawet 4k.

Ten algorytm aby działał w akceptowalnym czasie musiałby być wykonywany w całości na GPU. Wymaga to załadowania całego obrazu do pamięci karty graficznej, a to niestety kłopot, bo nie każda karta potrzebną ilość pamięć ma. Będę o tym myślał, gdy standardem na rynku będzie 4GB pamięci.

Cóż za problem wrzucić okienko "experimental features"? To coraz częstsza praktyka. Dajemy narzędzia entuzjastom / developerom, ale bez gwarancji działania. Photoshop już ma, Microsoft uruchomił Windows Technical Peview, w Androidzie każdy chętny znajdzie developer tools...
Akurat mam kartę z 4GB i chętnie bym sprawdził taki algorytm, a przecież z napisem 'używasz na własną odpowiedzialność' nie mógłbym mieć żadnych pretensji o nieprawidłowe działanie.

[Pebal]

Nie podam teraz konkretnego przykładu, ale zdarzało mi się, że walczyłem o piksel w te i wewte, aż wkurzony korzystałem z windowsowej lupy... Nie rozumiem, po co pasek przewijania? W powyższym przykładzie takiego nie ma i nie widzę zastosowania. Mógłbyś po prostu zrobić 8 okienek dla każdego typu krzywych w programie (bo akurat jest ich w SNS i każdy by je sobie rozmieścił i powiększył na ile potrzebuje. Przy pełnym ekranie 1920x1200 tylkop na narzędzia jest na to spokojnie miejsce, a mnóstwo ludzi korzysta już z 1440p czy nawet 4k.

Wiesz, można zrobić osiem dużych okienek, problem w tym gdzie je pomieścić. Trzeba by mieć dwa monitory, jeden na obraz a drugi na panele. Rozdzielczość ekranu nie ma większego znaczenia, bo kluczowa jest rzeczywista wielkość interfejsu.

Cóż za problem wrzucić okienko "experimental features"? To coraz częstsza praktyka. Dajemy narzędzia entuzjastom / developerom, ale bez gwarancji działania. Photoshop już ma, Microsoft uruchomił Windows Technical Peview, w Androidzie każdy chętny znajdzie developer tools...
Akurat mam kartę z 4GB i chętnie bym sprawdził taki algorytm, a przecież z napisem 'używasz na własną odpowiedzialność' nie mógłbym mieć żadnych pretensji o nieprawidłowe działanie.

Problem jest taki, że ja pracuję sam i nie bardzo mogę sobie pozwolić na wdrażanie eksperymentalnych rozwiązań dostępnych dla nielicznych. Nie mam na razie na to czasu.

[igsux3]

Wiesz, można zrobić osiem dużych okienek, problem w tym gdzie je pomieścić. Trzeba by mieć dwa monitory, jeden na obraz a drugi na panele. Rozdzielczość ekranu nie ma większego znaczenia, bo kluczowa jest rzeczywista wielkość interfejsu.

Osobiście nie znam nikogo, kto by miał desktopa i korzystał z jednego monitora. Ich ceny od lat są tak niskie, że nawet kompletni laicy mają po 2 ekrany, nawet jeden do facebooka a drugi do oglądania filmu. Ktokolwiek pracuje z grafiką/zdjęciami/filmem, zwykle ma 2, 3 a nawet 4 ekrany.
Nie znam nikogo, kto by pracował z Photoshopem i nie miał jednego ekranu na podgląd, a drugiego na panele.

A co do rzeczywistego rozmiaru, przerzuciłeś się na Direct Write? Mam Surface Pro z 220dpi i wersja 1.4 wygląda po skalowaniu wygląda tak sobie (czyli typowo po interpolacji).

Problem jest taki, że ja pracuję sam i nie bardzo mogę sobie pozwolić na wdrażanie eksperymentalnych rozwiązań dostępnych dla nielicznych. Nie mam na razie na to czasu.

Ok. No trudno, poczekam Możesz powiedzieć w przybliżeniu ile by się mielił obraz 12/24/36mpix na karcie gtx 980 z 4gb vramu za pomocą tego algorytmu?


-- edit --

wersja 2 usuwa exify przy zapisywaniu zdjęcia.

[zbyszekD7000]

czy jesteśmy zdani tylko na język EN ?