Tygodnik Astropolis - Udostępnij swoje projekty, postępy, odkrycia i wskazówki

[Paether]

6 godzin temu, wimmer napisał:

Jeśli tylko ktoś więcej wyrazi chęć, to czemu nie

Będą ludzie...i kilka psów się pewnie znajdzie 

[Tomek96]

To ja zaprezentuję moje zabawy po godzinach

Uczę się programu do ray tracingu dla optyki, a przy okazji zrobiłem taki oto układzik. Teleskop typu RC, 350mm średnicy, 2070 ogniskowej co daje światłosiłę F/5.9.

Obstrukcja 164mm, więc liniowo jest to 47%, powierzchniowo 22%. A więc w pewnym sensie efektywna aparatura to około 310mm, zatem efektywna światłosiła to F/6.7.

 

Prezentowany obrazek to spot size dla tego teleskopu, okrąg to 9um. Skala po lewej pokazuje kreskę o długości 0,02mm czyli 20um. Nadal nie jest idealnie, ale wcześniej kręciłem się w okolicach spot size o wielkości 1mm, więc teraz jest już "znośnie", ale nie idealnie.

Pokrycie to 44,5 mm obrazu, lustro wtórne jest na tyle duże, że nie powinno występować winietowanie. Jest to układ RC z eksperymentalnym własnym 2-elementowym korektorem, który jest umiejscowiony 150mm od matrycy. Układ działa dobrze dla -5/+2 mm od tej odległości, a więc zapas na dopasowanie złączek jest. Od powierzchni lustra do początku korektora jest 135mm, zatem z korektorem jest backfocus 300mm od powierzchni lustra, a więc pewnie 230mm od celi.

 

To jest projekcik, który się udał, ale dla mnie jest to zbyt wielki teleskop Wessel zwrócił uwagę, że ODK mają zbyt dużą obstrukcję i zbyt małą światłosiłę. Ten nadal jest ciut za ciemny i ma 2070mm ogniskowej, a Pan Maciej marzył o 1700mm

 

Wady tego teleskopu? Mała światłosiła, duża obstrukcja, problematyczna kolimacja i kto by zrobił ten korektor za przystępną cenę? Ponadto jak prowadzić tak dużą ogniskową, jak schładzać lustro, z jakich materiałów robić lustro, aby miało małą rozszerzalność cieplną (zerodur?)... No i trzeba byłby go zrobić To jak dzielenie skóry na niedźwiedziu...

 

To co z myślą o sobie projektuję (być może za 15 lat zaprojektuję, zbuduję, przetestuję) to układzik w okolicach RC lub DK 200/800, ale problem stanowi backfocus, który zakładam na poziomie 300mm. Walczę więc z astygmatyzmem i krzywizną pola. Próbuję też za wszelką cenę robić wtórne lustro sferyczne, aby łatwiej się je kolimowało.

Taki układ 200/800 z pewnością byłby fajny do astrofotografii

 

To jest taka drobna rzecz po godzinach. Może kiedyś przerodzi się to w coś większego?

 

Pozdrawiam

Tomek

 

Edytowane 28 Marca 2019 przez Tomek96

[Jagho]

20 minut temu, Tomek96 napisał:

To ja zaprezentuję moje zabawy po godzinach

Uczę się programu do ray tracingu dla optyki ...

To niesamowicie ciekawe. Co to jest za program, w którym modelujesz te projekty ?

[Tomek96]

@Jagho

OSLO EDU - wersja edukacyjna - ponieważ jestem studentem

Studiuję informatykę, ale znalazłem w internecie na kierunku fizyki optycznej UW materiały, żeby wykonać ćwiczenie właśnie w tym programie, więc od tego momentu z niego korzystałem.

Jestem z niego bardzo zadowolony, a z wiadomych powodów pokazałem tylko spot size bez szczegółów dotyczących korektora etc.

 

Próbowałem zaznajamiać się z literaturą dotyczącą budowania optyki, w szczególności do teleskopów, ale w PL w bibliotekach nie ma tego dużo. Od siebie mogę polecić tę stronę:

