WielkiAtraktor

Godzinę temu, Mareg napisał:

Obrazy ze "sztucznej gwiazdy" nie mają wyraźnych prążków dyfrakcyjnych, więc to raczej nie bardzo miarodajny test.

Z mojej (TS 50 µm) mają ― książkowy wzór Airy'ego (320x, źrenica wyjściowa ok. 0,6 mm). Używam jej do kolimacji RC8, acz ustawiam jakieś 100 m od teleskopu (a i tak muszę przedłużkę do wyciągu dokładać, żeby wyostrzyć).

@dobrychemik może to głupie pytanie, ale nie mógłbyś użyć którejś kamerki astro jako detektora? Skierować tę odbitą/przepuszczoną (przez obiekt badany) wiązkę z monochromatora na sensor kamerki (przez obiektyw albo po prostu wyczernioną rurkę, ze światłem w pokoju zgaszonym), połapać kilkadziesiąt klatek w 10/12 bitach, posumować wartości pikseli. Charakterystyki odpowiedzi sensorów są chyba wystarczająco liniowe.

5 minut temu, Krzysztof z Bagien napisał:

Jesteś pewny? Bo np. w AZ-EQ5 powyżej 1000"/s oś musi się zatrzymać, żeby zmienić prędkość

Moja wina, nie zinterpretowałem "dowolnie" wystarczająco mocno. Tak, w HEQ5 (przynajmniej: w moim) też trzeba zatrzymać oś przechodząc między reżimem wolnym (⩽128x prędkość gwiazdowa) i szybkim (>128x).

22 minuty temu, Krzysztof z Bagien napisał:

Czyli - czy da radę z kompa dowolnie zmieniać prędkość obrotu obu osi niezależnie od siebie? Bo, zdaje się, ten montaż od Rainbow Astro niby miał umieć, a potem się okazało, że nie da się ustawić różnych prędkości dla obu osi; ale mieli to poprawić.

Dziwne, myślałem, że to oczywista funkcja (na 8-letnim HEQ5 da się bez problemu).

Mógłby ktoś sprawdzić, jak ze stabilnością po założeniu tuby wielkości Maka 180/C8 (znaczy, czy całość nie ma tendencji do wywracania się, jeśli statywu się nie dociąży)?

Kol. Maksim ustrzelił w kolorze z 16":

6 godzin temu, Robson_g napisał:

Po prostu zdziwiłem się tym, że można aż tak bezgranicznie oddać dużą część swojego życia w takie przedsięwzięcia

Akurat to może chyba powiedzieć każdy człowiek o każdym hobby, którego sam nie uprawia

