Sory, przeoczyłem Twój wpis.

mt wrote:
> Mam takie pytanie, są jakieś konkretne wymagania sprzętowe aby program
> działał w miarę płynnie?

Pod kątem wydajności program można rozgraniczyć na dwie części:
1. Wczytywanie plików + mapowanie tonów.
2. Dobieranie parametrów.

Pierwsza część jest najbardziej wymagająca, jednak trudno określić dla niej
minimum. Im wolniejszy procesor, tym dłużej trwają obliczenia.
Można jednak ograniczyć wielkość ładowanych obrazów, co przyspiesza
obliczenia koszem rozmiaru. Dwukrotnie zmniejszenie obrazu to czterokrotnie
szybsze obliczenia. Dla porównania na moim Q9550 (4 rdzenie), zdjęcie 12Mpix
w pełnej rozdzielczości, ładuje się 1m 35s.

Druga część jest mniej wymagająca a jej wydajność jest zależna od wielkości
okna programu. Wszystkie zmiany są wyświetlane w czasie rzeczywistym,
dlatego im większe okno, tym większe zapotrzebowanie na moc procesora. Do
pracy w rozdzielczości Full HD dobrze mieć procesor z dwoma rdzeniami.

Jeżeli chodzi o pamięć, to powinno jej być co najmniej 2GB.

Pozdrawiam,
- Bastek -

do góry

Uzytkownik "Sebastian Nibisz" <e...@g...pl> napisal w wiadomosci
news:hm14nn$tn$1@inews.gazeta.pl...
> XX YY wrote:
>> ale ja skladam 3 zdjecia roznie naswietlone
>> -2 ev , 0 ev +2ev.
>> kazde z tych zdjec obejmuje jakis tam waski inny powiedzmy 10 ev
>> zakres dynamiczny
>> ale te 3 zdjecia zlozone razem obejmuja ju zakres 14 ev.
>>
>> i to jest sens hdr.
>
dwa x i y ma racje, trzeba mu oddac honor za testowanie i trafne uwagi, co
przyczynilo sie do
poprawy i rozwoju Twojego programu. Tobie szacunek za program. Wynika, ze do
zbalansowania róznicy
tonów z jednego RAW jest bardzo dobry. Jesli chodzi o szerszy zakres z kilku
naswietlen - potrzebny
inny program. Co do ceny, moim zdaniem, po testach 2 razy xy, (bardzo przydatny
jegomosc) powinien
kosztowac max 1/2 ceny PM. Wiecej ludzi kupi, wiecej zarobisz. To nie PS, chociaz
adobe tez juz
troche otrzezwial i sprzedaje lzejsze wersje w ludzkiej cenie, lepszy rydz niz nic.
pozdr
j

do góry

Sebastian Nibisz pisze:
> Sory, przeoczyłem Twój wpis.
>
> mt wrote:
>> Mam takie pytanie, są jakieś konkretne wymagania sprzętowe aby program
>> działał w miarę płynnie?
>
> Pod kątem wydajności program można rozgraniczyć na dwie części:
> 1. Wczytywanie plików + mapowanie tonów.
> 2. Dobieranie parametrów.
>
> Pierwsza część jest najbardziej wymagająca, jednak trudno określić dla
> niej minimum. Im wolniejszy procesor, tym dłużej trwają obliczenia.
> Można jednak ograniczyć wielkość ładowanych obrazów, co przyspiesza
> obliczenia koszem rozmiaru. Dwukrotnie zmniejszenie obrazu to
> czterokrotnie szybsze obliczenia. Dla porównania na moim Q9550 (4
> rdzenie), zdjęcie 12Mpix w pełnej rozdzielczości, ładuje się 1m 35s.

Przyznaję, mój komputer ma już swoje lata (jak na komputer oczywiście) i
na P4 2 GHz nef 6 Mpix ładuje się około 12 minut.

> Druga część jest mniej wymagająca a jej wydajność jest zależna od
> wielkości okna programu. Wszystkie zmiany są wyświetlane w czasie
> rzeczywistym, dlatego im większe okno, tym większe zapotrzebowanie na
> moc procesora. Do pracy w rozdzielczości Full HD dobrze mieć procesor z
> dwoma rdzeniami.

Tutaj też niestety nie jest u mnie różowo, zmiana wielkości
wyświetlanego zdjęcia to już czekanie kilka sekund na przeskalowanie obrazu.
Do czego zmierzam, generalnie są jakieś szanse w przyszłości na
optymalizację kodu pod względem zapotrzebowania na zasoby sprzętowe czy
raczej zostanie jak jest?

