WielkiAtraktor

Podsumowując, dokładne ustawienie na biegun nie jest krytyczne. Niedokładność objawi się powolnym uciekaniem Słońca z pola widzenia, a jakby chcieć nagrać wiele sekwencji i potem złożyć animację poklatkową, będzie na niej widoczna rotacja pola. W szczególnych przypadkach można z powodzeniem kręcić z nieruchomego statywu foto (np. w Luncie 50 Słońce przechodzi przez pole widzenia mojej kamerki przez jakieś kilkadziesiąt sekund, wystarcza na zebranie klatek do stackowania).

Nie trzeba. Jeśli kręcisz w tym samym miejscu, co nocą, to w nocy zaznacz linię północ-południe parą kamieni czy sznurkiem, i potem ustaw montaż wg tego za dnia. Inne sposoby, które się u mnie sprawdziły: ustawienie na oko wg mapy i szczegółów terenu, ustawienie wg pozycji Słońca (jeśli zaczynamy kręcić w czasie około lokalnego górowania). Oczywiście przy takim nieidealnym ustawieniu trzeba będzie co jakiś czas korygować pilotem/programem pozycję montażu (może co kilka minut).

Podobnie jak poprzednio, proszę użytkowników o dodanie w jednym poście swoich najlepszych zdjęć/animacji (+ notka sprzętowa) z 2019 roku.

Dam, już robiłem przymiarki, ale trzeba jeszcze przemyśleć szczegóły

ImPPG w wersji 0.6.0 można pobrać z https://github.com/GreatAttractor/imppg/releases/tag/v0.6.0 Nowe funkcje: Back end GPU (OpenGL) zapewniający znacznie szybsze przetwarzanie Ulepszenia: Przewijanie widoku przez przeciągnięcie z prawym klawiszem myszy (dotychczas: ze środkowym) Zmiana powiększenia widoku kółkiem myszy (dotychczas: Ctrl + kółko myszy) Po wyczyszczeniu i uelastycznieniu architektury dodałem back end GPU/OpenGL, tj. prawie wszystkie obliczenia (oprócz wyrównywania sekwencji) są teraz wykonywane na GPU. W praktyce na większości komputerów oznacza to: co najmniej kilkakrotnie szybsze przetwarzanie dla dość dużych zaznaczeń (i umiarkowanej liczby iteracji dekonwolucji L-R) wynik renderowany jest w czasie rzeczywistym, wraz z przeciąganiem suwaka sigma przewijanie i odświeżanie widoku bez opóźnienia, gdy powiększenie ≠ 100% tryb interpolacji sześciennej nie obniża szybkości odświeżania widoku Można obejrzeć to w akcji na krótkim filmiku: Porównanie prędkości na moim komputerze (CPU: Ryzen 2700, 8C/16T, podst. takt. 3.2 GHz, GPU: Radeon R370). Obróbka w trybie wsadowym 200 obrazów po 1,2 MPix, 50 iteracji L-R, unsharp masking i zmiana krzywej tonalnej: CPU: 2:20 min GPU: 19 s Nawet na 5-letnim laptopie ze zintegrowaną grafiką Intela pracuje się zauważalnie szybciej. Tryb GPU zostanie włączony automatycznie przy pierwszy uruchomieniu wersji 0.6.0. Aktywny tryb wyświetlony jest po prawej na dole na pasku statusu: Tryby można przełączać w menu:

Podejrzewam, że to przez jaśniejsze hotpiksele (gwiazdki?) - dzięki nim histogram nie jest na podglądzie aż tak rozciągany (jak w dwu pierwszych postach), inaczej musiałyby zostać obcięte.

Może cisza przed burzą Jeśli rąbnie tej zimy, proszę osoby z wielkoaperturowymi zestawami DS o kręcenie time lapsów noc w noc.

A propos, ostatnio (szukając czego innego) zauważyłem skorygowane Schmidty-Cassegrainy (ACF) f/8, chyba tylko Meade taką światłosiłę sprzedaje.

Może nowe podejście do EXO: zamawiamy ten sam sprzęt hurtowo u Chińczyków i (co wiąże się z nieco wyższą ceną niż u innych) gwarantujemy, że skolimowaliśmy i sprawdziliśmy na gwiazdach?

Tutaj obszerny wątek na CloudyNights: https://www.cloudynights.com/topic/421894-lasik-eye-surgery-and-observing/