https://www.telescope-optics.net/

 

Jest to istna kopalnia wiedzy

Póki co najlepszy układ jaki udało mi się zrobić to 200/950, ale z niepraktycznym backfocusem tylko 100mm od lustra.

 

Pozdrawiam

Tomek

Edytowane 28 Marca 2019 przez Tomek96

[Jagho]

15 minut temu, Tomek96 napisał:

@Jagho

OSLO EDU - wersja edukacyjna - ponieważ jestem studentem

https://www.lambdares.com/oslo-usonly/

Z opisu i zrzutów ekranowych program wygląda nieźle (jak na moje zupełnie niedoświadczone oko) i cena (!!!) też pokazuje, że raczej dla profesjonalistów. Tomek, powodzenia i życzę Ci abyś w przyszłości (ale może szybciej niż za 15 lat) zadziwił społeczność astronomiczną jakimś ciekawym projektem.

Edytowane 28 Marca 2019 przez Jagho

[Adam_Jesion]

3 godziny temu, Tomek96 napisał:

To jest taka drobna rzecz po godzinach. Może kiedyś przerodzi się to w coś większego?

Świetna sprawa. Walcz i ucz się. Na pewno kiedyś to wykorzystasz i zbudujesz sobie własny teleskop, a może i go skomercjalizujesz?

[Adam_Jesion]

A tak swoją drogą, projektowanie optyki to jest defacto proces optymalizacji. Wydaje się, że to idealny materiał dla uczenia maszynowego (ML/AI). Czy ten soft (lub jakiś inny) już to robi?

[Tomek96]

10 minut temu, Adam_Jesion napisał:

A tak swoją drogą, projektowanie optyki to jest defacto proces optymalizacji. Wydaje się, że to idealny materiał dla uczenia maszynowego (ML/AI). Czy ten soft (lub jakiś inny) już to robi?

Optymalizacja na pewno jest - pytanie czy z poziomu tej wersji mam do niej sprawdzę. Na spokojnie to sprawdzę.

Gdyby nie była taka jaką chciałbym mieć, to zawsze mogę zrobić własny programik z ML do tego zagadnienia

Moje osobiste plany na najbliższe tygodnie jeśli chodzi o tworzenie oprogramowania po godzinach to stworzenie programu do stackowania bazującego na obliczeniach na kartach grafiki. Nie chcę się paprać w czystej CUDA, więc pewnie użyję Alea GPU, aby pisać w .NET. Wiem, że w ciągu kilku-kilkunastu miesięcy będę zmieniał kamerę, a nie chce mi się czekać 30 minut na wynik stackowania. Przecież na GPU chyba będzie się dało to zrobić w 2 minuty - de facto będzie nas ograniczać prędkość odczytu dysku

 

Pozdrawiam

Tomek

[Adam_Jesion]

2 godziny temu, Tomek96 napisał:

Przecież na GPU chyba będzie się dało to zrobić w 2 minuty - de facto będzie nas ograniczać prędkość odczytu dysku

Dokładnie. Aż trudno uwierzyć, że nikt tego jeszcze nie zrobił. Wiele rzeczy dałoby się praktycznie real-time wizualizować

[MateuszW]

4 godziny temu, Tomek96 napisał:

Przecież na GPU chyba będzie się dało to zrobić w 2 minuty - de facto będzie nas ograniczać prędkość odczytu dysku

Będę niecierpliwie czekał na efekt  Liznąłem GPU na zajęciach, ale nie miałem czasu się w to bardziej pobawić.

Zastanawiam się, na ile problematyczna będzie w procesie stackowania kwestia komunikacji. Bo jak w każdych obliczeniach równoległych, najlepiej jak jednostki obliczeniowe nie muszą się wymieniać danymi. Pytanie, jak dobrze zrównoleglają się algorytmy alignacji.

 

Zastanawia mnie kwestia GPU w PSie. Generalnie wydaje mi się, że ta akceleracja niewiele daje. Pytanie, czy jest tak słabo zrobiona, czy po prostu nie da się za bardzo przyspieszyć tych operacji graficznych?

 

