Skocz do zawartości

Jedna klatka vs stack


diver

Rekomendowane odpowiedzi

2 godziny temu, Tomek96 napisał:

U mnie występuje ten problem, że mam f/6,5, piksel 4,65um i QE 15-18% dla Ha. Zatem mam bardzo ciemny sprzęt. Miałem zalecenie od Pana Macieja Kapkowskiego, aby dla NGC6888 robić po 1200s, czyli 20 minut. Uznaję wessela za guru w tych sprawach. U mnie decydującym faktem może być podniesienie poziomu sygnału ponad poziom szumów odczytu. Dla KAF-8300 miałbym około 5,4um i sprawność około 50%. Zatem materiał zbierałbym 4,5 raza szybciej - zamiast 20 minut potrzebowałbym niecałych 5-ciu. I tutaj dla KAF-8300 możliwe, że nie ma dużej różnicy między 5, 10, 15 a 20 minut. Dla mojej kamery może to być albo nie być. I z tego powodu były też moje pytania ;) Czy lepiej aby mieć na pojedynczej klatce lepszy sygnał, czy pozwolić metodom stackowania materiału na poprawę jakości zdjęcia (obniżenia poziomu szumów).

 

Dzięki wielkie za odpowiedzi :)

 

Pozdrawiam

Tomek

Moim zdaniem - wg tego, jak rozumiem wzór na SNR - bezwzględnie paliłbym klatki tak długo, jak tylko możliwe, przynajmniej w klasycznym astrofoto. Stackowanie przecież jest tylko protezą, pozwalającą ominąć przynajmniej pierwsze z dwóch ograniczeń:

1. Nie mamy nieskończonej studni potencjału na matrycy

2. Montaż nie jest w stanie prowadzić w punkt dowolnie długo.

 

Jedyne co się liczy, to sygnał. Robimy długie fotki żeby zwiększyć sygnał. Robimy stacki, żeby zwiększyć sygnał. 

  • Lubię 1
Odnośnik do komentarza
Udostępnij na innych stronach

9 godzin temu, Tomek96 napisał:

Wiem, że powyżej 150-200 klatek z mojego doświadczenia zaczyna się etap, że bardzo, bardzo wolno zyskujemy w stackowaniu w stosunku do poświęconego czasu.

słuszna uwaga. Aby zwiększyć S/N 2 razy trzeba zwiększyć ilość klatek (łączny czas naświetlania) aż 4 razy. Jeśli masz tych klatek 10 to z całkiem rozsądnych 40 klatek uzyskasz 2 razy lepszy S/N ale jeśli masz tych klatek 200 to musisz dodać jeszcze 600 następnych aby zwiększyć S/N kolejne 2 razy. To obowiązuje zawsze i w każdym rodzaju astrofotografii. Nie ma znaczenia czy to słaba mgławica czy Księżyc. Obowiązują dokładnie te same prawa. Trzeba zebrać 4 razy więcej fotonów

 

pozdrawiam

  • Lubię 1
Odnośnik do komentarza
Udostępnij na innych stronach

20 minut temu, ZbyT napisał:

słuszna uwaga. Aby zwiększyć S/N 2 razy trzeba zwiększyć ilość klatek (łączny czas naświetlania) aż 4 razy. Jeśli masz tych klatek 10 to z całkiem rozsądnych 40 klatek uzyskasz 2 razy lepszy S/N ale jeśli masz tych klatek 200 to musisz dodać jeszcze 600 następnych aby zwiększyć S/N kolejne 2 razy. To obowiązuje zawsze i w każdym rodzaju astrofotografii. Nie ma znaczenia czy to słaba mgławica czy Księżyc. Obowiązują dokładnie te same prawa. Trzeba zebrać 4 razy więcej fotonów

 

pozdrawiam

I tu nie do końca o to mi chodziło ;) Kiedy jeszcze nie miałem guidingu i robiłem NGC7293 łącznie ponad 10h materiału w klatkach około 60s, to miałem wrażenie, że nic nie zyskałem między 5 a 10h. Obiekt stosunkowo duży a bardzo ciemny, nisko nad horyzontem, plus LP od Warszawy. Powiem, że na 60s zdjęciach miałem taki poziom tła, jak obecnie w 900s w zenicie. Jak zrobiłem raz po roku 900s ponownie tego obiektu, to około 12-krotnie jest wyższy poziom tła, niż w zenicie.

 

Apropo tych krótkich czasów i różnicy między stackiem 300 a 600 klatek. Może tu była jakaś specyficzna cecha algorytmów do stackowania, może po prostu wszystko już ucięło się w szumie i LP. Ale poprawy nie miałem. Jeśli dobrze liczyłem wtedy, to miałem elementy, które chciałem wyciągać około 1-2 ADU powyżej tła na pojedynczej klatce, a szum odczytu liczony z czystej teorii to około 25-30 ADU. Więc widać jak bardzo wyciągałem z tła i miałem wrażenie, że osiągnąłem pewien limit. Może to były moje subiektywne odczucia? ;)

 

Pozdrawiam

Tomek

 

PS. Przykładowa klatka 60s z tamtych czasów... Tylko podciągnięta poziomami. Pięknie były to czasy, gdy człowiek patrzył klatka po klatce przy komputerze jak schodzi z kamerki :)

helix ha-001d60.jpg

Edytowane przez Tomek96
Odnośnik do komentarza
Udostępnij na innych stronach

10 minut temu, Tomek96 napisał:

I tu nie do końca o to mi chodziło ;) Kiedy jeszcze nie miałem guidingu i robiłem NGC7293 łącznie ponad 10h materiału w klatkach około 60s, to miałem wrażenie, że nic nie zyskałem między 5 a 10h. Obiekt stosunkowo duży a bardzo ciemny, nisko nad horyzontem, plus LP od Warszawy. Powiem, że na 60s zdjęciach miałem taki poziom tła, jak obecnie w 900s w zenicie. Jak zrobiłem raz po roku 900s ponownie tego obiektu, to około 12-krotnie jest wyższy poziom tła, niż w zenicie.

dwukrotne wydłużenie czasu ekspozycji pozwoliło zwiększyć S/N tylko 1,41 razy. To nie jest dużo ale zawsze coś. To co było poza zasięgiem zaczynało wyłaniiać się z szumu.

