Drizzle zajmuje tyle co gotowanie obiadu dwudaniowego (albo dłużej)

[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:

 

Tak jakoś wyszło z tym statusem. Wrzuciłem shitpost że Drizzle trwa tyle co gotowanie obiadu i patrz :-) Ale chyba nie pozostaje nic innego niż kontynuować.

 

Drizzle idzie w odstawkę na razie. Natomiast MureDenoise muszę się przyjrzeć. Teraz walczę ze sobą i z Pixem o zachowanie pewnego poziomu szumu wysokiej częstotliwości a ścięcie niższej bo to ewidentnie lepiej wygląda. Na subie z~10h Ha jest i tak niewiele szumu, więc bardziej O i S mnie interesują. Zastanawiam się jakie kaskadowe efekty ma MD na dalsze prace. Jak znajdę chwilę to spreparuję kilka-kilkanaście subów z różnymi ustawieniami MD i popatrzę na pixele. Ale wtedy już rozpocznę normalny wątek. A może NoiseGeneration ;-P ?

 

Przemek Majewski  tańczy ostatnie tango:

 

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.

 

GRZMOT, TRZASK, KRZYKI I PANIKA, NA SCENĘ WPADA @Behlur_Olderys:

 

@Przemek Majewskialbo @Herbert Westzałóżcie nowy temat i użyjcie Copy&Paste. Silnik forum nie pozwala jeszcze na przenoszenie ze statusów. Ja tu niewiele mogę pomóc niestety.

 

Herbert West tragicznie wrzuca ostatni wpis kilka sekund po @Behlur_Olderys lecz nie ma już publiczności, nie ma moda, nie ma aktorów.....

 

Ciekawa sprawa z ludzką subiektywną percepcją i szumem- przynajmniej wysokiej częstotliwości. Ciekawe czy ma to cos wspólnego z usypianiem dzieci za pomocą akustycznego białego szumu (definitywnie działa).

Kiedyś bawiłem się TopazDenoize (przestałem po godzinie) który potrafi rozsmarować wszystko na gładko i faktycznie jpeg z tego trochę posteryzował.

Dzięki za dyskusję Przemek Majewski Następnym razem wrzucę posta zamiast statusu.

 

 

ŚWIATŁA POWOLI GASNĄ, NASTAJE CIEMNOŚC, TEMPERATURA DĄŻY DO 0 K LECZ NIGDY TAM NIE DOTRZE..... KURTYNA.

Edytowane 23 Listopada 2021 przez Herbert West
formatowanie

[Przemek Majewski]

to się nazywa stachanowiec... zawstydziłeś mnie @Herbert West. uszanowanie

 

xD

[Herbert West]

@Przemek Majewski Mogłem poćwiczyć podstawowe kompetencje twórcze (CTRL+C, CTRL+V) i jeszcze trochę narozrabiać, więc czemu nie ;-)

[Behlur_Olderys]

@Herbert West dzięki, jak widać temat dużo zyskał dzięki przeniesieniu:) Powiedz jeszcze koniecznie jaki obiad gotowałeś: rosół i bigos (cały dzień) czy bardziej zupa w proszku + odgrzewana pizza?

 

 

 

[Herbert West]

1 minute ago, Behlur_Olderys said:

@Herbert West dzięki, jak widać temat dużo zyskał dzięki przeniesieniu:) Powiedz jeszcze koniecznie jaki obiad gotowałeś: rosół i bigos (cały dzień) czy bardziej zupa w proszku + odgrzewana pizza?

 

Pomidorowa z przecieru z cebulą, czosnkiem, świeżym imbirem i cayene oraz tarta szpinakowa z octem balsamicznym, gałką muszkatałową i również świeżym imbirem... Odpowiadam tylko dlatego na ten offtop, ponieważ obrazuje to co można zrobić w domu, gdy do astrofoto używa się Drizzle Integration.

[count.neverest]

2 godziny temu, Herbert West napisał:

świeżym imbirem i cayene

 

Szanuję Cię za to.

[RMK]

Chciałem przy kawie przeczytać całość ale przewinąłem w dół celem oszacowania długości wątku. Przeczytałem posta z przepisem i tak mi narobiliście smaku, że czytanie poczeka chwilkę, kawa będzie po południu. Idę zrobić coś do jedzenia. Proszę admina do dodanie do regulaminu forum punktu aby nie publikować przepisów kulinarnych.

[Herbert West]

Wykolejanie własnych wątków idzie mi o wiele lepiej niż astrofotografia ;-)

[Behlur_Olderys]

15 minut temu, RMK napisał:

Idę zrobić coś do jedzenia.

Chciałeś powiedzieć: idę sprawdzić kilka nowych, czasochłonnych algorytmów stackowania

[Zlew]

Narrację wątku czytałem jak powieść  Treść będę musiał tak po pracy na spokojnie  

[isset]

Zawstydzić @Przemek Majewski -> bezcenne  

[rambro]