Tak się do GPU odnosi PixInsight

Cytat

Obviously there are "many important priorities before GPU acceleration" in the further development of PixInsight.

 

Godzinę temu, trouvere napisał:

Chyba jeszcze bardziej trudno uwierzyć, że stakowanie on-line (tak, tak właśnie real-time) zostało zaimplementowane w kamerach video już około 2008 r.

Co masz konkretnie na myśli? Bo jeśli zwykłe uśrednianie klatek to jest to proces nieporównywalnie prostszy i jak najbardziej możliwy do zrobienia przy niewielkiej mocy obliczeniowej.

Ponadto, kamery czy aparaty są wyposażone w procesory DSP, które są specjalnie zoptymalizowane pod swoje zadania i wykonują wiele złożonych operacji czysto sprzętowo.

[Tomek96]

8 minut temu, MateuszW napisał:

Będę niecierpliwie czekał na efekt  Liznąłem GPU na zajęciach, ale nie miałem czasu się w to bardziej pobawić.

Zastanawiam się, na ile problematyczna będzie w procesie stackowania kwestia komunikacji. Bo jak w każdych obliczeniach równoległych, najlepiej jak jednostki obliczeniowe nie muszą się wymieniać danymi. Pytanie, jak dobrze zrównoleglają się algorytmy alignacji.

Teraz to co piszę to szybkie przemyślenia na żywca, więc mogą być tu fundamentalne błędy w rozumowaniu:

Problem numer 1: Na każdej klatce trzeba znaleźć gwiazdy.

Problem numer 2: Musimy znaleźć, które gwiazdy odpowiadają którym w klatce referencyjnej. Klatka referencyjna tylko do odczytu.

Problem numer 3: Sam proces stackowania.

 

Problem numer 1 jest spokojnie do zrównoleglenia po przetwarzaniu jednego obrazu, kilka kolumn lub wierszy ląduję w pierwszym wątku, kolejne w kolejnych i tak kilkaset wątków lub kilka tysięcy wątków. Możemy nie tyle co ściągać kolumny a nawet przesuwać się tylko maską w trybie odczytu. Nie jest wymagana synchronizacja na poziomie globalnym, lokalnie bardzo szybka synchronizacja wątków w bloku powinna wystarczyć. Na koniec należy tylko połączyć zebrane dane.

 

Problem numer 2 nie będzie już zajmował sporo miejsca w pamięci, ponieważ będą to listy zawierające po kilka tysięcy elementów. Zatem pokuszę się o stwierdzenie, że można byłoby zrównoleglić po liczbie zdjęć pakując wszystkie dane do pamięci i wątków. Nie muszą się komunikować. Muszą zwrócić parametry przesunięcia względem klatki referencyjnej.

 

Problem numer 3 to problem gdy znów musimy załadować dane obrazowe, przetworzyć na nowe pozycje, dodać do zdjęcia wynikowego dla algorytmów sumy, średniej etc. Problemy pojawiają się przy medianie, sigma clip etc. Wtedy przydałoby się mieć cały "zbiór wartości" dla danego piksela, aby wyznaczyć medianę czy też pochodne jej. Suma i średnią można obliczyć w O(n), a medianę chyba w co najmniej O(nlogn). I pojawia się pytanie - czy ładować zdjęcia po kolei, czy też najpierw zając się pierwszą kolumną i analizujemy wszystkie pliki. Wtedy mielibyśmy otwartych bardzo dużo strumieni, ale oszczędzamy na pamięci. Z kolei jak będziemy ładować zdjęcia po kolei do pamięci, to na końcu działania algorytmu musimy mieć wszystkie dane (dla mediany) w pamięci, czyli np. 30GB. I to jest złe rozwiązanie. Muszę doczytać jak się robi takie rzeczy, bo z kolei czytanie randomowe z naraz 600 plików też nie wydaje mi się dobre. Nadzieja jest w przebudowaniu algorytmu np. Quick Search już na etapie kilku tysięcy wątków, aby rekurencja działa się w każdym wątku. To zmienia trochę sposób myślenia, ale być może zastosowanie nawet jakiegoś gorszego algorytmu (np. O(n^2)) może dać nam lepsze efekty niż O(nlogn), ponieważ puścimy n wątków, gdzie każdy wykona O(n), a więc czas będzie logn razy krótszy A log2(1024) to 10, więc jest o co walczyć. Oczywiście należy pamiętać o współczynniku przy złożoności średniej i stałej, bo może się okazać wolniej. Ale nie sądzę