LP powoduje, że potrzeba wydłużyć łączny czas ekspozycji kilka razy w stosunku do miejscówki z małym LP. Belhur kiedyś to przeliczał. Wyszło z tego, że da się osiągnąć to samo przy dużym LP co przy małym ale kosztem wielokrotnego wydłużenia sesji

 

pozdrawiam

Odnośnik do komentarza
Udostępnij na innych stronach

7 godzin temu, Krzychoo226 napisał:

Można to oczywiście policzyć i korzyść będzie po stronie dłuższych klatek (o ile kamera ma niski prąd ciemny!):

SNR = ((Sobj + Sskyfog) * Csubs)/SQRT(Csubs * (Sobj + Sskyfog + Sdarkcurrent + Nread^2))

Kombinuję, kombinuję i nie mogę się doliczyć. Dlaczego dla zerowych szumów nie otrzymujemy nieskończoności?

Wzorów jak obliczyć analitycznie SNR nie znam...

Ale na podstawie znanego obrazu możemy obliczyć w ten sposób:

SNR = WartośćŚrednia / OdchylenieStandardowe, gdzie odchylenie standardowe możemy obliczyć w sposób następujący:

OdchylenieStandardowe = SQRT((Suma po każdej próbie, gdzie sumujemy kwadrat różnicy wartości próby i wartości średniej)/(n-1)).

Niech ktoś mnie poprawi, jeśli się mylę. Pytanie w szczególności do @Behlur_Olderys po próbuję w excelu zasymulować Twoją wypowiedź z sąsiedniego wątku i nie jestem w stanie dojść do Twoich wyników. Po prostu nie mogę... Biorę sobie sygnał 800, dokładam losowy szum +- 5 i mi wychodzi SNR około 252,4 dla n=10000 losowych prób. Biorę sygnał 400 i szum losowy +- 5 i mi wychodzi SNR na poziomie około 126,3 (moją metodą).
Dla 8 elektronów i +- 5 wychodzi mi 2,54 SNR. Dla 4 elektronów zaledwie 1,25. To są obliczenia empiryczne i liczymy oczekiwany SNR dla jednego piksela.

Chodzi mi o tego posta:

 

Proszę, pokażcie mój błąd w rozumowaniu. Bo nie jestem w stanie go znaleźć :/

 

Pozdrawiam

Tomek

 

 

Odnośnik do komentarza
Udostępnij na innych stronach

4 minuty temu, Tomek96 napisał:

Kombinuję, kombinuję i nie mogę się doliczyć. Dlaczego dla zerowych szumów nie otrzymujemy nieskończoności?

Wzorów jak obliczyć analitycznie SNR nie znam...

Ale na podstawie znanego obrazu możemy obliczyć w ten sposób:

SNR = WartośćŚrednia / OdchylenieStandardowe, gdzie odchylenie standardowe możemy obliczyć w sposób następujący:

OdchylenieStandardowe = SQRT((Suma po każdej próbie, gdzie sumujemy kwadrat różnicy wartości próby i wartości średniej)/(n-1)).

Niech ktoś mnie poprawi, jeśli się mylę. Pytanie w szczególności do @Behlur_Olderys po próbuję w excelu zasymulować Twoją wypowiedź z sąsiedniego wątku i nie jestem w stanie dojść do Twoich wyników. Po prostu nie mogę... Biorę sobie sygnał 800, dokładam losowy szum +- 5 i mi wychodzi SNR około 252,4 dla n=10000 losowych prób. Biorę sygnał 400 i szum losowy +- 5 i mi wychodzi SNR na poziomie około 126,3 (moją metodą).
Dla 8 elektronów i +- 5 wychodzi mi 2,54 SNR. Dla 4 elektronów zaledwie 1,25. To są obliczenia empiryczne i liczymy oczekiwany SNR dla jednego piksela.

Chodzi mi o tego posta:

 

Proszę, pokażcie mój błąd w rozumowaniu. Bo nie jestem w stanie go znaleźć :/

 

Pozdrawiam

Tomek

 

 

Sygnał na poziomie 800e będzie obarczony "na dzień dobry" szumem fotonowym na poziomie sqrt(800) =~28e. Może to o tym zapomniałeś? ;)

Odnośnik do komentarza
Udostępnij na innych stronach

1 godzinę temu, Behlur_Olderys napisał:

Sygnał na poziomie 800e będzie obarczony "na dzień dobry" szumem fotonowym na poziomie sqrt(800) =~28e. Może to o tym zapomniałeś? ;)

@Behlur_OlderysNa dzisiaj ostatnie pytanie. Czy możemy założyć, że szum fotonowy (śrutowy?) i szum odczytu mają rozkład normalny, gdzie za odchylenie standardowe uznajemy podawaną wartość szumu? Tak jak ty podawałeś np. 1,75e dla ASI1600 dzisiaj?

I drugie pytanie - jak ma się do tego prąd ciemny? Jeśli jest on generowany losowo też z rozkładu normalnego? Jak mamy np. 0,012e/pix/sec to w ciągu 60s będzie on wynosił 0,72e/pix. I od tej wartości dopiero liczymy szum dla prądu ciemnego, czy jego całego uznajemy za szum?

 

Czy sumę tych szumów możemy traktować jak funkcję sumy dwóch zmiennych losowych niezależnych o rozkładach normalnych?

Postaram się od swojej strony sprawdzić Twoje wyliczenia ;) Coś nie wierzę, że takie a nie inne są różnice miedzy f/2.2 i f/10 (wyliczenia Behlura w drugim temacie).

 

Mam ponadto dylemat, że tematy SNR, jak on się zmienia wraz z stackiem etc., czy lepiej jedną dłuższą klatkę czy stacka to niby są związane z tematem "Jedna klatka vs stack", a z drugiej strony jest to dość mocno związane z wątkiem "Dyskusje o szumie, sygnale i SNR" Mateusza. Jeśli moderator uzna te moje rozważania za zbyt duży off-topic od tego tematu, to proszę o przeniesienie tej dyskusji lub wydzielenie tematu. Ja tego nie zrobiłem, ponieważ uznaję to za bezcelowe - póki co ta dyskusja jest zbyt mocno związana zarówno z tym wątkiem, jak i tym co pojawiło się w sąsiednim. Przepraszam diver, za zaśmiecanie tego tematu, ale mam nadzieję, że nasza dyskusja jest "wartościowa" :)

 

