Przemek Majewski

oczywiscie. nie mówiąc o tym, że mała porcja szumu ani nie przeszkadza ludzkiemu nonAI a także pomaga np. w nieposteryzowaniu formatu typu jpeg pozniej. nie wiem jak z wydrukami, bo tu nie mam doswiadczenia.

też tak sądzę, bo przecież wielu "ekspertów" tutejszego forum "ma o mnie złe zdanie" zawsze wolałbym takie dyskusje prowadzić przy szerszej widowni, i moja pisanina się troche mniej marnuje wtedy...

ale zawsze mamy @Behlur_Olderys on chętnie połączy posty, wydzieli dyskusje i przerzuci ją do nowego wątku, pt. "drizzle nsg i inne". także @licho52 możesz być spokojny

predzej czy pozniej NSG wejdzie do procesów... aż żal, że wyjsciowo pix mierzył SNR w stosunku do tła nieba. i standardowe wagi snrowe były najwyzsze dla zdjec z poranka/wieczora. teraz nsg robi to porządnie używając gwiazd jako świec standardowych  drizzle to tak naprawdę zwiekszenie rozdzielczości by użyć innej interpolacji bez artefaktow ale mniej ostrej (poza rzadkimi przypadkami jak HST gdzie naprawde sluzy do odtwarzania undersamplowanego detalu). w tym sensie nsg dodaje solidną wartość do wrokflowu, a drizzle to tak, żebym mogl pogadac o metodach interpolacji...

zdecydowanie nsg rządzi, zaś ja bym chciał zrozumieć jaką korzyść czerpiesz z mure? w czym jest lepszy od tgv do szumu wysokich częstosci? ten niby fizyczny model z read noisem moglby sie tyczyc pojedynczej klatki, a do stacka i tak muszę dobierac parametry w mure. to wole w tgv z maską, local supportem itd.

I mały drobiazg. Jeśli NSG działa dobrze, to wagi od NSG to prawdziwe fizycznie wagi! nie jakieś wydumane. w dwumianowym zliczeniowym rozkladzie

wariancja = Nfotony*QE*(1-QE).

do tego sie dodaje wariancja odczytu. czyli

subNoise^2 = Rnoise^2 + Nfotony*QE*(1-QE).

czyli pomijajac stały dodatek wariancja jest proporcjonalna do wysokosci sygnalu.

I teraz mega ważne: masz dwa pomiary x1 ma błąd 1 drugi, x2, ma błąd 3. Co to znaczy?

ze jeden ma wariancje 1 drugi 9. że x1 jest wazniejszy. Optymalne wagi w tym wypadku to... odwrotnosci wariancji. np.

(9*x1+1*x2)/10 = optymalnaŚrednia.

jest to estymator o najnizszej wariancji.

Teraz co zabawne, jesli na 13 subie masz połowę sygnału w porównaniu do 17 suba to... znaczy, że możesz oszacować prawdziwy SNR. Tym sygnalem gwiazd i jego wariancją. To doprowadzi do matematycznie poprawnego ważenia i takie oferuje NSG. Gwiazdy mają tak wysoki sygnał, że ten read noise jest pomijalny i NSG rozkminia które suby są wartosciowe. Literalnie mowi Ci:

sub13 -> jedna porcja sygnału

sub17 -> dwie porcje sygnalu

sub19 -> 0.3 porcji itd.

także używanie NSG w tej chwili powinno dawać minimalny szum i poprawne ważenie. więc problemy z drizzle mozna odstawić. Można się upodobnić do drizzle'a w przypadku np bardzo undersamplowanych danych przez uzywanie specyficznej interpolacji w rejestracji. To jest opcja zwykle zapominana tam na dole. A wystarczy porejestrowac 1 plik i przeszukać okolice gwiazd i hot pikseli. i dobrać clamping w spline, albo zdecydować się na lanczosa lub nie etc.

nie zastąpi. ja używam drizzle z przyzwyczajenia, ale z kilku powodow

1) kliknięcie "generate drizzle data" nic nie boli -- nie trzeba robic drizzle

1a) naturalnie chwilowa niezgodnosc NSG z drizzle mocno podkopuje drizzle (trzeba przeprogramowac drizzle tak by rozumialo.jak skorzystac z przeskalowania gradientu, umie korzystac z LN wiec sadze, ze autorowi NSG nie chcialo sie juz, lub nie umial wygenerować plików typu local normalization

1b) gdyby NSG zamiast skalowac gradient generował pliki "local normalization" (rownowazne skalowaniu grafientu), to wszystko działaloby tak samo. sugerowalem to, ale nie wiem, czy jest to możliwe bo nie wiem jakie ograniczenia ma LN, jesli to tylko sklejone obszarami transformacje liniowe to pewnie nie moga pomiescic tego co NSG

1c) mure nie polubilem

2) reasumujac: preferowalbym NSG jako ze to ważenie sygnalem gwiazd, ktorego mi strasznie brakowalo i musialem sam kombinowac