Trzeba na spokojnie się zastanowić. Dla mnie nie ma problemu raczej z alignacją, a jest problem z procesem stackowania. Bo tu będą ciekawe algorytmy obliczania wartości na zbiorach w sposób równoległy i kiedy dodajemy sekwencyjnie kolejne klatki.

 

To tak pokrótce

Przepraszam za taki offtop na forum o tematyce astronomicznej.

 

Pozdrawiam

Tomek

[MateuszW]

31 minut temu, Tomek96 napisał:

Musimy znaleźć, które gwiazdy odpowiadają którym w klatce referencyjnej.

Znasz na to jakiś algorytm?

32 minuty temu, Tomek96 napisał:

Z kolei jak będziemy ładować zdjęcia po kolei do pamięci, to na końcu działania algorytmu musimy mieć wszystkie dane (dla mediany) w pamięci, czyli np. 30GB. I to jest złe rozwiązanie. Muszę doczytać jak się robi takie rzeczy

DSS robi to właśnie w ten sposób  Zapisuje na dysku ogromny plik tymczasowy i potem jedzie po nim medianami itp. Ale tak na prawdę, to etap wyliczania końcowego obrazu jest w miarę krótki w porównaniu do poprzednich czynności.

33 minuty temu, trouvere napisał:

No to tym razem ja mam dwa pytania, pierwsze co konkretnie nazywasz zwykłym uśrednianiem klatek ? I drugie, czym według Ciebie jest stacking ?

Zwykłym uśrednianiem nazywam wzięcie sekwencji zdjęć i policzenie średniej (czy tam czegoś innego) dla każdego piksela. W szczególności bez alignacji. Stackowaniem nazywam tutaj kompletny proces, który opisał Tomek (analiza zdjęć, alignacja, "właściwe" stackowanie).

36 minut temu, trouvere napisał:

Widzisz jakiś problem w tym, że kamera wykonuje jakieś operacje sprzętowo a nie programowo bo ja nie.

Nie widzę w tym problemu, ale to jest powód dla którego stosunkowo proste i tanie urządzenia potrafią wykonywać niebywale szybko pewne czynności, z którymi komputer mógłby mieć  problem. To takie lekkie "oszustwo"  

[Adam_Jesion]

9 godzin temu, MateuszW napisał:

Zastanawia mnie kwestia GPU w PSie. Generalnie wydaje mi się, że ta akceleracja niewiele daje. Pytanie, czy jest tak słabo zrobiona, czy po prostu nie da się za bardzo przyspieszyć tych operacji graficznych?

Photoshop cierpi na swój wiek - to jest architektura napisana w latach 90-tych  Trudno teraz napisać cały program przynoszący miliardy zupełnie od zera (ryzyko kompatybilności, etc), ale to się dzieje step-by-step i paralelizm jest coraz mocniej wdrażany w filozofię. Są nowe programy graficzne, które już powstały w paradygmacie wielowątkowości i GPU (vide Affinity). Wydajność jest nieporównywalna. 

Piszesz, że różnica w Photoshopie jest niezauważalna. No nie - tam gdzie jest wielowątkowość z GPU różnica jest szokująca. Nie wiem, od kiedy pracujesz w PS (ja zawodowo od 93 roku :)), ale kiedyś wykonanie np. blura na dużym zdjęciu trwało wieki. Teraz możesz trzasnąć blue na 2GB zdjęciu. prawie real time  Tak samo filtry typu Lens Blur, które symulują realne zachowanie głębi ostrości - bez GPU - tragedia. Z GPU - super. Generowanie kafli (w pamięci podręcznej), skalowanie preview (płynny zoom ogromnego zdjęcia), to wszystko jest zaimplementowane i działa ok. Oczywiście ciągle jest wiele rzeczy w PS, które działa jednowątkowo.