Pozdrawiam

Tomek

  • Lubię 1
Odnośnik do komentarza
Udostępnij na innych stronach

2 godziny temu, Tomek96 napisał:

Przepraszam diver, za zaśmiecanie tego tematu, ale mam nadzieję, że nasza dyskusja jest "wartościowa" :)

Niczego nie zaśmiecasz Tomek. To przecież cały czas dyskusja na "mój" temat. A Twoje rozważania dokładnie tego dotyczą. Jak również poniższe podsumowanie Bartka - jest to pewien logiczny werdykt w temacie "Jedna klatka vs stack".

 

8 godzin temu, Behlur_Olderys napisał:

Moim zdaniem - wg tego, jak rozumiem wzór na SNR - bezwzględnie paliłbym klatki tak długo, jak tylko możliwe, przynajmniej w klasycznym astrofoto. Stackowanie przecież jest tylko protezą, pozwalającą ominąć przynajmniej pierwsze z dwóch ograniczeń:

1. Nie mamy nieskończonej studni potencjału na matrycy

2. Montaż nie jest w stanie prowadzić w punkt dowolnie długo.

 

Jedyne co się liczy, to sygnał. Robimy długie fotki żeby zwiększyć sygnał. Robimy stacki, żeby zwiększyć sygnał. 

Choć przyznaję, że nadal nie rozumiem, w jaki sposób taki np. DSS zwiększa sygnał podczas stackowania. To, że stara się podnieść SNR jest dla mnie jasne. W ten sposób uzyskamy wizualnie (względnie) większą jasność obiektu light. Ale nie zwiększymy przecież bezwzględnej jasności tego obiektu. Ja nie widzę (przynajmniej w DSS) opcji "sumuj sygnał z klatek light".

"Robimy długie fotki żeby zwiększyć sygnał" - to dla mnie jasne i oczywiste. W terminologii klasycznej fotografii "zwiększamy ekspozycję", co pozwoli nam wydobyć więcej słabo świecących szczegółów. Ale co to w końcu Bartek znaczy "Robimy stacki, żeby zwiększyć sygnał"? :g:

Odnośnik do komentarza
Udostępnij na innych stronach

5 godzin temu, diver napisał:

Niczego nie zaśmiecasz Tomek. To przecież cały czas dyskusja na "mój" temat. A Twoje rozważania dokładnie tego dotyczą. Jak również poniższe podsumowanie Bartka - jest to pewien logiczny werdykt w temacie "Jedna klatka vs stack".

 

Choć przyznaję, że nadal nie rozumiem, w jaki sposób taki np. DSS zwiększa sygnał podczas stackowania. To, że stara się podnieść SNR jest dla mnie jasne. W ten sposób uzyskamy wizualnie (względnie) większą jasność obiektu light. Ale nie zwiększymy przecież bezwzględnej jasności tego obiektu. Ja nie widzę (przynajmniej w DSS) opcji "sumuj sygnał z klatek light".

"Robimy długie fotki żeby zwiększyć sygnał" - to dla mnie jasne i oczywiste. W terminologii klasycznej fotografii "zwiększamy ekspozycję", co pozwoli nam wydobyć więcej słabo świecących szczegółów. Ale co to w końcu Bartek znaczy "Robimy stacki, żeby zwiększyć sygnał"? :g:

Może dlatego że na końcu stackowania wynik jest uśredniany? ;)

W końcu wyniki musi się zmieścić na tych 16 bitach czy iluś.

Algorytm stackowania to nie suma, ale średnia, albo mediana. (Albo wariacje na ten temat).

@Pav1007 już wspominał coś o tym.

 

Jeśli dodasz do siebie 1000 zdjęć o głębi 14b to wynikowa głębia (14 + log_2(1000) =~ 24b).

DSS dodaje zdjęcia i tworzy tymczasowo plik o głębi 32b, gdzie to się wszystko zmieści, a potem dzieli wynikowe wartości pikseli przez jakąś liczbę. To dzielenie nie powinno wiele zmienić w kategoriach SNR, a efekt ma taką samą głebię koloru, jak oryginalne suby. Dzięki temu można je sensownie obrabiać na komputerze. Ale może ktoś wie coś lepiej w tym temacie? Przyznam, że dla mnie mogłaby zostać "goła" suma, w dobie GIMPa 32b? :)

 

 

Odnośnik do komentarza
Udostępnij na innych stronach

21 godzin temu, diver napisał:

Choć przyznaję, że nadal nie rozumiem, w jaki sposób taki np. DSS zwiększa sygnał podczas stackowania. To, że stara się podnieść SNR jest dla mnie jasne. W ten sposób uzyskamy wizualnie (względnie) większą jasność obiektu light. Ale nie zwiększymy przecież bezwzględnej jasności tego obiektu. Ja nie widzę (przynajmniej w DSS) opcji "sumuj sygnał z klatek light".

jest opcja "sumuj sygnał z klatek light" w DSS. W Stacking Parameters w zakładce light jeśli zaznaczysz Average to właśnie będziesz sumował klatki light

choć zwykle mówimy o uśrednianiu to w rzeczywistości DSS dodaje do siebie pewne obrobione statystycznie wartości pikseli czyli na koniec nie dzieli przez ilość klatek jak to jest liczone dla średniej. Działa to podobnie jak wydłużenie ekspozycji, gdzie mamy sprzętowe sumowanie fotonów. Tylko, że podczas stackowania nie musimy stosować prostego sumowania ale bardziej zaawansowaną obróbkę statystyczną, która pozwoli wyeliminować gorące piksele, przelatujące satelity itd. Skuteczność tej obróbki oczywiście zależy od ilości klatek. Trzeba ich jednak sporo (statystyka matematyczna mówi o przynajmniej 33 próbkach) by ta obróbka była efektywna. Granica nie jest tu sztywna ale trzeba się liczyć z tym, że klatek powinno być dużo, a w końcowym rozrachunku i tak najważniejszy jest łączny czas ekspozycji

 

