Stakowanie - przemienność dodawania?

[TUR]

@_Spirit_ robił już test na 100 klatkach. Może wystarczy to ocenić wizualnie ? 

[szuu]

46 minut temu, ZbyT napisał:

Może się okazać, że jakaś część informacji jest tracona podczas konwersji z liczb zmiennoprzecinkowych na całkowite 16-to bitowe i wtedy jakieś drobne różnice mogą być

różnice nie tylko mogą ale muszą być!

(raw 14 bitów) * (100 klatek) =  21 bitów

zapis do pliku => 16 bitów zapisujemy a 5 wyrzucamy

aczkolwiek z tego wyliczenia nie da się wywnioskować czy te różnice są ważne

[kubaman]

Dobra, bo nie chce tego schrzanić

Tu wyniki dla jednego stacka (500 minut, 250 subów)

 

 

A tu to samo rozbite na trzy mniej więcej równe paczki

 

wszystkie ustawienia takie same.

[count.neverest]

Godzinę temu, Krzysztof z Bagien napisał:

Średnia z całości jest taka sama, jak średnia ze średnich cząstkowych, np.:

 

 

 

 

 

 

 

 

[MaciejW]

Liczenie średniej w excelu pośrednio i na raz to tylko wielkie uproszczenie stackowania. Algorytm stackowania jest bardziej skomplikowany, dochodzi normalizacja, dochodzi odrzucanie pixeli, średnia ważona. Nie znam odpowiedzi na pytanie, ale nie ma też co zbytnio upraszczać, najłatwiej sprawdzić. 

Używasz Pixinsight widzę, więc wchodzisz w script -> image analysis  i masz narzędzia do pomiaru SNR i pomiaru szumu. Podejrzewam, że subframeselector też dałby jakąś odpowiedź na temat, który stack ma lepszy SNR. 

Edytowane 5 Kwietnia 2021 przez MaciejW

[ZbyT]

40 minut temu, szuu napisał:

różnice nie tylko mogą ale muszą być!

(raw 14 bitów) * (100 klatek) =  21 bitów

zapis do pliku => 16 bitów zapisujemy a 5 wyrzucamy

aczkolwiek z tego wyliczenia nie da się wywnioskować czy te różnice są ważne

 

suma to nie to samo co średnia, a średnia z liczb 16-to bitowych też jest liczbą 16-to bitową z dokładnością do 1 ADU. Pamiętajmy, że sam szum fotonowy to pierwiastek z liczby fotonów czyli całkiem dużo

suma 1000 klatek da nam liczbę 24 bitową, a na wynikowym stacku dokonamy konwersji do 16 bitów więc wyrzucimy 8 bitów

 

przyjmijmy, że mamy 1600 klatek to wyjdą nam liczby całkowite

jeśli jedna klatka ma SN=X to stack 100 klatek ma SN=10X

stackując 400 klatek otrzymamy SN=20X, a 1600 klatek SN=40X

 

teraz stackujemy ponownie 100 klatek i otrzymujemy SN=10X, a potem stackujemy stacki po 100 klatek o SN=10X

otrzymujemy dla 4x100 SN=20X, a dla 4x4x100 klatek SN=40X czyli dokładnie tyle samo

 

oczywiście cały czas musimy pamiętać o zaokrągleniach, które jednak będą miały niewielki wpływ (choć jakiś będzie) ale statystycznie tyle samo będzie zaokrągleń w górę co w dół więc sumarycznie różnice między oboma sposobami będą niewielkie

 

stackowanie 10 klatek nie jest miarodajne ponieważ aby próbka była istotna statystycznie trzeba aby była liczniejsza niż 33 sztuki

 

pozdrawiam

[kubaman]

15 minut temu, MaciejW napisał:

Używasz Pixinsight widzę, więc wchodzisz w script -> image analysis  i masz narzędzia do pomiaru SNR i pomiaru szumu. Podejrzewam, że subframeselector też dałby jakąś odpowiedź na temat, który stack ma lepszy SNR. 

Dzięki, wyszło tak:

 

stack w 3 substackach

 

i stack od razu

 

nie wiem czy dobrze to odczytuję, ale wyższy SNR jest dla stakowania w krokach..

Edytowane 5 Kwietnia 2021 przez kubaman

[_Spirit_]

Kuba - a nie prościej,  szybciej i wygodniej zrobić to tak jak ostatnio robiliśmy w Siril ale stack wykonać w Pixie?  

[kubaman]

dobra, dobra - to jest inny temat. Teraz chciałbym rozwikłać tę zagadkę

 

[apolkowski]

Był kiedyś podobny wątek.

 

[_Spirit_]

@kubaman Proszę. 

Stack ze 103 klatek bez multi

 

stack 103 klatki z multi (103 stacki)

 

 

jak dla mnie strata czasu. Chyba że ktoś zrobi soft do takiej zabawy.

Edytowane 6 Kwietnia 2021 przez _Spirit_