[szuu]

programy operujące na dużych obrazach dzielą je na "kafelki" tak żeby piksele z jednego rejonu obrazu były blisko siebie w pamięci co polepsza skuteczność cachowania (a różnice w czasie dostępu do cache i do ramu są olbrzymie. nawet najszybszy procesor superwielordzeniowy pada na kolana gdy musi w każdym cyklu czekać na transfer z pamięci bo program ciągle sięga w inne miejsca i niczego nie da się zcachować)

być może przy stackowaniu (końcowa faza - łączenie obrazów), gdzie trzeba korzystać w jednym kroku algorytmu z danych z bardzo wielu obrazów czyli bardzo wielu odległych obszarów pamięci też da się zastosować jakąś strategię która polepszy lokalność odwołań.

 

kamery które od dawna potrafią sumować obrazy dla polepszenia czułości to zupełnie inna kategoria. nie ma tam w ogóle potrzeby zapamiętywania więcej niż jednego obrazu ani wyszukiwania w nim czegokolwiek. lecą sobie nowe nowe dane i są po kolei dodawane do istniejących w pamięci i tak w kółko dla każdej nowej klatki. pewnie nawet arduino dałoby radę

[Adam_Jesion]

Zauważ, że jeszcze chwilę temu uważano, że np. typowy rendering nie da się robić na ograniczonych na GPU, a tylko na CPU. Aż nagle wszystko się zmieniło i dzisiaj GPU totalnie rewolucjonizuje branże 3D (nie mylić z realtime 3D oczywiście).

Myślę, że w stackowaniu da się tak posegmentować dane i rozłożyć ją na wiele wątków, że przyspieszenie będzie ogromne. Stackowanie to statystyka, a w statystyce i big data stacje obliczeniowe na GPU robią rewolucyjną robotę. Pewnie dałoby się zastosować jakieś istniejące biblioteki do analizy danych i je dostosować do naszych potrzeb.

PS. Współczesne karty graficzne mają już po kilkanaście GB pamięci, a to znacznie upraszcza kwestię. Nie trzeba transferować danych pomiędzy RAM, a GPU w czasie obliczeń.

[szuu]

a czymże w istocie rzeczy jest najnowszy android jeśli nie tym samym co nokia sprzed 20 lat

stosując odpowiednio szczodre generalizacje to w ogóle prawie wszystko jest identyczne z prawie wszystkim

[MateuszW]

Godzinę temu, trouvere napisał:

A czym w istocie rzeczy jest stakowanie jeśli nie składaniem obrazów w celu polepszenia czułości ? To, że wprowadzono zamiast prostego sumowania operowanie medianą każdego piksela w niczym nie zmienia istoty operacji

Przecież już napisałem, nie rozumiesz? Stackowaniem nazywamy nie tylko samo uśrednianie pikseli, czy liczenie mediany, a również kilka złożonych operacji, jakie dzieją się wcześniej - preprocessing, czyli analiza materiału, znalezienie gwiazd, określenie jakości, normalizacja, kalibracja, oraz alignacja klatek (znalezienie przesunięcia względem siebie). Tych wszystkich operacji nie robi Twoja kamera z 2008 roku.

Natomiast zmiana średniej na medianę w Twojej kamerze spowodowałoby znaczne utrudnienie dla kamery, bo zamiast trzymać jedną klatkę, musiałaby ona trzymać wszystkie naraz. W komputerze mamy wielką pamięć i to nie duży problem.

2 godziny temu, trouvere napisał:

swoją drogą tego rodzaju statystyczne podejście do zwiększenia czułości nie jest najlepszym rozwiązaniem