Byłem przekonany że drizzle przydaje się z obrazem zbyt małej rozdzielczości "undersampled". Może ktoś w skrócie napisać po co stosować drizzle jeśli nie mamy do czynienia z undersampling ?.

[Herbert West]

Byłem ciekaw jak to działa, ile zajmuje i oczywiście- co daje. Użyłem na obrazach, które nie były dotknięte undersamplingiem. Wyczytałem na cloudynights, między innymi, że całkiem dobre efekty daje drizzle z drop shrink w granicach 0.7, wstępna obróbka (dekonwolucja zwłaszcza) i resample to oryginalnej rozdzielczości- zarówno w zakresie detali jak i szumu. Nie za bardzo widzę opisywane efekty, szczerze mówiąc.

 

EDIT: Efekty w zakresie szumu. Ale efektów z DECON na 2x większej rozdzielczości nie sprawdzałem jeszcze. Może bliżej weekendu coś wrzucę na forum.

Edytowane 23 Listopada 2021 przez Herbert West

[Herbert West]

24 minutes ago, isset said:

Zawstydzić @Przemek Majewski -> bezcenne  

 

Tak, tylko że on pisał  o ważnych rzeczach a ja o zupie pomidorowej :-)

[Tayson]

Bawilem sie w testy drizzle dla swojej matrycy ICX695. Nic dobrego nie wychodzilo. Np drizzle 2x, potem downsize 0.5x, vs stack w natywnej rozdzielczosci, to natywna rozdzielczosc zawsze wygrywała wgledem ilosci szumow oraz jakosci chociazby gwiazdek.

 

[Herbert West]

3 minutes ago, Tayson said:

Bawilem sie w testy drizzle dla swojej matrycy ICX695. Nic dobrego nie wychodzilo. Np drizzle 2x, potem downsize 0.5x, vs stack w natywnej rozdzielczosci, to natywna rozdzielczosc zawsze wygrywała wgledem ilosci szumow oraz jakosci chociazby gwiazdek.

 

 

Moje wstępne wnioski są podobne- nie zauważam żadnej różnicy na plus. Na minus też chyba nie, więc po co sobie głowę zawracać. Jeszcze chyba sprawdzę dekonwolucję i przypuszczam, że to będzie koniec eksperymentu.

[Przemek Majewski]

8 minut temu, Tayson napisał:

Bawilem sie w testy drizzle dla swojej matrycy ICX695. Nic dobrego nie wychodzilo. Np drizzle 2x, potem downsize 0.5x, vs stack w natywnej rozdzielczosci, to natywna rozdzielczosc zawsze wygrywała wgledem ilosci szumow oraz jakosci chociazby gwiazdek.

 

tu mnie zdziwiłeś. zwykle nie powinno być po prostu różnic. rożnice zwykle pojawiają się wlasnie w artefaktach typu zipy, ringy i inne rzeczy. ale fakt, mozna to kontrolować wybierając metodę interpolacji w rejestracji (jesli takie problemy są)

 

co do podsumowania @rambro:

 

ogolny ton rozmowy jest taki, że NSG daje benefity w poprawnym ważeniu klatek i to wymierna korzyść,  drizzle (jeśli nie mamy problemów z undersamplingiem) zwykle nie zmienia nic, ewentualnie uchroni od pewnych artefaktow interpolacji (akademicka sprawa).

 

trochę w tym wątku:

 

 

 

 

[Pawcio]

Można zawsze wprowadzić nową miarę trwania procesu np:

drizzle=Pomidorowa z przecieru z cebulą, czosnkiem, świeżym imbirem i cayene oraz tarta szpinakowa z octem balsamicznym, gałką muszkatałową i również świeżym imbirem...

stack 50 klatek= podgrzanie pizzy w piekarniku

dekonwolucję = ? .. no właśnie

 

Swoją drogą bardzo przyjemnie czytało się ten post, niczym "Tylko dla orłów" Alistair MacLean  - przy okazji przemyciłeś sporo zagadnień astrofoto A ja wieczorem  czyba zrobię naleśniki w Wy sobie wymyślcie jaki proces w PiXie uruchomię

Edytowane 23 Listopada 2021 przez Pawcio

[Paether]

6 godzin temu, RMK napisał:

Proszę admina do dodanie do regulaminu forum punktu aby nie publikować przepisów kulinarnych.

 

Bez szans  Musiałbym wtedy sobie wlepić auto-bana 

 

 

[Herbert West]

Dobra Panowie, żarty na chwilę stop bo moderatorzy pomyślą, że tu tylko śmiecę. Zwłaszcza zapraszam @Przemek Majewski. Udało mi się znaleźć coś, co może być ciekawe- jednak są różnice gdy się porówna porządnie a nie na chybcika, choć być może jest to temat bardziej akademicki. Zrobiłem tak:

 

1. Obydwa pliki- integracja z Local Normalization / Generalized Extreme Studentized Deviate Test oraz Drizzle z plikami LocalNorm wykorzystanymi przy zwykłej integracji -> LinearFit (zwykły do drizzle).

 