[OnlyAfc]

Może troszkę ta dyskusja toczy się na wyższym poziomie wiedzy niż obecnie posiadam, ale na jakiej zasadzie działa w takim razie live stacking, np. w Asiair Pro? 

 

W teorii to jest stack dodatkowej klatki do już gotowego stacku, czyli właśnie składanie po kawałku. 

[kubaman]

Romek, nie wiem co tu pokazujesz, czy to strecz, STF czy co, ale widzę gołym okiem, że pierwsze zdjęcie ma większy kontrast.

No i SNR jest taki sam.

[rambro]

34 minuty temu, OnlyAfc napisał:

Może troszkę ta dyskusja toczy się na wyższym poziomie wiedzy niż obecnie posiadam, ale na jakiej zasadzie działa w takim razie live stacking, np. w Asiair Pro? 

 

W teorii to jest stack dodatkowej klatki do już gotowego stacku, czyli właśnie składanie po kawałku. 

Działa na takiej samej zasadzie jak w DSS Live tzn. stackuje średnią. Pamięta poprzednią średnią avg i ilość klatek n. Jak przyjdzie nowa klatka to nowa średnia navg = (avg * n + nowa klatka)/ (n+1). Z medianą, sigma clip itp. tak się nie uda.

[dominiksito]

11 godzin temu, kubaman napisał:

Dzięki, wyszło tak:

 

stack w 3 substackach

 

i stack od razu

 

nie wiem czy dobrze to odczytuję, ale wyższy SNR jest dla stakowania w krokach..

W tej analizie SNR jest podawany w poziomie szumu a nie w stosunek (wiem, to dziwne). Wiec niższy poziom szumu jest na stacku bez dzielenia na grupy

Edytowane 6 Kwietnia 2021 przez dominiksito

[Behlur_Olderys]

No to jak to jest: @_Spirit_ pokazuje, że jest to samo SNR, @kubaman pokazuje raz przewagę singlestacka, a raz multistacka w zależności od interpretacji 

 

BTW:

multistack który prezentuje @_Spirit_ to też jest to samo? Chodzi mi o to, że co innego składać 10x100x1 zamiast 1000x1, a co innego robić magiczną metodą Hamala 1000x1000x1, bo w tej ostatniej metodzie chodziło m.in o wybór klatki referencyjnej, a nie tylko o podział materiału na substacki.

 

Do uzyskania statystycznie miarodajnych wyników - na poziomie, po prawdzie, niemal naukowym - potrzeba więcej danych

10, 20 różnych zdjęć różnych obiektów trzeba by było zmierzyć i przestawić wyniki pomiarów. Najlepiej robionych niezależnie przez kilka osób. Wtedy ewentualny trend powinien być widoczny. 100x1 vs 3x33 wydaje się dość dobrym porównaniem do tego typu testów, bo jest w miarę duża różnica SNR substacków (ok. 6 vs 10), ale pewnie 10x10 też byłoby ciekawe sprawdzić.

 

Dochodzimy tu do momentu, w którym rozstrzygnięcie przestaje być ciekawe, zaczyna być żmudne, czasochłonne i najzwyczajniej nie ma dość danych. Oczywiście, ludzkość kierowana ciekawością budowała rakiety lecące na Księżyc i Wielkie Zderzacze Hadronów... No ale może się okazać, że jednak temat SNR nie jest aż tak doniosły

 

[Iluvatar]

To ja jeszcze dorzucę jedną propozycję. Spróbujcie powtórzyć stackowanie z 3 razy i potem zmienić też klatkę referencyjną lub nazywanie plików. Cokolwiek, żeby zmienić "kolejność" dobieranych plików. Nie powinno to wpłynąć na średnią w żaden sposób, a jak wpłynie, to stacki w mniejszych grupach też mogą się zachowywać inaczej, niż pojedynczy stack.

[Mareg]

53 minuty temu, Behlur_Olderys napisał:

(...)

Dochodzimy tu do momentu, w którym rozstrzygnięcie przestaje być ciekawe, zaczyna być żmudne, czasochłonne i najzwyczajniej nie ma dość danych. Oczywiście, ludzkość kierowana ciekawością budowała rakiety lecące na Księżyc i Wielkie Zderzacze Hadronów... No ale może się okazać, że jednak temat SNR nie jest aż tak doniosły

 

 

Automatycznie wyliczona poprawa SNR dla każdego kanału jest około 30 %. Aby o tyle poprawić SNR przez uśrednianie klatek trzeba mieć ich z 70 % więcej (1.3^2 = 1.69).
Może więc jednak warto to wyjaśnić "pro publico bono"...

 

[Tayson]

@kubaman Plik zapisujesz jako 32bit?

Edytowane 6 Kwietnia 2021 przez Tayson

[lkosz]

Pytanie nie jest o przemienność mnożenia i dodawania, tylko o łączność. Wszystko zależy od implementacji, jeśli algorytm ma zrobione naiwne mnożenie i dodawanie (tzn. bez zadbania o szczegóły*) to uzyskasz inne wyniki. Pisząc wprost:

 

