WielkiAtraktor

Świetne. Ostrzyłem sobie zęby na tę protuberancję, obserwując ją zeszłą dobę na http://halpha.nso.edu/ops.html, ale cały dzień miałem nie więcej niż po 5-10 minut Słońca między falami chmur.

Zapewne chodzi po prostu o zrobienie pliku wideo z osobnych klatek. Można to uzyskać od ręki np. w popularnych programach VirtualDub czy FFMPEG. Dla mnie niestety do animacji w świetle białym to podejście odpada: owszem, u siebie na komputerze mogę bez problemu zrobić filmik (używają np. kodeka x264) o wysokim bitrate, zachowujący wszystkie szczegóły (wychodził plik ok. 2 razy mniejszy niż animowany GIF), ale zarówno Vimeo, jak i YouTube rekompresują to tak, że drobne szczegóły ewolucji granulacji szlag trafia. Więc nie da się w ten sposób publikować. Z protuberancjami nie byłoby pewnie tak źle, acz wolę jednak bezstratność GIFów.

Ja póki co kładłem się na plecach, coś grubego pod głowę/kark i lornetkę na siebie (ze statywem z zsuniętymi nogami). 15x70 jest na tyle lekka, że znoszę, jak spoczywa mi na oczodołach.

Renims po paru wskazówkach już wyrównuje

W pierwszym poście nowa wersja 0.4. Zalecam pobranie z uwagi na ważną poprawkę. Zmiany: - obcinanie klatek wynikowych do największego wspólnego obszaru (jeśli chcemy dostać klatki powiększone do wspólnego obejmującego prostokąta jak przedtem, należy użyć opcji --no-crop) - poprawiona translacja przy zapisie wyrównanych obrazów, powodowała chaotyczne 1-pikselowe skoki

Uściślijmy - wtedy akurat wytargałem też (na Babią) laptopa i antyczny obiektyw 250 mm, coby postrzelać panoramy w podczerwieni Chameleonem, więc lornetkę na doczepkę przełknąłem Tak że potrzebność lub nie to już zależy od okoliczności... Naturalnie, do szybkiego wypadu (gdzie bagaż = kurtka i butelka wody) też bym jej nie brał.

Uściślijmy – odpada chodzenie z lornetką zawieszoną na szyi i szybkie celowanie co chwilę w zwierzynę i ptactwo z ręki. Ale rozłożenie się na szczycie ze statywem i dłuższe obserwacje widoków jak najbardziej, kilka razy moja TS Marine 15x70 już się w tej roli sprawdziła (bardzo dobrze).

Drobnica z dzisiejszego słonecznego późnego popołudnia. 1-minutowe odstępy (45 s nagrywania, 15 s przerwy), razem 25 minut. D=90 mm, f/13, etalon 1,5 Å, Chameleon mono: Wyrównane z użyciem imgalt (tak, pracuję właśnie nad dokładniejszym wyrównywaniem i zaczynam myśleć o nowym trybie: wykrycie i zakotwiczenie na brzegu tarczy).

Ja używałem tej, są podpisy (uwaga, północ na dole): http://alpo-j.asahikawa-med.ac.jp/kk07/m070515r.htm

Taki ładny wieczór, to wysunąłem refraktor przez okno i zainaugurowałem swoje tegoroczne Hα. D=90 mm, f/13, etalon 1,5 Å, Chameleon mono, Słońce poniżej 10 stopni nad horyzontem:

Przepraszam za mały off-topic, ale ten temat („noktowizor czysto optyczny”) poruszaliśmy już na astronomia.pl. Wyszło na to, że się nie da, musiałbyś mieć magiczne lusterko przepuszczające wszystko padające z jednej strony, a odbijające wszystko, co pada z drugiej strony. II zasada termodynamiki uniemożliwia to.

W pierwszym poście zamieściłem wersję 0.3. Zmiany: - akceptuje pliki BMP mono lub kolorowe, 8- lub 24-bitowe; po wyrównaniu zostaną zapisane w takiej samej głębi kolorów - naprawione zapisywanie BMP (czasem tworzone były niepoprawnej długości pliki, które IrfanView czy GIMP przyjmowały, ale Photoshop już nie) Ponadto: dodatkowe uwagi o używaniu bez wiersza poleceń.