--
pozdrawiam
marcin

do góry

janek wrote:
> Jesli chodzi o szerszy zakres z kilku naswietlen - potrzebny inny program.

Widocznie nie widziales, jak program SNS-HDR sklada obrazy o naprawde duzym
zakresie dynamiki. XX YY pisze o naswietlaniu kilkukrotnie sceny, której
dynamika spokojnie miesci sie w jednym strzale i chcialby uzyskac
"podrasowany" obraz. SNS-HDR nie byl tworzony do tego typu obróbki. Ten
program potrafi skladac, naturalnie wygladajace obrazy, których dynamika nie
miesci sie w 9 ekspozycjach (krok 1EV). Niejednokrotnie przy takich obrazach
PM robi glupoty, ze glowa boli.

> Co do ceny, moim zdaniem, po testach 2 razy xy, (bardzo przydatny
> jegomosc) powinien kosztowac max 1/2 ceny PM. Wiecej ludzi kupi, wiecej
> zarobisz. To nie PS, chociaz adobe tez juz troche otrzezwial i sprzedaje
> lzejsze wersje w ludzkiej cenie, lepszy rydz niz nic.
> pozdr

Jest wersja SNS-HDR Home, która kosztuje nawet mniej niz 1/2 ceny PM a
oferuje znacznie wiecej.

Pozdrawiam,
- Bastek -

do góry

mt wrote:
> Do czego zmierzam, generalnie są jakieś szanse w przyszłości na
> optymalizację kodu pod względem zapotrzebowania na zasoby sprzętowe czy
> raczej zostanie jak jest?

Program ma swoje wymagania, bo przetwarza ogromne ilości danych. Można
optymalizować operacje wykonywane na tych danych, ale i tak wszystkie dane
trzeba "obskoczyć". Wąskim gardłem u Ciebie może być wydajność pamięci.
Jedyną drogę jaką widzę do optymalizacji, to dodanie wsparcia GPU. Takie
wsparcie zostanie dodane, jednak wymagać one będzie karty graficznej
wspierającej OpenCL.

Pozdrawiam,
- Bastek -

do góry

Użytkownik "Sebastian Nibisz" napisał
> Pierwsza część jest najbardziej wymagająca, jednak trudno określić dla
> niej minimum. Im wolniejszy procesor, tym dłużej trwają obliczenia.
> Można jednak ograniczyć wielkość ładowanych obrazów, co przyspiesza
> obliczenia koszem rozmiaru. Dwukrotnie zmniejszenie obrazu to
> czterokrotnie szybsze obliczenia. Dla porównania na moim Q9550 (4
> rdzenie), zdjęcie 12Mpix w pełnej rozdzielczości, ładuje się 1m 35s.

U mnie na C2D T9500, 2GB ram również 12mpix raw wczytuje się 3 minuty.

adam

do góry

Sebastian Nibisz pisze:
> mt wrote:
>> Do czego zmierzam, generalnie są jakieś szanse w przyszłości na
>> optymalizację kodu pod względem zapotrzebowania na zasoby sprzętowe
>> czy raczej zostanie jak jest?
>
> Program ma swoje wymagania, bo przetwarza ogromne ilości danych. Można
> optymalizować operacje wykonywane na tych danych, ale i tak wszystkie
> dane trzeba "obskoczyć". Wąskim gardłem u Ciebie może być wydajność
> pamięci.
> Jedyną drogę jaką widzę do optymalizacji, to dodanie wsparcia GPU. Takie
> wsparcie zostanie dodane, jednak wymagać one będzie karty graficznej
> wspierającej OpenCL.

Dzięki za odpowiedź, zdaję sobie sprawę że konieczność zmiany komputera
zbliża się dużymi krokami i tak się w sumie tylko zastanawiałem na ile
da się program "przyspieszyć". Tak z innej beczki, to nie mogłem kiedyś
pojąć, że dwa różne programy potrafią wykonywać tę samą operację w
diametralnie różnym czasie. A chodziło o to iż swego czasu potrzebowałem
edytora tekstowego do banalnej wydawałoby się rzeczy, a mianowicie
zamiany przecinków na kropki bądź odwrotnie w plikach tekstowych,
chodziło o podmianę kilkudziesięciu milionów znaków. Jednym z
nielicznych programów, który uciągnął w ogóle kilkudziesięciomegowe
pliki ASCII tekst był PSPad i operacja zamiany zajmowała mu około 20-30
minut. Następnie trafiłem na UltraEdit i ta sama operacja na tym samym
pliku i komputerze zajmowała mu około 10 sekund! Różnica była naprawdę
kolosalna.