pozdrawiam

  • Lubię 2
Odnośnik do komentarza
Udostępnij na innych stronach

W dniu 15.03.2019 o 23:49, ZbyT napisał:

jest opcja "sumuj sygnał z klatek light" w DSS. W Stacking Parameters w zakładce light jeśli zaznaczysz Average to właśnie będziesz sumował klatki light 

Ponieważ utknąłem w "szumie informacyjnym" nie pozostało mi więc nic innego, jak poczytać po prostu tutoriala do DSS. W końcu autor wie chyba najlepiej, jak działa jego program.

Pozwolę sobie zacytować dwa fragmenty z tego tutoriala w interesującej nas materii i krótko je podsumować.

 

Cyt. 1.

---

Why combine?
The answer is simple: only to increase the Signal to Noise Ratio (SNR).
Is the resulting image more luminous? No.
Is the resulting image more colorful? No.
The goal of combing many images into one is only to increase the SNR. The resulting images are neither more luminous or more colorful but they contain much less noise which will let you stretch the histogram a lot more which will give you more freedom to bring back colors and details.

---

Po co zestawiać wiele klatek? Tylko po to, żeby polepszyć na obrazie wynikowym SNR.
Czy obraz wynikowy jest jaśniejszy? Nie.

 

Cyt. 2.

---

How many frames?
The more, the better but above some threshold it is less efficient.
The signal to noise ration in increasing with the square root of the number of combined frames regardless of the exposure time of each frame.
This is true with all the combining methods (average, median, kappa-sigma clipping, auto-adaptive weighted average, ...) except entropy weighted average since this one in using the entropy to weight each pixel and thus is increasing the noise that is a big entropy contributor..
This means that if your base SNR is 1, when you combine 10 images the SNR increases by 3.16 (square root of 10). For 30 images it is 5.47, for 50 images it is 7.07, for 100 images it is 10, for 300 images it is 17.32.
As you can see to gain a 7 ratio 50 frames are needed between 1 and 50, but 200 frames are needed above 100.
Are 100 x 1 minute and 10x10 minutes giving the same result?
Yes when considering the SNR but definitely. No when considering the final result.
The difference between a 10 minutes exposure and a 1 minute exposure is that the SNR in the 10 minutes exposure is 3.16 higher than in 1 minute exposure.
Thus you will get the same SNR if you combine 10 light frames of 10 minutes or 100 light frames of 1 minute. However you will probably not have the same signal (the interesting part). Simply put you will only get a signal if your exposure is long enough to catch some photons on most of the light frames so that the signal is not considered as noise.
For example for a very faint nebula you might get a few photons every 10 minutes. If you are using 10 minutes exposures, you will have captured photons on each of your light frames and when combined the signal will be strong.
If you are using 1 minute exposures you will capture photons only for some of your light frames and when combined the photons will be considered as noise since they are not in most of the light frames.

---

Ile klatek? Im więcej tym lepiej. Ale wartość SNR rośnie w tempie funkcji pierwiastkowej, więc im więcej klatek tym tempo przyrostu SNR jest mniejsze. Więc jednocześnie im więcej klatek, tym wydajność metody jest mniejsza.
Dla pojedynczej klatki SNR jest tym większy, im dłuższa ekspozycja. Podczas stakowania liczy się zaś łączny czas ekspozycji wszystkich klatek.
Czy więc 100 klatek po 1 minucie dla taki sam efekt jak 10 klatek po 10 minut?
Jeżeli rozważamy SNR matematycznie - tak. Nie musi to jednak oznaczać, że obraz finalny będzie taki sam. Trzeba zawsze pamiętać, żeby czas ekspozycji zapewnił nam wystarczającą jasność wybranego obiektu już na pojedynczej klatce. Jeżeli bowiem jasność jego obrazu będzie za mała, i tak zginie on w szumie tła podczas stakowania. Gdyż może zostać potraktowany przez algorytm stakujący po prostu jako szum.

 

Zaś metoda "Average" to prosta średnia matematyczna, a nie suma sygnału z klatek light.

Lektura tutoriala DSS potwierdzona moimi próbami stakowania różnymi metodami zdecydowanie na to wskazuje.

Wniosek ostateczny: stakowanie służy tylko i wyłącznie do zwiększenia SNR. "Teoria wiaderek" Pawła jest więc dla mnie tyleż niezrozumiała, co nie znajdująca potwierdzenia w samej idei stakowania (tutorial DSS)  jak i w moich doświadczeniach (nielicznych jeszcze, ale na temat).

 

Jeżeli jestem w błędzie, wyprostujcie mnie proszę. :flirt:

 

Edytowane przez diver
Odnośnik do komentarza
Udostępnij na innych stronach

Czy na bazie tego co napisano tutaj wcześniej można zatem zaryzykować wniosek, że jeśli mamy dylemat "100x1 vs 10x10" to: im obiekt ciemniejszy i zawierający subtelniejsze struktury tym bardziej powinniśmy skłaniać się w kierunku 10x10, a im jaśniejszy (lepiej kontrastujący z tłem) tym bardziej należałoby zbliżać się do "100x1"? 

Upraszczając oczywiście. Chodzi o zasadę.

Edytowane przez etomee
Odnośnik do komentarza
Udostępnij na innych stronach

albo tutorial do DSS mija się momentami z prawdą albo rzeczywiście DSS działa inaczej niż inne programy stackujące. To mogłoby tłumaczyć dlaczego stacki z DSS są gorszej jakości. Pamiętam jeszcze dawne czasy gdy nie było DSS, a do stackowania używałem Irisa., który bez najmniejszej wątpliwości sumował wartości pikseli, a tym samym wykonywał oversampling zwiększając rozdzielczość bitową finalnego zdjęcia. To samo robią programy stackujące aviki w fotografii planetarnej. Złożenie tysięcy 8-o bitowych klatek pozwala zwiększyć rozdzielczość bitową gotowego stacka. Gdyby tylko uśredniały sygnał nie udałoby się przeskoczyć S/N ograniczonego rozpiętością sygnału ograniczonego do wartości z przedziału 0-255

 

