Herbert West

Zgodnie z nakazem @Behlur_Olderys przeklejam przerośnięty statut do wątku:

 

Sztuka pod tytułem "Drizzle zajmuje tyle co gotowanie obiadu dwudaniowego (albo dłużej)"

 

Dramatis personae:

@Przemek Majewski @Herbert West @Tayson @Behlur_Olderys @apolkowski @licho52@Iluvatar

 

Miejsce: mało uczęszczany zakątek Internetu, w którym zamieszkuje zakon mnichów mówiących niezrozumiałe rzeczy o niezrozumiałych rzeczach z niezrozumiałym entuzjazmem.

 

Herbert West w wolnej chwili wrzucił shitposta:

 

" Pierwszy raz drizzle integration. Myślałem że 16 rdzeni / 32 wątki to dużo :-P Zdążyłem zrobić obiad dwudaniowy na jutro i jeszcze nie skończyło.

 

Tayson podstępnie wpadł wbijając szpilę:

 

Oby zdjecie bylo warte zużytego pradu 

 

Herbert West wziął na klatę:

 

Jak go nie zepsuję zbyt sadystyczną obróbką to będzie warte :-)

 

Nie spodziewałem się, że tak długo to zajmie. No ale drizzle jeszcze nie próbowałem. Pierwsze wrażenia: ~100x300s Ha Kalifornii z drizzle 2x, drop shrink 0.7 oraz resample 50% wygląda... bardzo czyściutko.

 

Tayson zapytał:

 

Drop shrink 0.7 co to?

 

Herbert West nie wiedział więc odpowiedział:

 

To, co Jon Rista pisał żeby ustawić z default 0.9 na 0.7 a nawet 0.5. Więc ustawiłem :-)

 

Illuvatar wkleił skan zeszytu w kratkę z pierwszej klasy SP:

 

Drop shrink opisuje, jak "wejściowy" piksel (czyli przed drizzle) zostaje przeliczony na końcowy obraz po drizzle.

 

Zielona kratka to obraz po drizzle, czerwona to oryginalne piksele, a drop shrink opisuje rozmiar niebieskiego piksela. Trzeba to sobie wyobrazić tak, jakby ktoś nałożył lejek na piksel i ograniczył "zasięg rozlewania".

 

Przemek Majewski has entered the chat i  od razu z grubej rury:

 

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

 

Apolkowski zza kulis:

 

A jak te 100*500s wygląda bez drizzle? Dużo gorzej?

 

Herbert West  postanowił napisać dłuższą odpowiedź niż Przemek:

 

100x300s po WBPP nie wygląda szczególnie gorzej. Gwiazdki są bardzo ładne po drizzle, zwłaszcza te mniejsze- okrągłe, regularne. Liczę na mniejszy szum po resample do oryginalnej rozdzielczości i nieco lepsze działanie dekonwolucji przed resample. Przynajmniej mózgi na clodynights i paru innych uznanych stronach tak sugerują. Ciekawe tylko jak po resample będą wyglądać te małe gwiazdki.

 

W każdym razie, dopóki nie sprawdzę sam to nie będę wiedział.

 

Natomiast S i O nie zamierzam poddawać temu samemu procesowi- zajmuje to bardzo, bardzo dużo czasu nawet na mocnym kompie (Ryzen 9 5950X pocił się ze dwie godziny), poza tym dane bardziej zaszumione niż H. Wspomniane mózgi sugerują też, że w przypadku bardziej zaszumionych danych lepiej albo nie gorzej sprawdzi się MureDenoise zamiast Drizzle.

 

Tayson zabrał zabawki i poszedł:

 

Dzieki za odpowiedzi.

 

Herbert West  wkleił wreszcie jakieś obrazki z gwiazdami i coś z DOSa w końcu to forum astronomiczne dla geeków:

 