W sobotę wybrałem się sprawdzić, czy zachęcająca prognoza seeingu (~0,6") na Meteoblue dla przełęczy Flüela (2384 m n.p.m.) w Alpach się sprawdzi — i faktycznie, warunki były bardzo dobre.

Użyłem Intesa M715 (Rumak 180 mm f/15) z folią Baadera ND 3.8 i filtrem Solar Continuum (8 nm szerokości@540 nm) oraz trzema innymi, które znalazłem na eBayu:

F1 40 nm@450 nm
F2 20 nm@410 nm
F3 8,5 nm@395 nm

(wszystkie z blokadą podczerwieni do co najmniej 1100 nm).

Dwa filtry są kwadratowe 10x10 mm, jeden okrągły 15 mm, akurat, żeby nakryć szkiełko ochronne sensora:

Prowizoryczne mocowanie z papieru (wchodzi do noska 1,25"):

M715 z doczepionym Crayfordem 1,25" (kupiony wcześniej do Lunta 50):

Nie liczyłem na nie wiadomo jakie warunki, ale seeing był dobry nawet w 395 nm (to już bliski nadfiolet); fragment surowego wideo (zwolnione z 226 do 50 fps, migawka 3 ms; trochę trzęsło od wiatru):

Przy obróbce zastosowałem tylko lekką unsharp mask. Może i wyszło trochę miękko, ale dekonwolucja L-R dawała jak na mój gust zbyt wyraźny ringing na granulach.

Należy pamiętać, że poniższy materiał nie jest odpowiedni do w pełni obiektywnego porównania filtrów — zmieniałem gammę między nagraniami (i finalne krzywe tonalne różnią się nieco). (Następnym razem nagram też neutralne surówki z nieruszaną gammą). Poza tym możliwe, że teleskop ma jakiś szczątkowy sferochromatyzm w UV (choć Rumak akurat powinien być w tym dość dobry), no i seeing robi się dotkliwszy proporcjonalnie do λ^-5.

Niezależnie od powyższego, wyraźnie widać różnicę w intensywności „migotania chromosferycznego” (nie wiem, jak to się formalnie nazywa) — mam na myśli ten wzór szybkich rozjaśnień i pociemnień jakby nałożony na granulację. Im mniejsza długość fali, tym migotanie bardziej kontrastowe. Wspominam chromosferę, bo wygląda mi to na słabszą wersję migotania, które dominuje w animacjach CaK:

Wszystkie animacje poniżej mają 15-sekundowe odstępy między klatkami (10 s nagrania, 5 s przerwy); do animacji samej granulacji histogram został dodatkowo mocno rozciągnięty. Niestety, w środkowej części tarczy były tylko małe, niedorozwinięte plamy; na cel wziąłem południową część grupy AR 3045.

(opcja zapętlenia wideo pod prawym przyciskiem myszy)

Solar Continuum (20 minut):

F1 (12 minut):

F2 (10 minut):

F3 (23 minuty):

Najlepsze klatki:

Solar Continuum

F1

F2

F3

Nakręcone kamerą Blackfly S (IMX 273), obróbka w AS!3 i ImPPG.

A pewnie, do planet tym bardziej. Automatycznie pomyślałem najpierw o Słońcu (i Księżycu).

Mój akumulator AGM 12 V 7 Ah (opisany tutaj) zasilał małego kompaktowego Canona bez problemu całą dobę (robił zdjęcie co 3 s do timelapse'a). Potrzebny był adapter do gniazda baterii i przetwornica DC-DC za paręnaście złotych.

Co do wyboru klatek, warto jeszcze wziąć pod uwagę, że PIPP wybiera całe klatki — ale stackery (w tym AS!3) wybierają najlepsze fragmenty klatek. Czyli wstępne przepuszczenie przez PIPP może nas pozbawić niektórych dobrych fragmentów nisko ocenionych (przez PIPP) klatek. Co pewnie nie ma aż takiego znaczenia, bo klatki odrzucone przez PIPP zwykle całe będą rozmyte i do niczego... Jak kto ma czas, mógłby pobawić się w dogłębną analizę i porównania.

1 godzinę temu, Behlur_Olderys napisał:

(czerwone to DEC, żółte to RA)

Będzie prościej, jak opiszesz to w arkuszu, nazwy serii pojawią się w legendzie wykresu

Hmm, a nie jest tak, że wpływ na ów dołek mają też księżycowe maskony, które są głównie po obecnie widocznej stronie? Wyobrażam sobie, że długoczasowo mają tendencję do „zwisania” w stronę Ziemi, stąd (mimo chaotycznych wpływów innych ciał) Księżyc średnio odwrócony jest do nas zawsze obecną stroną.

4 minuty temu, AviatorL napisał:

Czy nie brakuje klasy GeoPoint?

Pewnie była w poprzednich częściach wątku. @Wiesiek1952 ponawiam sugestię wrzucenia tego na GitHuba, byłoby jedno repozytorium ze wszystkim, do którego można co jakiś czas dodawać odkurzony i sprawdzony kod

To jeszcze skrypt w PostScripcie:

% KONFIGURACJA -----------------------------------------------------

/inner_tick_radius_mm 27.319 def
/outer_tick_radius_mm 33.319 def
/outer_circle_radius_mm 35 def
/inner_circle_radius_mm 5 def
/circle_line_width_mm 0.25 def

% Liczba znaczników (wliczając te usunięte do celów kalibracyjnych); musi być parzysta i większa od zera.
/num_ticks 1800 def

% Liczba znaczników pominiętych przy rysowaniu.
/num_removed_ticks 10 def




%-------------------------------------------------------------------

%
% Konwersja mm na natywne jednostki PS (1/72").
%
/mm {
    72 mul 25.4 div
} bind def

%
% Rysowanie znacznika.
%
% parametry (od lewej):
%
%   xs, ys, rmin, rmax, angle_start, angle_end
%
/draw_tick {
    newpath
    5 index 5 index 5 index 4 index 4 index arc
    5 index 5 index 4 index 3 index 5 index arcn
    closepath
} bind def

/center_x outer_circle_radius_mm mm 1.5 mul def
/center_y outer_circle_radius_mm mm 1.5 mul def

/current_angle 0 def
/current_tick 0 def
/tick_angular_dist 360 num_ticks div def
/tick_angular_width tick_angular_dist 2 div def

circle_line_width_mm mm setlinewidth

newpath center_x center_y inner_circle_radius_mm mm 0 360 arc closepath stroke

newpath center_x center_y outer_circle_radius_mm mm 0 360 arc closepath stroke

% rysowanie znaczników
num_ticks {
    current_tick num_removed_ticks ge {
        center_x
        center_y
        inner_tick_radius_mm mm
        outer_tick_radius_mm mm
        current_angle
        current_angle tick_angular_width add
        draw_tick
    } if

    /current_angle current_angle tick_angular_dist add def
    /current_tick current_tick 1 add def

    fill
} repeat

showpage

Na PDF można skonwertować np. GhostScriptem:

$ gs -sDEVICE=pdfwrite -o enkoder.pdf enkoder.ps

enkoder.pdf

Czysty PostScript wybornie się nadaje do takich rzeczy Ale najprościej chyba napisać programik w czymkolwiek (np. w Pythonie), który wygeneruje odpowiedni SVG — do takiego rysunku potrzeba tylko podstawowych elementów.

ImPPG nie obsługuje obecnie plików wideo, bo to wyrównywanie było początkowo przeznaczone do obrobionych stacków, które siłą rzeczy występują jako osobne obrazy. Ale masz rację, to jak najbardziej sensowne, żeby funkcja wyrównywania mogła łyknąć bezpośrednio wideo i działać na jego klatkach. Dodam to w następnej wersji.

Notabene, kol. Sebastian robi postępy z budowaniem pod macOS — więc, Makowicze, bądźcie dobrej myśli.

W ImPPG używam korelacji fazowej , ale nie wiem, czy do takiego wymagającego dokładności zastosowania się nada (mnie wystarcza, że do animacji jest „na oko” płynnie).

6 godzin temu, MateuszW napisał:

Tak więc, żeby przekroczyć kolejny poziom dokładności, będziesz musiał zmierzyć charakterystykę swojego enkodera i uwzględnić ją w obliczeniach. Czyli coś jak PEC, ale nie dla przekładni, a układu pomiarowego. Taką charakterystykę zbierzesz albo guiderem (z ograniczeniem do seeingu plus wspomniane przez Ciebie "błędy" atmosfery i ugięć)

A jakby wycelować we w miarę odległą ścianę z cegieł (czy inny powtarzalny wzór)? Wtedy przynajmniej seeing i atmosfera odpadną. (Przy idealnym prowadzeniu wzór powinien przesuwać się jednostajnie w polu widzenia, pozostaje pomierzyć odchyłki).

I mnie się ten montaż podoba (5 kg mniej niż HEQ5 i precz z przeciwwagami!). Do moich potrzeb najwygodniej jest móc sterować montażem z komputera bez pośredników; z tego pliku w repozytorium INDI wynika, że protokół komunikacyjny AM5 odpowiada Meade LX200 Autostar. Jest doń pełna dokumentacja (link, link) (i oczywiście zawsze można podejrzeć praktyczne użycie w kodzie INDI).

23 godziny temu, Jarek napisał:

Zamiast obliczeń zostają pomiary.

8 godzin temu, Behlur_Olderys napisał:

Mnie interesuje powiększenie w sensie fizycznym: ile um obserwowanego obiektu odpowiada ilu um na matrycy.

Gdy podłączałem obiektyw foto z pierścieniami makro (a potem i obiektyw mikroskopowy) do kamerki, tak właśnie robiłem: cykałem fotkę podziałki na linijce, żeby dostać µm/pix.

8 godzin temu, Behlur_Olderys napisał:

Swoją drogą to strasznie dziwne że programy do obróbki graficznej nie wykorzystują karty graficznej?

ImPPG wykorzystuje już od 2,5 roku

...który prowadzi do strony Christiana Viladricha z dokładną analizą zachowania się etalonów w wiązce telecentrycznej o różnym F.