raczej skłaniam się do błędów w tutorialu. Wynika z nich, że program osobno traktuje sygnał, a osobno szum. Tak niestety się nie da ponieważ oba te sygnały są ze sobą splecione, a dekonwolucja tylko częściowo radzi sobie z rozdzieleniem sygnału od szumu. Poza tym DSS musiałby wykonywać dekonwolucję zawsze podczas stackowania, a nie zauważyłem by dawał taką możliwość. Ponadto gdyby rzeczywiście dobrze sobie radził z dekonwolucją to stackowanie już nie byłoby potrzebne

 

pozdrawiam

Edytowane przez ZbyT
Odnośnik do komentarza
Udostępnij na innych stronach

47 minut temu, etomee napisał:

Czy na bazie tego co napisano tutaj wcześniej można zatem zaryzykować wniosek, że jeśli mamy dylemat "100x1 vs 10x10" to: im obiekt ciemniejszy i zawierający subtelniejsze struktury tym bardziej powinniśmy skłaniać się w kierunku 10x10, a im jaśniejszy (lepiej kontrastujący z tłem) tym bardziej należałoby zbliżać się do "100x1"? 

Upraszczając oczywiście. Chodzi o zasadę.

Ja tak to zrozumiałem. Ale jeżeli obiekt ciemny, to należy skłaniać się raczej w kierunku 100x10 niż 10x10. :emotion-5:

Odnośnik do komentarza
Udostępnij na innych stronach

13 minut temu, ZbyT napisał:

albo tutorial do DSS mija się momentami z prawdą albo rzeczywiście DSS działa inaczej niż inne programy stackujące. To mogłoby tłumaczyć dlaczego stacki z DSS są gorszej jakości.

ZbyT, na razie eksperymentuję z DSS. Wyniki moich prób i testów potwierdzają to, co wyczytałem w cytowanym tutorialu.

Ale może inne programy stakujące działają inaczej... :g:

Odnośnik do komentarza
Udostępnij na innych stronach

23 minuty temu, ZbyT napisał:

albo tutorial do DSS mija się momentami z prawdą albo rzeczywiście DSS działa inaczej niż inne programy stackujące. To mogłoby tłumaczyć dlaczego stacki z DSS są gorszej jakości. Pamiętam jeszcze dawne czasy gdy nie było DSS, a do stackowania używałem Irisa., który bez najmniejszej wątpliwości sumował wartości pikseli, a tym samym wykonywał oversampling zwiększając rozdzielczość bitową finalnego zdjęcia. To samo robią programy stackujące aviki w fotografii planetarnej. Złożenie tysięcy 8-o bitowych klatek pozwala zwiększyć rozdzielczość bitową gotowego stacka. Gdyby tylko uśredniały sygnał nie udałoby się przeskoczyć S/N ograniczonego rozpiętością sygnału ograniczonego do wartości z przedziału 0-255

 

Dodajemy sygnał z wszystkich klatek. A następnie dzielimy przez liczbę klatek. Czyli po kolei najpierw suma, a potem dzielenie, co razem daje średnią.

 

Wydaje mi się, że wszyscy mają rację. Domyślam się, że w planetarnym astrofoto zwykła średnia nie zda egzaminu ale tutaj? Czemu nie? Ostatecznie dysponując 14b, 16b subami nie ma po co zwiększać nie wiadomo jak głębi kolorów. Wystarczy przesunąć szum w dół ;)

 

Jeśli oryginalny obraz ma np. sygnał 10000, to szum będzie na poziomie 100. (SNR=100)

Po dodaniu 100 takich obrazów sygnał będzie na poziomie 1000000 a szum* - 1000. SNR =1000

 

*bo sygnał się dodaje normalnie a szum - jak pierwiastek) to istota stackowania.

 

Dzielimy całość przez 100 (czyli wynik to średnia arytmetyczna)  i mamy znów:

Sygnał 10000 ale już szum - 10. SNR = dalej 1000.

No to chyba rezultat jest taki, jaki miał być - zwiększenie SNR? Suma, czy średnia - nie widzę różnicy.

Edytowane przez Behlur_Olderys
  • Lubię 1
Odnośnik do komentarza
Udostępnij na innych stronach

22 minuty temu, ZbyT napisał:

albo tutorial do DSS mija się momentami z prawdą albo rzeczywiście DSS działa inaczej niż inne programy stackujące. To mogłoby tłumaczyć dlaczego stacki z DSS są gorszej jakości. Pamiętam jeszcze dawne czasy gdy nie było DSS, a do stackowania używałem Irisa., który bez najmniejszej wątpliwości sumował wartości pikseli, a tym samym wykonywał oversampling zwiększając rozdzielczość bitową finalnego zdjęcia. To samo robią programy stackujące aviki w fotografii planetarnej. Złożenie tysięcy 8-o bitowych klatek pozwala zwiększyć rozdzielczość bitową gotowego stacka. Gdyby tylko uśredniały sygnał nie udałoby się przeskoczyć S/N ograniczonego rozpiętością sygnału ograniczonego do wartości z przedziału 0-255

Wydaje mi się, że różnica pomiędzy sumą, a średnią w programach stackujących sprowadza się jedynie do końcowej prezentacji wyniku. Ja przynajmniej tak bym do tego podszedł. Wszystko sumujemy w 32 bitowych liczbach całkowitych i dzielimy na końcu całkowito-liczbowo na potrzeby średniej. Dzięki temu procesor może hulać nie tracąc czasu na operacje zmiennoprzecinkowe.

Odnośnik do komentarza
Udostępnij na innych stronach

16 minut temu, Krzychoo226 napisał:

Wydaje mi się, że różnica pomiędzy sumą, a średnią w programach stackujących sprowadza się jedynie do końcowej prezentacji wyniku. Ja przynajmniej tak bym do tego podszedł. Wszystko sumujemy w 32 bitowych liczbach całkowitych i dzielimy na końcu całkowito-liczbowo na potrzeby średniej. Dzięki temu procesor może hulać nie tracąc czasu na operacje zmiennoprzecinkowe.