W pierwszym poście jest już poprawiony imgalt.zip. Obecnie archiwum zawiera plik EXE i dwa pliki DLL, należy je rozpakować w tym samym katalogu. (Uwaga techniczna: jakoś nie udało mi się na szybko doprowadzić do tego, żeby MinGW zbudował plik wykonywalny statycznie połączony z PThread. Jak to opanuję, w archiwum znów będzie tylko 1 plik EXE).

I znów średniodaleka fotka, Tatry z ok. 40 km. UV/IR cut: Astronomik Planet IR Pro 742, surowe: obrobione:

W pierwszym poście zamieściłem nową wersję 0.2. Nie ma jeszcze tego dodatkowego wyrównywania, za to: Zmiany: - praca wielowątkowa

I słonecznych:) Na te drobne drgania (u siebie na ostrych, wyraźnych WL też mam) zaaplikuję niedługo dodatkowy przebieg wyrównujący (szybką metodą wspomnianą wcześniej w wątku).

Zgadza się (tak będzie w każdej wersji Windows). Jeszcze jedna uwaga, gdy wpisujemy polecenie ręcznie i katalogi źródłowy/docelowy zawierają spacje, trzeba objąć to cudzysłowami, np.: imgalt "c:\moje astro\2013 lipiec" --output-dir "c:\moje astro\2013 lipiec\wyrównane"

Dodałem kod źródłowy w pierwszym poście. Filmik nagrany, jak wszystko u mnie, kamerką Point Grey Chameleon mono (ta akurat animacja w całej okazałości: http://astropolis.pl/topic/39586-slonce-w-h/page-21?do=findComment&comment=506713). Do protuberancji konieczny jest bardzo wąskopasmowy filtr (zwykle H-alfa). Nada się dowolny popularny teleskop słoneczny (Lunt, Coronado), ale szczegółowość jak w moim przykładzie wymaga apertury 90 mm; fabryczne teleskopy tej wielkości są kosztowne, dlatego zmajstrowałem przystawkę do zwykłego refraktora z nie aż tak wąskim filtrem: http://astropolis.pl/topic/41505-h-z-filtrami-omega-optical/ Do pisania używam zwykle Eclipse+CDT. Jeszcze jeden przykład, animacja warpala (pomniejszona 2-krotnie): przed: po:

Tak, składam w GIMPie. Otwieramy wszystkie wyrównane klatki przez File->Open as Layers..., potem można je wszystkie naraz przyciąć (zaznaczamy prostokąt i Image->Crop to selection), i pozostaje wyeksportować. Jak wybierzemy format GIF, będzie opcja eksportu jako animacji. Część Twoich wyrównało dobrze, z tego co pamiętam z jedną lub dwoma mniejszymi się nie udało. Wyślij mi proszę mailem te, na których zawiodło, przyjrzę się wieczorem.

Tak, o tę filozofię chodzi. Zauważ, że jeśli na początku pozwolisz użytkownikowi wybrać myszką „punkt zakotwiczenia” (np. samolot), to wystarczy, jak pomiędzy kolejnymi klatkami będziesz porównywał te różnice kolumn/wierszy tylko w pewnym małym obszarze wokoło (np. 32x32, zależy od tego, jak szybko cel się przesuwa). Mam wrażenie, że np. AviStack używa dokładnie tego podejścia (w fazie frame alignment).

Napisane w C++. Chyba już jutro wrzucę, tylko muszę makefiles przygotować. Najbliższy cel to przyspieszenie i paralelizacja tego, bo na razie mam ok. 2 s na 1,3-megapikselową klatkę (1 wątek na Core i5-3570K). Ale do śledzenia samolotów itp., gdzie obiekt pomiędzy klatkami przesuwa się nieznacznie, znacznie prostsza i szybsza będzie metoda „minimalnej sumy różnic bloków” (testowałem to kiedyś, jest błyskawiczne). Coś jak opisane na początku tego dokumentu: http://image.ing.bth.se/ipl-bth/siamak.khatibi/computerVisionBTH10Summer/papers/BlockMatchingAlgorithmsForMotionEstimation.pdf