3) drizzle uzywam w osc jesli chxe uniknąc debajerowania, choc mozna uzyc debajer bilinear i bedzie podobnie, albo do zmiany rozdzielczosci o 2/3 "x2 bin3" i wlasciwie poza tymi jest mały zysk.

4) nie chodzi o szum, bo szum poprawia odrzucanie i normalizacja, i stackowanie. drizzle powinien miec taki sam szum, nijak tego aspektu nie poprawia, i tak jest (w twoich plikach); drizzle jest wolny od artefaktow nieliniowej interpolacji. dlatego downsample wtedy lepiej robic metodami ktore z kolei z kolei znowu nie wprowadzą takowych. czyli np bin2. wiec wlasciwie o to chodzi. przesuwane hot pixele np. lubia miec pierscienie. otoczenue malych gwiazd podcina sie ciemniej itd. z tym walczysz.

widziałes to moje?

to jest zawsze dłuższa sprawa -- zacznę od pierwszego pytania: integrację z "niedrizzle" i "drizzle" (bądź z jakiejkolwiek innej metody) mogą wyjść inaczej znormalizowane --> żeby nakładać ten sam stretch trzeba najpierw użyć narzędzia "Linear Fit" i sprawdzic w "Inspection|Statistics" czy mediana oraz sqrt(BWMV) są podobne. dopiero później nałożyć ten sam stretch. Stretch na astrofotach to potężna funkcja wykładnicza, coś typu "pierwiastek dziesiątego stopnia", i ona może dawać okropne różnice jeśli na jednej integracji jest tło 320 a na drugiej 330 poziomów.

zmniejszanie 50% jest tak dobrze uwarunkowane, że nie odrózni się za bardzo spline, cubic, Hermite, Catmull-Rom od siebie. ja bym po prostu kliknął lupkę 2:1  to nie ma dużego znaczenia.

znacznie znacznie większe znaczenie ma to jakiej interpolacji użyłeś w "Registration", na dole jest od tego panel. I tam zarówno Lanczos, jak i Cubic mają swój "clamping threshold", to taki parametr deringujący. z tymi interpolacjami jest taki problem, że dają ostrzejsze obrazki ale za to krzywa ucieka nieco pod poziom kiedy pik sie konczy ( nie zawraca od razu, stad ciemne ringi w wielu smartfonowych fotach dookola jasnych punktow).

proste ćwiczenie -- jak przesunąc biały piksel na środku pieciu szarych (np. 0.2 0.2 1 0.2 0.2 ) pikseli o pół piksela w lewo? wystarczy sie chwilkę nad tym zastanowić, by zrozumieć, jakie problemy się tu napotyka.

ps: jak ktoś jest bardzo odważny to można od siebie te dwa "linear dofitowane staki" odjąć, dodając jakiś piedestał np 0.1, zeby uniknąc zer. coś w stylu pixmath("stack1-stack2+0.1", rescale result). to ładnie pokazuje ringi, dookola gwiazd, i czym się różnią etc. tak zerkając na te zdjecia na monitorze, to widzę, ze jedno (to po drizzle'u), ma wyraźnie jasniejsze tło.

ps2. rozumiem, że chciałeś zastosować technikę drizzle x2 i resample x0.5. to jest całkowicie przeciwskuteczne wedlug mnie i zwyczajną stratą czasu (wystarczy drizzle x1 z niewielkim shrink faktorem, albo zmienić ustawiena interpolacji w rejestracji na bilinear), niezależnie od tego co mówi internet. jedyne co lubilem robic z takich rzeczy, to drizzle x2, a pozniej Integer Downsample x3 median (żeby wygladzic rezultat i dokonac skalowanie 2/3 bez interpolacji nieliniowej).

ps3. różnice w szumie są jakieś aptekarsko przypadkowe, te algorytmy też nie są świete, i w zależnosci od tych szczatkowych wyników innej interpolacji dla rejestracji mogą sie nieco różnić. weź ten stack drizzle x2 i zrób interger downsample x2 i zobacz jaki szum wtedy będzie wg mnie wtedy bedzie epsilon mniejszy od stacka "niedrizzle"

@Tayson udziele prostej  drop shrink udaje tak, jakby pomiędzy pikselami były szpary, a trudniej:

drizzle x1 jest równoważny biliniowej interpolacji, taka trochę "rozplywa" detal, ale za to nie "ringuje". gdy zmniejszyć piksel a priori np do 80% jego wielkosci, to wtedy ten drizzle jest nieco bardziej ostry -- ale bardziej skory do "niezapełniania" całej siatki. Ja stosuję zwykle cfa drizzle x1 bez drop shrink (1.0, ale to do OSC) lub drizzle x1 z drop shrink 0.8

Nie no co Ty, swietnie, przeraził mnie po prostu ten czarny kształt potworny

A ja naturalnie odprzeprosiłem i przyznałem, że złośliwymi odpowiedziami lałem wodę na młyn  No cóż, ulegam pyskówkowemu sportowi. >>Nobody's perfect<< jak mawia @Behlur_Olderys