właśnie po to zwiększa się rozpiętość bitową by operacje zmiennoprzecinkowe nie były potrzebne. Poza tym średnia nie musi być liczną całkowitą, a wtedy po konwersji do liczb całkowitych tracimy bezpowrotnie informację, która przy sumowaniu nam nie ucieknie. Z pozoru wydaje się, że podzielenie liczby będącej sumą (czyli policzenie średniej) przez 100 czy pomnożenie niczego nie zmienia ale jeśli to będzie liczba 57 to już intuicyjnie widać, że różnica jednak będzie

 

jeśli stackujemy obrazy 16 bitowe to straty nie są takie straszne ale jeśli dysponujemy matrycą 12 bitową to zaczyna się z tego robić tragedia. Utrata informacji będzie ogromna i całe to stackowanie traci sens

 

pozdrawiam

Edytowane przez ZbyT
Odnośnik do komentarza
Udostępnij na innych stronach

W dniu 18.03.2019 o 00:55, Behlur_Olderys napisał:

*bo sygnał się dodaje normalnie a szum - jak pierwiastek) to istota stackowania.

 

Dzielimy całość przez 100 (czyli wynik to średnia arytmetyczna)  i mamy znów:

Sygnał 10000 ale już szum - 10. SNR = dalej 1000.

No to chyba rezultat jest taki, jaki miał być - zwiększenie SNR? Suma, czy średnia - nie widzę różnicy.

Bartek, Twoja definicja istoty stackowania - ok. Algorytm stara się wycinać to co uzna za szum w postępie funkcji log2/x. To raczej pewne.

To że zsumowany sygnał light jest potem sprowadzany do "średniej" to też raczej pewne. Są jednak różne "średnie". Co innego średnia arytmetyczna, a co innego np. mediana. Po wielu próbach stackowania tego samego materiału widzę, że przy słabszej i różnej jakości materiału (czyli słaby SNR w klatkach składowych), średnia arytmetyczna jest zabójcza. Mediana przynosi wtedy znacznie lepsze rezultaty w obrazie tła wynikowej klatki. Przy dobrej i równej jakości klatek składowych nie widziałem istotnej różnicy w zastosowaniu metody uśredniania jednej czy drugiej.

No i jest też w końcu dla mnie pewne, że program stackujący nie sumuje sygnału light (nie podnosi jego jasności), obniżając jednocześnie poziom szumu. Tak jak napisałeś, program wylicza taką czy inną średnią z klatek light usiłując jednocześnie wygasić szum w postępie funkcji log2/x. Takie wyjaśnienie to oczywiście wniosek rodzaju jak działa zegarek bez otwierania jego koperty. Nie znam przecież algorytmu obliczeniowego programu (DSS), a wnioski mogę jedynie wyciągać z instrukcji jego obsługi w połączeniu z efektami jego stosowania. Co kolejny raz pokażę na poniższych fotkach.

 

Jeszcze raz pojedyncza klatka z zestawu. Po 8 minutach ekspozycji obiekt widoczny dość wyraźnie, jednak ginie w szumie tła. I nie da się w obróbce graficznej tego poprawić.

M101_20190311_03149.jpg.ffc9b9c4cab506a43dafe45b43e70821.jpg

 

A tutaj klatka jeszcze mocniejszego stacka, niż poprzednio. Zebrane 128 minut w 20 klatkach różnej jakości. Główny obiekt nie jest jaśniejszy niż ten na pojedynczej klatce, ale jakość obrazu w sensie wyodrębnienia słabych świateł obiektu z tła jest radykalnie lepsza.

M101.jpg.e40536cc02061f97beac8373e044aedd.jpg

 

 

Edytowane przez diver
Odnośnik do komentarza
Udostępnij na innych stronach

13 godzin temu, diver napisał:

Bartek, Twoja definicja istoty stackowania - ok. Algorytm stara się wycinać to co uzna za szum w postępie funkcji log2/x. To raczej pewne.

To że zsumowany sygnał light jest potem sprowadzany do "średniej" to też raczej pewne. Są jednak różne "średnie". Co innego średnia arytmetyczna, a co innego np. mediana. Po wielu próbach stackowania tego samego materiału widzę, że przy słabszej i różnej jakości materiału (czyli słaby SNR w klatkach składowych), średnia arytmetyczna jest zabójcza. Mediana przynosi wtedy znacznie lepsze rezultaty w obrazie tła wynikowej klatki. Przy dobrej i równej jakości klatek składowych nie widziałem istotnej różnicy w zastosowaniu metody uśredniania jednej czy drugiej.

No i jest też w końcu dla mnie pewne, że program stackujący nie sumuje sygnału light (nie podnosi jego jasności), obniżając jednocześnie poziom szumu. Tak jak napisałeś, program wylicza taką czy inną średnią z klatek light usiłując jednocześnie wygasić szum w postępie funkcji log2/x. Takie wyjaśnienie to oczywiście wniosek rodzaju jak działa zegarek bez otwierania jego koperty. Nie znam przecież algorytmu obliczeniowego programu (DSS), a wnioski mogę jedynie wyciągać z instrukcji jego obsługi w połączeniu z efektami jego stosowania. Co kolejny raz pokażę na poniższych fotkach.

 

Jeszcze raz pojedyncza klatka z zestawu. Po 8 minutach ekspozycji obiekt widoczny dość wyraźnie, jednak ginie w szumie tła. I nie da się w obróbce graficznej tego poprawić.

M101_20190311_03149.jpg.ffc9b9c4cab506a43dafe45b43e70821.jpg

 

A tutaj klatka jeszcze mocniejszego stacka, niż poprzednio. Zebrane 128 minut w 20 klatkach różnej jakości. Główny obiekt nie jest jaśniejszy niż ten na pojedynczej klatce, ale jakość obrazu w sensie wyodrębnienia słabych świateł obiektu z tła jest radykalnie lepsza.

M101.jpg.e40536cc02061f97beac8373e044aedd.jpg

 

 