2. Resample H_Drizzle do zwykłego rozmiaru.

 

3. DynamicCrop.

 

4. ImageStatistics:

 

 

5. NoiseEvaluation z następującymi, wynikami:

 

 

6. Identyczny STF na obydwu i kilka porównań- zwykły po lewej, drizzle po prawej:

 

 

 

 

7. Pixelmath jak sugerował Przemek: (H_LN-H_DRIZZLE)+0.1

 

 

8. Zapisałem pliki w formacie .tiff (po resample i DynamicCrop) Możecie pobrać je tutaj przez tydzień: https://1drv.ms/u/s!AjNBHKkQrQLmhLQiA1hKUxA_eJIM6w?e=UOk93c

 

Discuss!

[Przemek Majewski]

@Herbert West wow. dałbym 2 puchary

 

no i na róznicy widać gdzie te rożnice są. tak "krótko", to jedne interpolacje są bardziej ostre ale mają artefakty, a inne mniej szumne, ale za to bardziej rozmyte

 

ponadto w statystykach włącz sobie sqrt(BWMV), warto.

 

BWMV strasznie brzmi -- Biweight Midvariance, ale to nie takie straszne, wyjasnie:

- MAD, median absolute deviation, to mediana odchyleń od mediany. "robustny" estymator zakresu.

- BWMV to taka odpowiednio ważona wariancja, która bierze histogram tylko do 9 MAD. (coś jak odrzucanie 3 sigma, tyle, że 9 MAD).

- jak ktos lubi grzebac w pixie to MAD i BWMV pojawiają się w wielu miejscach

- do czytania

https://en.m.wikipedia.org/wiki/Robust_measures_of_scale

 

 

 

[Przemek Majewski]

no i oczywiście przez rozkojarzenie i migrene nie napisałem dlaczego "robustne":

- wezmy taki hot pixel, 65000, a mediana zdjecia? 400. ten hot pixel w odchyleniu KWADRATOWYM wystarczy by zaburzyc bardzo obliczenie zwyklego odchylenia kwadratowego

- MAD to mediana odchyleń od mediany. mediana jest odporna na skrajne wartosci, niewrażliwa w ogole na dodanie jednej prawej i jednej lewej. wiec mediana odchyleń ładnie pokazuje jaki "rozrzut" głownego tła zdjecia

- 9 MAD to dosc dobry zakres w ktorym mozna badać wariancje. nieco skomplikowane wyrazenoe z wagami zależącymi od odleglosci danej od mediany w jednostkach MAD skutkuje wlasnie owym BWMV

 

[Herbert West]

I jak myślisz @Przemek Majewski? Jak dla mnie Drizzle jednak jest opcją jeżeli autor NSG przepisze skrypt w C++ i będzie można go używać razem z Drizzle.

[Przemek Majewski]

25 minut temu, Herbert West napisał:

I jak myślisz @Przemek Majewski? Jak dla mnie Drizzle jednak jest opcją jeżeli autor NSG przepisze skrypt w C++ i będzie można go używać razem z Drizzle.

no tak. ja zwykle z przyzwyczajenia robię. a drizzle data generuje zawsze. tyle, że tu to mówię. pewien zysk (w postaci mega drobnych artefaktow) w przesuwaniu pixeli inną interpolacją itd. raczej nie ma straty.

 

natomiast NSG i matematyczna weryfikacja ile jest sygnału na każdej klatce? do tej pory, bez nsg mozna bylo robic tak (eksperymentowalem)

- zdefiniowac proces dbe na jednej klatce

- wrzucic lighty do image containera

- odpslic dbe na wszystkich skalibrowanych lajtach

- pozniej integracja z ważeniem automatycznym i normaiuzacją ax+b

 

To oczywiscie (plus mierzenie intensywnosci gwiazd) jest teraz elegancko zawarte w NSG. I to jest naprawdę DUŻO. Ale nic by nie zaszkodziło, jakby razem z tym dużo działało też "troszkę" drizzle. Ponadto NSG jako proces będzie wiele razy szybsze i lepiej zoptymalizowane. Wielowątkowe etc.

[Herbert West]

A, właśnie. Odnośnie metod ważenia- w PIX 188-10 wypada stara noise evaluation i wchodzą dwie nowe:

 

New Image Weighting Algorithms

PixInsight 1.8.8-10 comes with two new image weighting methods:

• A new weighting method based on signal estimation with PSF photometry, available in two variants: PSF Signal and PSF Power. This method is robust and accurate, and is the new default option in the ImageIntegration process. The old noise evaluation weighting method has been deprecated and removed.
   
• An improved version of the SNRWeight method.

Both methods are now tightly integrated in our preprocessing pipeline, including the following processes: ImageCalibration, Debayer, SubframeSelector, ImageIntegration, and DrizzleIntegration. This means that you don't have to do anything to enable them by default, and both work in a completely automated and transparent way without requiring adjustment of additional parameters in most cases. They are fast and have a small impact in terms of computational work.