A + (B + C) != (A + B) + C

na komputerze. Matematycznie jest to oczywiście spełnione dla wszystkich typów liczb. Na komputerze dla żadnych - działa to tylko miejscami. Łatwo to sprawdzić, wystarczy w C wybrać trzy liczby zmiennoprzecinkowe, w miejscach gdzie dostępna "ilość" liczb jest nieduża (cecha znacznie podniesiona, mantysa w pobliżu limitu) i zaokrąglenia są bardzo duże. Komputery nie operują na liczbach rzeczywistych, ani nawet nie na pełnych wymiernych, tylko na niewielkim podzbiorze liczb wymiernych (64-bitowym dla typu double), dodatkowo nie są równomiernie rozłożone na osi. Te zbiory nie są ani ciągłe, ani gęste, co powoduje dość bolesne zaokrąglenia, i tu wracamy do gwiazdki:

* - dbanie o szczegóły polega nie tylko na usuwaniu wszelkich zer z mianownika (tzn. nawet gdy dane wejściowe matematycznie nie pozwalają na powstanie zera w mianowniku, ale komputer jednak podzieli przez zero, ze względu na wyżej opisane nierówności rozkładu liczb), ale też na tym, żeby omijać rafy braku łączności działań. W ekstremalnych przypadkach (dla uzyskania maksymalnej precyzji) należy liczby tablicować i operacje na nich (na ich tablicowych reprezentacjach) wykonywać ręcznie (w sensie nie jako operację dodawania/mnożenia na koprocesorze, tylko pętlą "w słupku"). Mnożenie i dodawanie INTów do 10 działa na klasycznych komputerach raczej niezawodnie, a przecinek to pozycja kropki, więc też INT.

Zatem program jest co najwyżej tak inteligentny i dokładny, jak jego autor. Nigdy bardziej.

 

Tyle teoria. To, na ile powyższe efekty będą zauważalne, to inna sprawa. Masz dwa wyjścia - przeanalizować kod w jaki sposób operacje matematyczne zostały zaimplementowane, albo testować jak czarną skrzynkę. Napis w programie "średnia" lub "suma" nie musi oznaczać średniej arytmetycznej w ścisłym rozumieniu, mogą tam też być po drodze różne kwantyzacje, progowania, odszumiania itd. Wówczas inny zestaw, lub inna kolejność, da inne wyniki.

 

Prościej przetestować jak czarną skrzynkę, tzn. kilka różnych sesji, każdą kilkadziesiąt razy dzielisz na N części i losowo rozrzucasz zdjęcia do tych części, i stackujesz. Możesz też w tym punkcie zrobić kilkanaście przetasowań kolejności tych półstacków, i potem je stackować. W efekcie będziesz mieć kilka sesji (różnych danych) * kilkadziesiąt realizacji algorytmu * kilkanaście przetasowań półstacków. Licząc w każdym przypadku statystyki sygnału uzyskasz wartości z których dopiero można wyciągnąć wnioski. Będzie to trochę "magiczne" myślenie, bo żeby poznać prawdziwy powód, trzeba się wczytać w algorytm, ale da już jakiś pogląd.

 

Na koniec może się okazać, że różnice w sygnale, które na 99% będą, nawet jeśli są ewidentne, to są na poziomach niedostrzegalnych przez ludzkie zmysły, i od tego bym zaczął - czy w ogóle jest się nad czym zastanawiać. A zdaje się że robisz te zdjęcia po to żeby na nie patrzeć, a nie dalej numerycznie analizować, więc najlepiej tak podejść do problemu.

Edytowane 6 Kwietnia 2021 przez lkosz

[_Spirit_]

Tą samą sekwencję -100 stacków - posortowałem w losowej kolejności z inną klatką ref. Wynik identyczny.

 

[Behlur_Olderys]

8 minut temu, _Spirit_ napisał:

Tą samą sekwencję -100 stacków - posortowałem w losowej kolejności z inną klatką ref. Wynik identyczny.

pokaż to Hamalowi

Przypominam, że oryginalne pytanie to:

stack 1x1000x1 czy 10x100x1

A więc czy coś tracimy robiąc stack mniejszych stacków zamiast jednego dużego stacka

[_Spirit_]

10 minut temu, Behlur_Olderys napisał:

10x100x1

Paczki 5x 20 stacków - żadnej różnicy.

 

[Behlur_Olderys]

3 minuty temu, _Spirit_ napisał:

Paczki 5x 20 stacków - żadnej różnicy.

 

 

S/N jednak wychodzi 1.85, a w tych poprzednich było 1.57

To dosyć spora różnica!

[_Spirit_]

1 minutę temu, Behlur_Olderys napisał:

S/N jednak wychodzi 1.85, a w tych poprzednich było 1.57

To nie jest ten sam obszar zaznaczony