1. Uśrednianie "zwykłe" average wobec mediany ma taki problem, że zawsze bierze pod uwagę cały sygnał. Mediana (z definicji) wybiera jakby najlepsze piksele z wszystkich zdjęć, pomijając praktycznie wszystkie inne. Ogólnie to temat na niejedną pracę naukową, i w zasadzie z tego co czytam u większości osób mediana daje najlepsze rezultaty przy małej ilości zdjęć w stacku. Ja osobiście preferowałbym average z odcinaniem najgorszych próbek czyli sigma-kappa clipping. Pamiętaj, że average da ci nową jakość, stworzy piksel, którego nie było na żadnym zdjęciu, być może lepszy od wszystkich możliwych  a tymczasem mediana tylko wybierze jeden z istniejących. To wydaje się przewagą algorytmów opartych na średniej. Minusem jest to, że jeśli masz nierówne jakościowo fotki w stacku to średnia małej ilości zdjęć uwypukli błędy prowadzenia itp. SigmaKappa już nie, dlatego ją ogólnie polecam ;)

 

2. Nie wiem, skąd wziąłeś log2/x ? SNR rośnie jak sqrt(N), a głębia bitów rośnie jak log4(N) (gdyby to był prawdziwy oversampling, ale nie wiem, co DSS naprawdę robi).

 

3. Jeszcze raz powtarzam: to, że coś widać "na oko" to nie znaczy, że działa tak, czy inaczej. Jakość zdjęć, żeby można je porównać obiektywnie, trzeba *mierzyć*. SNR można od biedy zmierzyć porównując średnią wartość piksela w jakimś  jednolitym obszarze do odchylenia standardowego. Wtedy można porównywać między różnymi wynikami stackowania. To powinno dać się zrobić w PS, albo w jakimś Matlabie ;)

 

4. Sumowanie i średnia - nie ma specjalnej różnicy. Suma to a+b, średnia to (a+b)/2. Później i tak rozciągasz histogram suwakami ;) 

 

Jak zrobisz jedno zdjęcie 1x1min to sygnał będzie np. 100. Szum fotonowy to *zawsze* pierwiastek z tego, więc 10.

SNR = 100/10 =10

 

Zrobisz 1x4minuty - sygnał będzie 400. Szum od tego sqrt(400) = 20.

SNR = 400/20 = 20.

 

A jak zamiast naświetlania będziesz stackował 4x1min:

 

100+100+100+100=400

Sqrt (400) = 20 

400/4 = 100

20/4 = 5

SNR = 100/5 = 20 tak samo jak 1x4 min.

 

Tylko jak zdjęcia są "pojechanie" to taka matematyka niestety nic Ci nie da :)

 

podobnie, jeśli oprócz szumu fotonowego masz jeszcze dużo szumu odczytu czy innego syfu.... ;)

 

Pozdrawiam.

 

 

 

 

 

  • Lubię 1
Odnośnik do komentarza
Udostępnij na innych stronach

W dniu 23.03.2019 o 16:31, Behlur_Olderys napisał:

2. Nie wiem, skąd wziąłeś log2/x ? SNR rośnie jak sqrt(N)

Upss... log2/x to rzeczywiście nieco inna funkcja niż sqrt(x). :ermm:

 

Jeżeli już Bartek napieramy na matematykę, spróbujmy jeszcze bardziej elementarnie.
Zróbmy praktyczne obliczeniowo założenie, że podczas 1 minuty ekspozycji zbierzemy 1 jednostkę sygnału. Teraz powtórzę za Tobą jak "papuga", ale trochę inaczej.

 

Jak zrobisz jedno zdjęcie 1x1min to sygnał będzie np. 1. Szum fotonowy to *zawsze* pierwiastek z tego, więc 1.
Suma sygnału SS: 1 * 1 = 1
Szum od sumy sygnału: sqrt(1) = 1
Średnia sumy sygnału: 1/1 = 1
Średnia szumu od sumy sygnału: 1/1 = 1
SNR wynikowy: 1/1 = 1

 

Ciekawa matematyka... Co z tego w praktyce powinno wyniknąć? Że obiekt utonie w szumie?... :g:

Jedźmy jednak dalej.

 

Teraz 4 klatki po 1 minucie.
Suma sygnału SS: 4 * 1 = 4
Szum od sumy sygnału: sqrt(4) = 2
Średnia sumy sygnału: 4/4 = 1
Średnia szumu od sumy sygnału: 2/4 = 0,5
SNR wynikowy: 1/0,5 = 2

 

Teraz 1 klatka 4 minuty.
Suma sygnału SS: 1 * 4 = 4
Szum od sumy sygnału: sqrt(4) = 2
Średnia sumy sygnału: 4/1 = 4
Średnia szumu od sumy sygnału: 2/1 = 2
SNR wynikowy: 4/2 = 2

 

Wszystko się więc w ujęciu matematycznym zgadza. To znaczy przy przyjęciu zasady że finalny SNR liczymy jako avr(suma sygnału) / avr(sqrt(suma sygnału)), SNR dla jednej klatki z taką samym sygnałem jak dla n klatek matematycznie będzie taki sam.

 

Spróbujmy teraz sprowadzić to do praktyki. Dla uproszczenia obliczeń zakładamy nadal, że 1 minuta ekspozycji to 1 jednostka sygnału.
Powiedzmy, że zadowalający nas sygnał (jasność obiektu) uzyskamy już po 1 minucie ekspozycji.
Jeżeli więc zrobimy jedną klatkę 4 minuty to finalnie po uśrednieniu mamy więcej sygnału (4), a SNR po stackowaniu tej klatki wyniesie 2.
Jeżeli zrobimy 4 klatki po 1 minucie to na stacku będziemy mieli uśredniony sygnał jedynie zadowalający (1), a SNR też wyniesie 2.
Wydaje się więc że jedna 4-minutowa klata w sensie matematycznym powinna dać lepszy wynik, bo mamy na niej 4 razy więcej sygnału a SNR taki sam jak przy stacku 4x1.

Dlaczego więc nie zadowalamy się jedną klatką z dłuższym czasem ekspozycji poddaną procesowi stackowania (dodane darki, flaty i biasy)?
Czy program do stackowania liczy jedną klatkę według innych zasad? Nie tych, które zostały tu omówione?

 

Odnośnik do komentarza
Udostępnij na innych stronach

6 minut temu, diver napisał:

Upss... log2/x to rzeczywiście nieco inna funkcja niż sqrt(x). :ermm:

 