--
pozdrawiam
marcin

do góry

On 24 Feb., 02:16, "adam"
<j...@o...maile.com> wrote:
> Użytkownik "Sebastian Nibisz" napisał
>
> > Pierwsza część jest najbardziej wymagająca, jednak trudno określić dla
> > niej minimum. Im wolniejszy procesor, tym dłużej trwają obliczenia.
> > Można jednak ograniczyć wielkość ładowanych obrazów, co przyspiesza
> > obliczenia koszem rozmiaru. Dwukrotnie zmniejszenie obrazu to
> > czterokrotnie szybsze obliczenia. Dla porównania na moim Q9550 (4
> > rdzenie), zdjęcie 12Mpix w pełnej rozdzielczości, ładuje się 1m 35s.
>
> U mnie na C2D T9500, 2GB ram również 12mpix raw wczytuje się 3 minuty.
>
> adam

raw wczytuje sie pare sekund
3 minuty trwa tonmaping , ale to we wszystkich programach tak jest
zalezy od rozdzilczosci pliku i sprzeto efkoz.
program nie jest wolniejszy od innych pod tym wzgledem.

do góry

>
> Jezeli scena miesci sie w 10 EV, to nie ma sensu rejestrowac 14EV, chyba, ze
> chce sie redukowac szumy.

rozpietosc sceny z samolotem jest olbrzymia
wybralem taki motyw - od czarnych opon w cieniu do wysokich refleksow
na srebrenej , polerowanej blasze.
nie mierzylem dokladnie ile ev ale z pewnoscia przekracza zakres
dynamiczny jaki jest w stanie zarejestrowac matryca.
zakres dynamiczny matrycy to ok 9 - 10 ev .
zakres tej sceny oceniam tak na oko na co najmniej 20 ev.

> Ja wiem do czego zmierzasz, ale to nie jest istota HDR. Ty chcesz miec
> wieksza rozdzielczosc bitowa aby m c zwiekszac lokalna dynamike.

NIE , calkowicie chodzi o cos innego.

powiedzmy ze mam te scene o zakresie od 0 do 20 ev. i matryce zdolna
zarejestrowac 10 ev.


robie 1 zdjecie wg swiatlomierza i powiedzmy zostanie zarejestrowana
na jednym rawie scena w zakresie np 5 - 14 ev. ( zdj nr1)

robie zdj nr 2 naswietlajac na -2ev - zostanie zarejestrowana scena
w zakresie 3 - 12 ev

robie zdje nr 3 naswietlajac na +2 ev zostanie zarejestrowana scena w
zakresie 7-16 ev

mam 3 Rawy , kazdy obejmuje tylko 10 ev , ale w sumie mam na nich
objety zakres os 3 do 16 ev


i teraz skladam te 3 rawy
mam w sumie zakres danymiczny sceny 3-16 ev na jednym zdjeciu - to
jest hdr

i jeszcze musze moc zobaczyc to zdjecie np na monitorze o zakresie
tonalnym powiedzmy 8 EV

i teraz potrzebyn jest tonmaping - "scondensuje " obraz o zakresie
3-16 ev ( zakr 14 ev) do mozliwosci monitora 8 ev.

i dzieki temu zobaczymy wystepujace w naturze glebokie czernie i
wysokie swiatla na jednym zdjeciu.


>
> Prawdziwy HDR jest wtedy, gdy dynamika jest na tyle duza, ze nie mozna jej w
> calosci odwzorowac.