Różnica między obrazem ze standardową integracją (z LocalNormalization- te same pliki co użyte do DrizzleIntegration) a Drizzle Integration (Scale 2, Drop Shrink 0.7 oraz Resample 50% algorytmem Catmull-Rom- więc z powrotem w oryginalnej rozdzielczości).

Do obydwu obrazów podany identyczny STF (STF na zwykłej integracji i przeniesiony STF do obrazu drizzle). Po lewej drizzle, po prawej zwykły. Dodatkowo jeszcze noise evaluation. Skąd ta różnica po podaniu takiego samego STF?

 

Herbert West  Bezczelnie Sprowokował Przemka (skutecznie):

 

Przemek Majewski rzucisz oczyma?

 

Przemek Majewski Nie mógł się powstrzymać:

 

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" 

 

Herbert West Nie był w stanie napisać już nic dłuższego niż Przemek:

 

Drizzle po lewej - więc drizzle ma ciemniejsze tło.

Spróbuję z LinearFit jak i Integer Downsample i zobaczymy co wyjdzie.

Różnica w szumie faktycznie do pominięcia co stawia pod znakiem zapytania wykorzystywanie Drizzle jako zamiennik MureDenoise na mniej pierwotnie zaszumionych danych bo po Drizzle MureDenoise nie działa.

Na dodatek NormalizeScaleGradient także nie działa z Drizzle (ale może zacznie, gdy autor przepisze moduł w C++).

 

Kolejny raz się przekonuję, że czytanie nawet mądrych głów w necie nie zastąpi zrobienia samemu i popatrzenia na pixele.

 

Przemek Majewski przystąpił do bezczelnej promocji swojego contentu:

 

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?

 

Przemek Majewski Nie mógł spać, więc:

 

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.

 

Herbert West był już bardzo śpiący:

 

Dzięki Przemek. Chociaż uczciwe powiem, że zrozumiałem w porywach 50% :-) Reasumując, po zrobieniu próby u siebie nie widzę szczególnego powodu do przedkładania Drizzle nad NSG i MureDenoise. Może kiedyś do Drizzle wrócę, jednakże autor NSG napisał gdzieś na forum PI, że musi przepisać swoje dzieło z Javy na C++ bo inaczej trudno mu generować pliki które można zastosować w Drizzle Integration.

 

Przemek Majewski obudził się o 2 w nocy i dodał:

 

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.

 

Licho52 Postanowił porozstawiać ludzi po kątach:

 

Szkoda że takie dyskusje odbywają sie w statusach.

 

Przemek Majewski wyraża swój weltshmerz:

 

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 

 

Herbert West wyczuwa nadciągającego moderatora i postanawia jeszcze zatańczyć, póki orkiestra gra:

 

Cześć!

 

Starałem się odprawić pokutę i cofnąłem się w obróbce aż do DBE. Wszystko dalej robiłem ponownie i wiele rzeczy inaczej. Przede wszystkim:

• Żadnej dekonwolucji,
• O wiele łagodniejsze odszumianie, zwłaszcza Ha użytego jako LUM,
• Delikatniejsze MLT,
• StarXterminator z AI V.6 zamiast Starnet.

 

Udało mi się nie wklejać gwiazdek RGB wraz z towarzyszącym im halo (w przypadku jaśniejszych) ale zapłaciłem za to ich mniej "wtopionym" wyglądem- teraz wyglądają jak wklejone i dodatkowo nieco rozciapane :-/

 

Sprzęt:

• EQ6PRO
• TS65Q
• ASI1600MMP
• ASIAir V1
• FIltry: Baader Ha, OIII (buee), SII, Astronomik DeepSky RGB

 

Materiał:

• Ha: 103x300s
• OIII: 107x300s
• SII: 92x300s
• RGB: po 60x30s
• Darki, flaty, dark flaty...

 

Obróbka 100% pix, resample 80%, PNG.

 

 

Byłbym zobowiązany, jeżeli osoby, które udzielały wskazówek w poprzednim wątku teraz rzuciłyby okiem: @tex88 @Tayson @diver @wismat. Z góry dziękuję!