Jeżeli już Bartek napieramy na matematykę, spróbujmy jeszcze bardziej elementarnie.
Zróbmy praktyczne obliczeniowo założenie, że podczas 1 minuty ekspozycji zbierzemy 1 jednostkę sygnału. Teraz powtórzę za Tobą jak "papuga", ale trochę inaczej.

 

Jak zrobisz jedno zdjęcie 1x1min to sygnał będzie np. 1. Szum fotonowy to *zawsze* pierwiastek z tego, więc 1.
Suma sygnału SS: 1 * 1 = 1
Szum od sumy sygnału: sqrt(1) = 1
Średnia sumy sygnału: 1/1 = 1
Średnia szumu od sumy sygnału: 1/1 = 1
SNR wynikowy: 1/1 = 1

 

Ciekawa matematyka... Co z tego w praktyce powinno wyniknąć? Że obiekt utonie w szumie?... :g:

Jedźmy jednak dalej.

 

Teraz 4 klatki po 1 minucie.
Suma sygnału SS: 4 * 1 = 4
Szum od sumy sygnału: sqrt(4) = 2
Średnia sumy sygnału: 4/4 = 1
Średnia szumu od sumy sygnału: 2/4 = 0,5
SNR wynikowy: 1/0,5 = 2

 

Teraz 1 klatka 4 minuty.
Suma sygnału SS: 1 * 4 = 4
Szum od sumy sygnału: sqrt(4) = 2
Średnia sumy sygnału: 4/1 = 4
Średnia szumu od sumy sygnału: 2/1 = 2
SNR wynikowy: 4/2 = 2

 

Wszystko się więc w ujęciu matematycznym zgadza. To znaczy przy przyjęciu zasady że finalny SNR liczymy jako avr(suma sygnału) / avr(sqrt(suma sygnału)), SNR dla jednej klatki z taką samym sygnałem jak dla n klatek matematycznie będzie taki sam.

 

Spróbujmy teraz sprowadzić to do praktyki. Dla uproszczenia obliczeń zakładamy nadal, że 1 minuta ekspozycji to 1 jednostka sygnału.
Powiedzmy, że zadowalający nas sygnał (jasność obiektu) uzyskamy już po 1 minucie ekspozycji.
Jeżeli więc zrobimy jedną klatkę 4 minuty to finalnie po uśrednieniu mamy więcej sygnału (4), a SNR po stackowaniu tej klatki wyniesie 2.
Jeżeli zrobimy 4 klatki po 1 minucie to na stacku będziemy mieli uśredniony sygnał jedynie zadowalający (1), a SNR też wyniesie 2.
Wydaje się więc że jedna 4-minutowa klata w sensie matematycznym powinna dać lepszy wynik, bo mamy na niej 4 razy więcej sygnału a SNR taki sam jak przy stacku 4x1.

Dlaczego więc nie zadowalamy się jedną klatką z dłuższym czasem ekspozycji poddaną procesowi stackowania (dodane darki, flaty i biasy)?
Czy program do stackowania liczy jedną klatkę według innych zasad? Nie tych, które zostały tu omówione?

 

 

 

Sprowadźmy Twoją "praktykę" do jeszcze bardziej praktycznej (pomijając rzecz jasna inne szumy niż fotonowy i inne sygnały, niż ten dla nas wartościowy)

 

a) Zrobiliśmy 1x4min. S=4, N=2, SNR=2. Nie ma stackowania.

Końcowy S=4, końcowy N=4, SNR końcowe = 2. 

Na zdjęciu wynikowym obiekt będzie dość jasny, więc zostawimy tak, jak jest..

 

b) Zrobiliśmy 4x1min. S=1, N=1, SNR=1. Stackujemy bez uśredniania:

Średni S=4, średni N=2, SNR po stackowaniu = 2. Efekt identyczny jak przed chwilą.

 

c) A teraz 4x1min z uśrednianiem. S=1, N=1, SNR=1. Stackujemy i uśredniamy:

Średni S=1, średni N=1/2, SNR po stackowaniu = 2.

Wynikowe zdjęcie jest 4x ciemniejsze, niż w a) czy b), więc rozciągamy histogram, efektywnie mnożąc wartości x4:

Ostateczny S=4, N=2, SNR= <oczywiście> 2. Efekt doskonale identyczny.

 

Zapominasz, że zawsze można pomnożyć albo podzielić przez jakąś liczbę i nic nie tracisz. Można też dodać stałą wartość - też nie ma to wpływu na SNR.

 

Wniosek? Dopóki mamy idealną sytuację, w której nie ma innego szumu, niż fotonowy, to nie ma znaczenia czy naświetlasz 4x1 czy 1x4.

 

W rzeczywistości dochodzi:

- prowadzenie montażu (im dłużej tym większe ryzyko pojechania)

- nasycenie pikseli (powyżej wartości maksymalnej nie rejestrujemy już więcej sygnału)

- szum termiczny (im dłużej tym gorzej)

- szum odczytu (im krótsze klatki tym większą rolę odgrywa)

- szum LP (im dłużej tym lepiej)

- fixed pattern noise (im więcej klatek tym gorzej)

- szum kwantyzacji

- błędy obliczeń zmiennoprzecinkowych

- wiele innych czynników....

 

Odnośnik do komentarza
Udostępnij na innych stronach

  • 2 tygodnie później...

Dołącz do dyskusji

Możesz dodać zawartość już teraz a zarejestrować się później. Jeśli posiadasz już konto, zaloguj się aby dodać zawartość za jego pomocą.

Gość
Dodaj odpowiedź do tematu...

×   Wklejono zawartość z formatowaniem.   Usuń formatowanie

  Dozwolonych jest tylko 75 emoji.

×   Odnośnik został automatycznie osadzony.   Przywróć wyświetlanie jako odnośnik

×   Przywrócono poprzednią zawartość.   Wyczyść edytor

×   Nie możesz bezpośrednio wkleić grafiki. Dodaj lub załącz grafiki z adresu URL.

×
×
  • Dodaj nową pozycję...

Powiadomienie o plikach cookie

Umieściliśmy na Twoim urządzeniu pliki cookie, aby pomóc Ci usprawnić przeglądanie strony. Możesz dostosować ustawienia plików cookie, w przeciwnym wypadku zakładamy, że wyrażasz na to zgodę.