wybralem takie zdjecie , ktore dynamicznie nie zmiescilo sie na 1
rawie.
to sa 3 zdjecia naswietlane -3ev , 0ev +3ev.
cudow nie ma .
" jasnosc" kazdego rawu jest taka sama ( ona zawsze musi byc
identyczna , ale kazdy z rawow obejmuje inny obszar jasnosci
wystepujacej w naturze.

> HDR to nie zdjecie zlozone z kilku ekspozycji. HDR to zdjecie o duzym
> zakresie dynamiki.

dynamika jaka obserwujesz jast zawsze taka sama - jest ona ograniczona
przez dynamike urzadzenia wyjscia.

caly dowcip hdr zasadza sie na tym aby szersza dynamike zarejestrowana
w raw pokazac na urzadzeniu o mniejszej dynamice wyjscia.

w technice HDR ( czy tez zwanej hdri ) wyroznia sie 2 etapy:

1. rozszerzenie zakresu dynamicznego jaki moze objac matryca - osiaga
sie to przez autobracketing i zlozenie kilku expozycji
2. Dopasowanie szerokiego zakreszu dynamicznego po zlozeniu kilkiu
zdjec do zakresu dynamiczengo urzadzenia wyjscia - tonmaping.



>
> SNS-HDR blizej do oryginalu i taka przyswieca mu idea. To nie jest program
> do wydobywania ze zdjec szczeg l w, kt rych w normalnych warunkach nie
> widac. Do tego lepiej nadaje sie Machinery.


obydwa przyklady samolotu , ktore podalem - robione za pomoca PM i
SNS sa rownie blizkie oryginalowi .
obydwa za blizsze oraginalowi od pokazanego zdjecia zrobionego z
oryginalnego RAW bez obrobki.


Moznaby nieco poprawic " urealistycznic " zdjecie oryginalne
odpowiednio manipuluajac suwakami i gnac krzywe .
jest to inny rodzaj obrobki niz daje tonmaping. Tonmaping z definicji
to obrobka pozwalajaca urealistycznic przeksztalcenie obrazowe ,
gdyz z definicji uwzglednia ona aspekt fizjologiczny.

Jezeli jednak wynik SNS z jednego zdjecia jest identyczny jak z
trzech zdjec tzn ze skladanie zdjec nie jest portzebne.
TZN ze ono nie dziala.

Moim zdaniem w tej formie o czym juz pisalem program jest wolarka
rawow oparta na zasadzie tonmapingu ( ma to tez FM) , z tym ze moim
zdaniem w SNS tonmaping dziala lepiej niz w FM.
Na ladnie naswietlonych , rozpietych tonalnie scenach dostalem wynik
identyczny , w scenach trudnijszych , np w swietle sztucznym wynik z
SNS jest lepszy. Obserwuje w FM bledy dyskawlifikujace czesto
tonmapimg z tego propgramu. w SNS tonmaping dziala prawidlowo.

Moim zdaniem aby rzeczywisice zrobic z sns program typu hdr ( hdri)
nalezy zmienic filozofie w podejsciu do algorytmu skladajacego 3 rawy
( przeliczajacego obraz z 3 rawow do jednego ) .
Bedzie rownie naturalnie , a szerzej dynnamicznie.

Nie pisze tego w formie krytykanctwa - wrecz przeciwnie , wyrazilem
wiele pochlebnych opini.
Program jest gotowy w 99% , ten brakujacy 1 % moze zadecydowac czy
siegnac po FM; czy sns.

pzdr

do góry

XX YY pisze:
> On 24 Feb., 02:16, "adam"
> <j...@o...maile.com> wrote:
>> Użytkownik "Sebastian Nibisz" napisał
>>
>>> Pierwsza część jest najbardziej wymagająca, jednak trudno określić dla
>>> niej minimum. Im wolniejszy procesor, tym dłużej trwają obliczenia.
>>> Można jednak ograniczyć wielkość ładowanych obrazów, co przyspiesza
>>> obliczenia koszem rozmiaru. Dwukrotnie zmniejszenie obrazu to
>>> czterokrotnie szybsze obliczenia. Dla porównania na moim Q9550 (4
>>> rdzenie), zdjęcie 12Mpix w pełnej rozdzielczości, ładuje się 1m 35s.
>> U mnie na C2D T9500, 2GB ram również 12mpix raw wczytuje się 3 minuty.
>>
>> adam
>
> raw wczytuje sie pare sekund
> 3 minuty trwa tonmaping , ale to we wszystkich programach tak jest
> zalezy od rozdzilczosci pliku i sprzeto efkoz.
> program nie jest wolniejszy od innych pod tym wzgledem.

No niestety jest, to samo zdjęcie, z którym SNS radzi sobie w około 12
minut, w Photomatixie zajmuje około 3 minut i to jeszcze z klikaniem w
międzyczasie. Możliwe, że przy szybkich wielordzeniowych procesorach te
różnice się zacierają, ale przy moim jednordzeniowcu różnica jest
odczuwalna.

--
marcin

do góry