Tak, heliospektrografy są świetne; na forum Solarchat (ten dział) kilka osób je zbudowało i można znaleźć sporo przykładowych obrazków; przykład z wątku Petera Zetnera: Tu akurat się nie zgodzę. Faktycznie, można osiągnąć bardzo wąskie pasmo, i to wokół dowolnej ciekawej linii widmowej, ale jakość obrazu to nie ta klasa, którą osiągamy z wąskopasmowym etalonem i kamerą rejestrującą wszystkimi pikselami naraz. Acz jestem ciekaw, czy dałoby się zrobić sensowną animację np. protuberancji.

Najbardziej przemawia do mnie coroczna zbiórka. Będzie i przypomnienie, i bez wymogu regularności, i czasem wpłacą jedni, czasem inni. Takie podejście pomaga Stephenowi Ramsdenowi w finansowaniu jego CBSAP (i forum Solarchat).

Może pomóc też dryf w trakcie nagrywania, tutaj pokazałem to dla PGR Firefly: https://astropolis.pl/topic/48891-chameleon-3-icx445/?do=findComment&comment=575548

Można robić i tak, ale pewnie większość tu pokazanych to pojedyncza ekspozycja (tzn. wiele zestackowanych surowych klatek, ale naświetlanych tak samo). Gdy protuberancje są dość jasne, wystarczy lekko „podciągnąć” ciemny koniec krzywej tonalnej w ulubionym programie graficznym, żeby je wydobyć.

Na forum Solarchat koledzy zaproponowali zerknięcie na oprogramowanie BassSpectro do obróbki danych: https://groups.io/g/BassSpectro

O ile pamiętam, na stronie Astrokraka była informacja, że zbudowali na zamówienie hiperboliczny astrograf dla jednego z kolegów polujących na supernowe (ale może to inny typ).

Zgadza się.

Promień jest podawany do funkcji SKRY_init_quality_est jako detail_scale. W oknie ustawień Stackistry jest to parametr „skala szczegółów”: Ponieważ samo rozmycie to 3-krotne nałożenie filtra uśredniającego z równymi wagami, nie wiem, jakie to daje w przybliżeniu odchylenie std. Ale grunt, że rozmywa — do sortowania klatek i fragmentów względem jakości się sprawdza. aktualizacja: Rozpisałem się, a na pytanie nie odpowiedziałem. Dobór promienia: dla materiału mającego optymalną skalę (lub "undersampled"): wartość 1. Dla znacznie powiększonego (oversampling) lepiej 2-3.

Niezupełnie. Firmware MagicLantern do Canonów daje możliwość zapisu nieskompresowanego wideo, również w pełnych 14 bitach jak RAWy (chyba tylko niektóre modele, no i maks. rozdzielczość zależy od wydajności karty pamięci).

FITS też ma możliwość kompresji; może po prostu niewiele popularnych wśród nas-amatorów narzędzi to obsługuje. https://heasarc.gsfc.nasa.gov/docs/software/fitsio/compression.html

Znalazłem ostatnio na Cloudy Nights wątek o nowym otwartoźródłowym stackerze planetarnym PSS (czyli ze Stackistry są już co najmniej dwa). Zmotywowany jego dokumentacją, w końcu przysiadłem i opisałem algorytmy używane przez Stackistry/libskry: link do PDF (po ang.)

Nie sądzę, żeby to była jakaś przeszkoda. W latach 50. i 60. krążyły non-stop bombowce strategiczne obładowane bombami (nawet kilka Amerykanie zgubili…). Sporo wystrzelono też satelitów z generatorami radioizotopowymi (https://en.wikipedia.org/wiki/List_of_nuclear_power_systems_in_space). Jeśl pojawiłaby się kiedyś wola polityczna i budżet, do Oriona po prostu zastosowuje się bardziej surowe zasady bezpieczeństwa.

Pamiętajmy o odróżnieniu asysty grawitacyjnej jako takiej (bliski przelot obok masywnego, poruszającego w jakimś pasującym nam kierunku się ciała, by zmienić nasz wektor prędkości kosztem pędu „asystenta”) od samego efektu Obertha (https://en.wikipedia.org/wiki/Oberth_effect). W tym drugim chodzi o odpowiedź na pytanie: „rakieta jest w stanie odpalić silnik o ciągu F przez czas Δt (albo prościej, jeśli Δt jest krótkie: jest w stanie zwiększyć swój pęd o Δp), kiedy jest najlepszy moment na zrobienie tego (by dołożyć jak najwięcej energii kinetycznej)?”. Odp.: gdy poruszamy się z największą prędkością. Czyli np. w przypadku spadania przez środek planetoidy, jak najbardziej należy odpalić w samym środku. (Efekt jest nieintuicyjny, ale matematyka jest na poziomie fizyki z podstawówki, więc każdy łatwo może sprawdzić). A w połączeniu z normalną asystą grawitacyjną — w chwili największego zbliżenia do asystującego ciała.