Tak, mediana daje mniejszą poprawę snr od średniej, ale pogorszenie to nie jest duże, a w zamian mediana pozwala dość skutecznie pozbyć się ekstremów, jak ślady po satelitach, czy hotpiksele. Średnia tego nie "potrafi", taki ślad zawsze pozostawi swoje "echo" na zdjęciu.

[Adam_Jesion]

22 minuty temu, MateuszW napisał:

Tak, mediana daje mniejszą poprawę snr od średniej, ale pogorszenie to nie jest duże, a w zamian mediana pozwala dość skutecznie pozbyć się ekstremów, jak ślady po satelitach, czy hotpiksele. Średnia tego nie "potrafi", taki ślad zawsze pozostawi swoje "echo" na zdjęciu.

Po to wymyślono trochę bardziej zaawansowane algorytmy, żeby mieć zalety mediany, ale bez utraty poziomu szumu. 

https://www.gnu.org/software/gnuastro/manual/html_node/Sigma-clipping.html

Przy okazji - tu masz info o PS + GPU: https://helpx.adobe.com/photoshop/kb/photoshop-cc-gpu-card-faq.html

 

Z drugiej strony PS ciągle leży w świecie pojedynczych wątków i nie wykorzystuje wielordzeniowości dzisiejszych procesorów. Niby modułów wielowątkowych przybywa, ale ciągle większość funkcji programu działa na 1 wątku. W ostatnich wersjach wreszcie można zapisywać pliki niezależnie od pracy, co jest wielkim osiągnięciem dla Adobe, bo wymagało przepisania sporej części programu.

[MateuszW]

37 minut temu, Adam_Jesion napisał:

Po to wymyślono trochę bardziej zaawansowane algorytmy, żeby mieć zalety mediany, ale bez utraty poziomu szumu. 

Jasne, masz rację. 

Ale czy snr z sigmy na pewno jest taki sam jak średnia? Może jest jakiś ubytek, ale mniejszy niż w medianie? 

[Adam_Jesion]

34 minuty temu, MateuszW napisał:

Ale czy snr z sigmy na pewno jest taki sam jak średnia? Może jest jakiś ubytek, ale mniejszy niż w medianie? 

Kiedyś mierzyłem i jest praktycznie identyczny. Różnice są całkowicie pomijalne, biorąc pod uwagę benefity. Choć ja stosowałem zasadę, że jak miałem mniej niż 10 klatek, to nie używałem.

[Krzychoo226]

Sigma clipping to najnormalniejsze narzędzie statystyki. Nikt nie używa średniej czy mediany do badania danych które mogą być obarczone błędnymi wartościami, nie rozumie dlaczego a naszym hobby panuje jakiś dziwny opór przed sigmą.

[MateuszW]

40 minut temu, Krzychoo226 napisał:

nie rozumie dlaczego a naszym hobby panuje jakiś dziwny opór przed sigmą.

W moim przypadku to zwykłe przyzwyczajenie i tyle Nigdy nie przywiązywałem do tego większej wagi. Teraz będę. 

[Krzychoo226]

2 godziny temu, trouvere napisał:

Może dlatego :

 

When working on astronomical images, objects like galaxies and stars are blurred by the atmosphere and the telescope aperture, therefore their signal sinks into the noise very gradually. Galaxies in particular do not appear to have a clear high signal to noise cutoff at all. Therefore σ-clipping will not be useful in removing their effect on the data.

 

źródło: https://www.gnu.org/software/gnuastro/manual/html_node/Sigma-clipping.html

Ale rozumiesz jak ona działa? Chyba nie, bo to co tu cytujesz możesz zastosować do dowolnej metody. Gdybyśmy żyli w idealnym świecie i jedyny szum pochodziłby od fotonów to stackowałoby się średnią, w takim świecie niestety nie żyjemy.

[Adam_Jesion]

Jest jeszcze SD Mask Raya Gralaka, zaimplementowany w Maximie  Mój ulubiony (zmodyfikowany Sigma Clipping).

[Krzychoo226]

Dodałem update po pierwszych testach montażu: