Strona GłównaMetrec - instrukcja obsługi.
Metrec - instrukcja obsługi.
Wersja 07.04.2014 - dodany uruchamianie MetReca "na skróty" - bez pliku .ref.
Wersja 06.04.2014 - dodany rozdział o rozwiązywaniu problemów.
Wersja 21.09.2013 - autostart MetReca i auto-data w nazwie pliku log, przeredagowania.
Wersja 01.04.2013 - dalsze drobne zmiany (głównie moduł grab).
Wersja 11.03.2012 - drobne poprawki do działu przesyłanie danych do IMO.
Wersja 26.02.2012 - uaktualnione rozdziały o przesyłaniu danych do IMO...
Jeśli masz kłopot z uruchomieniem MetReca - rozwiązania szukaj przede wszystkim w rozdziale o rozwiązywaniu problemów.
Na końcu instrukcji można znaleźć załączoną prezentację omawiającą optymalizację czułości MetReca.
Metrec jest oprogramowaniem freeware stworzonym około 1997 roku przez Sirko Molau, przeznaczonym do wykrywania i rejestracji meteorów za pomocą zestawu kamery cctv i komputera. Metrec ma minimalne wymagania w stosunku do komputera. Wadą jest konieczność nabycia nieprodukowanej od dawna karty Matrox Meteor w cenie około 80 €.
Spis treści.
Wstęp.
Co trzeba mieć, aby zacząć.
Instalacja pakietu.
DOS dla opornych.
Grab - dark i obraz referencyjny.
Plik refstars.osc - współrzedne stacji.
Maska - przeszkody w polu widzenia.
Refstars - wskazanie metrecowi gwiazd.
Plik metrec.cfg - konfiguracja metreca.
Metrec - prowadzenie obserwacji.
Metrec "na skróty" - jak szybko zacząć bez pliku referencyjnego.
Metrec - rozwiązywanie problemów.
Postproc - redukcja danych.
Optymalizacja plików referencyjnych.
Przesyłanie danych do IMO.
Redukcja danych przed ich przesłaniem do IMO.
Wstęp.
Niniejsze luźne notatki powstały w celu praktycznego przeprowadzenia użytkownika metreca przez instalację i uruchomienie pakietu oraz przesyłanie danych do PKiM a także, docelowo, do IMO. Jeśli ktoś zamierza przesyłać dane do IMO powinien zapoznać się z poświęconymi temu rozdziałami, ponieważ tamta sieć ma inne zasady działania niż PFN czego zrozumienie ma istotne znaczenie dla prawidłowego przygotowania danych.
Interfejs metreca jest czarno-biały - wszelkie kolorowe oznaczenia i teksty na zrzutach z ekranu są dodane przeze mnie. Metrec ma dwie wersje - jedna pracuje tylko pod dosem (nie można jej uruchomić w oknie dosowym MS Windows) - a druga pracuje tylko w oknie dosowym i tylko pod systemem Windows XP 32 bitowym. Instrukcja powstała na bazie wersji dla Windows XP – wersja dosowa jest w zasadzie identyczna. Program nie toleruje przecinka w roli znaku oddzielającego miejsca dziesiętne od całości - można używać w tym celu wyłącznie kropki. We wszystkich modułach użycie danego klawisza z shiftem powoduje przeciwne działanie (jeśli np. "małe" c powoduje zwiększenie kontrastu, to "duże" C zmniejsza go).
Sirko Molau uaktualnia oprogramowanie, nie zmieniając jednak czasami numeru wersji. Jedynym pewnym znacznikiem kolejnych uaktualnień jest data widoczna pod numerem wersji w oknie głównym programu (por. rys. 7). Sirko Molau nie opublikował manuala, jednak dość szczegółowo opisuje wprowadzane zmiany na mailowej liście dyskusyjnej metrec@yahoogroups.com . Innym xródłem sa zapiski autora w wiki: http://www.imo.net/wiki/index.php/Practical_hints_for_MetRec_users .
Jeśli ktoś zaczyna zupełnie od zera, to przede wszystkim nie powinien się zniechęcać. Metrec nie jest user-friendly. Nie ma rozbudowanej pomocy, nie zawiera podpowiedzi i nie sugeruje którą opcję wybrać. W razie błędu reakcja jest typowa dla dosowych programów – wyświetlenie składni źle wprowadzonego polecenia i powrót do linii poleceń z kursorem. Tam gdzie jest mowa o pakiecie oprogramowania, chodzi o całość, tam gdzie padają nazwy poszczególnych jego części składowych jak grab, refstars czy metrec (będących w istocie osobnymi programami) – chodzi konkretnie o te moduły.
Obecna stabilna wersja to 5.1, charakteryzująca się m. in. możliwością określenia minimalnej i maksymalnej prędkości kątowej zjawisk. Wszyscy powinni jak najszybciej przejść z wersji starszych na najnowszą.
Mocne strony wersji 5.1 vs 4.x to m.in.:
- wkopiowanie momentu wykonania w obraz referencyjny (program grab), możliwość użycia kilku obrazów referencyjnych do obliczania siatki współrzędnych (program refstars),
- wykrywanie gwiazd w czasie pracy i zapisywanie ich pozycji (program metrec), które następnie można użyć do optymalizacji siatki współrzędnych w programie refstars,
- opcjonalne wykonywanie obrazków tła w określonym interwale,
- stała korekta zegara programu według czasu systemowego (metrec),
- uproszczone codzienne przesyłanie danych do IMO bez wstępnych przygotowań,
- określanie teff z lm wykrytych gwiazd, możliwość wysyłania danych na serwer IMO w czasie rzeczywistym, usprawnienia refstarsa
Prace wstępne - co trzeba mieć, aby zacząć.
Wiele spraw "sprzętowo-montażowych" zostało szczegółowo omówionych na stronie PKiM - tutaj podano jedynie podstawowe kwestie.
Karta tv Matrox.
W przypadku metreca najbardziej ekskluzywnym i trudno dostępnym elementem zestawu jest karta Matrox Meteor II lub II Multi-Channel. Karty Meteor I działają, jednak tylko pod dosem (nie w dosowym oknie windows). Sprowadzenie karty może wymagać nieco czasu i nie jest tanie - obecna cena to ok. 80 lub 40 € zależnie od typy wyjścia antenowego, plus przesyłka. Nie są one produkowane od wielu lat - można je kupić jedynie używane np. na e-bayu. Skupuje je autor metreca Sirko Molau - i po przetestowaniu odsprzedaje zainteresowanym prowadzeniem stacji po cenie zakupu. Nie należy więc na własną rękę licytować karty, kiedy taka pojawi się na internetowej aukcji, ponieważ niepotrzebnie podbija się jej cenę, nie ma się pewności czy karta jest sprawna, a także gdyż nie wszystkie karty Matrox współpracują z metrecem - a jest ich wiele typów i łatwo o pomyłkę.
Internet
Nie jest konieczny dostęp do internetu z komputera, na którym zamierzamy uruchomić metreca. Należy jednak rozważyć taką możliwość z dwóch bardzo ważnych powodów. Po pierwsze internet pozwoli na bieżąco korygowac czas komputera do serwera czasu. Jest to bardzo ważne ze względu na jakość generowanych w trakcie obserwacji danych. Po drugie ułatwi znacznie stałe przesyłanie danych - a w przyszłości włączenie w sieć INDRY.
Korekta czasu powinna być zorganizowana w ten sposób, aby uaktualnienie nastepowało częściej, niż interwał przewidziany w Windows. Można to uzyskać jakimkolwiek darmowym klientem czasu. Serwer należy wybrać blisko położony. Niewspierany już klient nettime (ale do wersji 2.0) umożliwia pobieranie czasu z kilku serwerów, niwelując w ten sposób lagi sieci. Czas w komputerze najlepiej ustawić na UTC (GMT) oraz wyłączyć automatyczną zmianę czasu na letni. W każdym wypadku należy wpisać właściwą różnicę czasu strefowego względem UTC w pliku metrec.cfg (w wypadku, jeśli zegar ustawimy na UTC - poprawka będzie równa zero).
Komputer
Nie ma szczególnych wymagań co wydajności komputera. W wersji dosowej (nie pod XP) program potrzebuje do wygodnej pracy procesora Pentium II 500 MHz, pół GB pamieci RAM i 1 GB pamięci na karcie grafiki. Pod XP można założyć, że jeśli sam system operacyjny będzie funkcjonował prawidłowo, bez spowolnień i zacięć - to metrec da sobie radę. Dysk 20 GB jest wystarczający, o ile nie będzie się na nim przechwowywać zbyt wielu zredukowanych już obserwacji. Można także podłączyć dysk na USB.
Najważniejsze wymagania w stosunku do komputera to procesor Pentium (karty często nie współpracują z płytami AMD) - oraz rozmiar obudowy. Karta jest dość duża i nie zmieści się do obudów typu slim. Karta montowana jest w złącze PCI. Po zamontowaniu wysokość karty od wierzchu złącza PCI do jej brzegu to 10,1 cm, długość karty od złącza w kierunku przeciwnym do tylnej ścianki komputera (czyli w kierunku do jego wnętrza) to 8,2 cm. Wymiary te mieszczą się w standardzie PCI (full-size card), jednak szczególnie długość może sprawiać problemy w kompaktowych obudowach. Wymiary zostały zdjęte z rzeczywistej karty, niewykluczone, że moga one być nieco inne dla innego typu, należy więc zapewnić pewien margines.
Rys. 1 - Wymiary karty Matrox Meteor II Multi-Channel po zamontowaniu
Wkładając kartę do obudowy należy zachować podstawowe zasady ostrożności - odłączyć kabel zasilający i dotknąć czegoś dobrze uziemionego aby pozbyć się elektryczności statycznej. Jeśli po włożeniu karty i uruchomieniu komputera nie ma monitu o wykryciu nowego sprzętu - to prawdopodobnie mamy pecha i dana konfiguracja sprzętu (płyta, procesor) nie będzie z nią współpracować. Można spróbować przełożyć w inne gniazdo. Jeśli wszystko jest OK należy przed instalacją oprogramowania wgrać sterowniki dołączone do dystrybucji metreca.
Automatyczny start
Jest pożądane, aby stacja włączała się i wyłączała samoczynnie. Najwygodniej, jeśli w BIOSie komputera można ustawić włączanie o określonej godzinie. Jeśli opcji takiej nie ma - możemy skorzystać z zewnętrznego włącznika z programatorem czasowym i gniazdkiem, do którego podłączymy komputer - ale tylko pod warunkiem, że w BIOSie jest opcja "uruchom ponownie komputer po przywróceniu zasilnia" (np. resume after power failure). Wówczas komputer uruchomi się, kiedy po okresie bez zasilania zegar (programator) włączy napięcie. Jeśli żadnej z tych opcji nie ma - to trudne będzie automatyczne uruchamianie maszyny. Można jedynie wówczas maszyny w ogóle nie wyłączać (a skonfigurować plik cfg by restartował samego metreca wraz z początkiem nowej obserwacji).
Aby po włączeniu się komputera uruchomił się metrec najprościej stworzyć w katalogu głównym programu metrec (patrz struktura katalogów) plik batch. Plik jest plikiem tekstowym, który nazywamy np. start, a rozszerzenie zmieniamy na .bat . Mamy więc plik start.bat , w który wpisujemy dwie linie:
metrec metrec.cfg log.log
shutdown -f -s -t 900 -d p
Pierwsza linia uruchomi metreca (zakładając, że plik konfiguracyjny metreca nazwiemy metrec.cfg i chcemy, aby plik wynikowy nazywał się log.log - patrz konfiguracja metreca). Druga linia, po wyłączeniu się metreca, (co należy ustawić w pliku metrec.cfg - patrz konfiguracja) po czasie 900 sekund wyłączy komputer. 900 sekund (15 minut) jest po to, aby zapisały się wszystkie pliki a INDRA wysłała dane - można ten czas skrócić stosownie do potrzeb. Jeśli komputer włączany jest zewnętrznym programatorem czasowym to czas wyłączenia na programatorze należy ustawić tak, aby z pewnością nastąpiło ono już po zamknięciu się komputera komendą shutdown (np. na 9-tą rano, kiedy metrec na pewno już się wyłączy). Programator musi wyłączyć zasilanie aby komputer mógł uruchomić się samoczynnie po ponownym podaniu napięcia.
Aby plik start.bat zadziałał tworzymy z niego skrót w autostarcie Windows (start/wszystkie programy/autostart). Utworzony plik należy edytować (prawoklik i właściwości) i upewnić się, czy jako element docelowy wpisany jest plik start.bat wraz ze ścieżką (tzn. jeśli plik start.bat jest w katalogu c:\metrec to wpis powinien wyglądać tak: c:\metrec\start.bat). Od tej chwili każde włączenie komputera spowoduje również uruchomienie metreca (a po jego wyłączeniu - wyłączenie komputera itd.).
Uwaga praktyczna - jeśli proces shutdown zacznie odliczanie - sekwencję można przerwać wpisując w linię poleceń:
shutdown /a [Enter]
Nie ma potrzeby wyłączania zasilania kamery i obudowy - te podzespoły najlepiej jeśli są stale "pod prądem" - wówczas najmniej się zużywają i psują.
Kamera.
Kamera telewizji przemysłowej (cctv) jest "instrumentem pokładowym" stacji. Metrec współpracuje z każdą kamerą PAL bądź NTSC. Powinna to być kamera czarno-biała, z matrycą 1/3", mocowanie obiektywu C/CS, w systemie PAL. Koniem pociągowym sieci PFN jest Tayama C3102-01A1. Jest to tania (nieprodukowana - dostępna np. na allegro) kamera, która po teście okazała się przydatna do naszych celów. Kupując inną kamerę najlepiej się poradzić, gdyż nasze wymagania są specyficzne. Wybierając kamerę trzeba zwrócić uwagę na zasilanie - może to być napięcie stałe 12 lub 24 V lub zmienne 24 czy 230 V. Ze względów bezpieczeństwa lepiej wybrać model zasilany napięciem do 24 V.
Obiektyw
Wymagania w stosunku do "oka" kamery są proste: obiektyw powinien być światłosilny i mieć ogniskową 4-8 mm. Dobrze też jeśli nie zniekształca pola widzenia (brak dystorsji) - z tym lepiej sobie radzą obiektywy ze stałą ogniskową. Na rynku jest mało obiektywów spełniających pierwszy warunek (światłosilnych). Najbardziej pożądane szkła mają otwór względny F 1,0 a nawet F 0,75 - jest ich jednak niewiele na rynku. Absolutne minimum wymagań w tym wypadku to F 1,2. Obiektyw może być w pełni manualny (ostrość i przysłona) bądź mieć przysłonę automatyczną (AI - auto iris). Na początek można nabyć łatwo dostępny obiektyw auto iris D/N TAV308DC SIRIUS produkcji SPACECOM - zoom o ogniskowej 3-8 mm, z przysłoną F 0,95.
Obudowa.
Kamera z obiektywem będzie stale narażona na wpływ czynników zewnętrznych - w związku z czym musi być zamontowana w standardowej obudowie zewnętrznej z grzałką. Należy wybrać obudowę z górną pokrywą odchylaną na bok - inne rozwiązania poważnie utrudniają manipulacje przy kamerze. Obudowa wymaga zasilania (zawiera grzałkę odraszającą szybkę). Występują obudowy - podobnie jak kamery - na napięcie 12, 24 i 230 V. Ze względów bezpieczeństwa należy wybrać napięcie do 24 V. Warto także doprowadzić do tego, abyśmy mieli cały sprzęt pracujący pod takim samym napięciem - znacznie uprości to zasilenie stacji.
Montaż zestawu.
Zanim wyjdziemy na dach czy balkon trzeba sobie dobrze uświadomić, że najważniejsze jest nasze bezpieczeństwo, tak w czasie montażu jak i później w trakcie obsługi. Temu warunkowi trzeba podporządkować myślenie.
Przed mechanicznym montażem kamery należy wykonaż obrazek dark.
Przed montażem dobrze jest sprawdzić, czy standardowa stopka obudowy umożliwia montaż kamery zwróconej ku górze - zwykle kamery cctv patrzą w dół i bardzo często trzeba dorobić jakiś pośredni element, aby umożliwić skierowanie jej w niebo.
Wybór miejsca na montaż kamery powinien uwzględniać kilka czynników. Najistotniejsza jest oczywiście widoczność w pożądanym kierunku. Pole widzenia powinno być czyste, niedobrze jeśli blisko przed kamerą znajduje się komin (nawet wentylacyjny). Po drugie - oczywiście - musimy mieć stały i BEZPIECZNY dostęp do kamery, nie raz i nie dwa trzeba będzie coś poprawić, niekoniecznie akurat będzie lato. Po trzecie bardzo ważne jest stabilne zamocowanie do konstrukcji. Odpada montaż do drewnianych elementów dachu czy do jego pokrycia. Preferowany jest montaż do elementów murowanych czy żelbetowych, w ostateczności stalowych. Raczej, o ile to możliwe - nie do kominów. Wiąże się to z kwestią stabilności kamery w długich okresach czasu, kiedy da znać o sobie rozszerzalność cieplna. Nie należy żałować wielkości i długości śrub mocujących stopkę obudowy, warto także kupić specjalne śruby (kotwy) do muru czy betonu - zwykłe kołki są zbyt miękkie i kamera dość szybko opada. Czwarta sprawa to oczywiście możliwość podciągnięcia do miejsca montażu kamery zasilania i kabla sygnałowego.
Dodatki i gadżety.
Musimy zapewnić sobie zasilacz, kable (sygnałowy i zasilania). Kabel sygnałowy (tzw. koncentryk, czy też antenowy) 75 Ohm powinien być dobrej jakości, miedziany - zarówno "gorąca żyła" jak i oplotka. Potrzebnych jest też kilka wtyków (BNC lub cinch). Karty MC (Multi-Channel) wymagają specjalnej, rzadko stosowanej wtyczki D-Sub 44 (44 piny), podobnej nieco do Centronicsa (LPT). Do wygodnych gadżetów można zaliczyć miniaturowy odbiornik tv, który podłączymy bezpośrednio do kamery, dzięki czemu będziemy mogli ustawić ostrość nie kursując między kamerą na dachu a komputerem w mieszkaniu.
Instalacja pakietu.
Instalacja pakietu polega na rozpakowaniu ściągniętego ze strony http://www.metrec.org/download/ pliku do założonego w tym celu folderu. Nadając nazwy folderom oraz planując ich rozmieszczenie na dyskach należy mieć na względzie, że metrec pracuje w oknie dosowym, obsługiwanym z klawiatury i wymaga nieraz wprowadzenia pełnej ścieżki dostępu do pliku, stąd najlepiej kiedy nazwy są krótkie i proste, nie zawierają spacji czy polskich znaków, a foldery nie są pozagnieżdżane w łańcuchu podfolderów na peryferiach dysku twardego - tylko znajdują się zaraz za literą dysku.
Struktura katalogów.
Struktura katalogów pakietu metrec jest bardzo prosta. Katalog, w którym umieścimy pliki programu po rozpakowaniu to - jak dalej będę go nazywał - katalog GŁÓWNY programu. Na przykład c:\metrec. Natomiast poszczególne obserwacje (całe noce - od włączenia do zamknięcia programu danej nocy) będą lokowane w podkatalogach zwanych dalej DZIENNYMI, będą one tworzone automatycznie przez metreca i będą nazwane datą w której rozpoczęto obserwację (w formacie yyyymmdd - year_month_day - tzn. podkatalog dzienny z obserwacji rozpoczętej 20 grudnia 2013 roku bedzie miał nazwę 20131220 - mimo, że obserwacja zakończy się już 21 grudnia). Podkatalogi te będą tworzone w katalogu DANYCH. Katalog DANYCH (domyślnie nazwany data) jest podkatalogiem katalogu GŁÓWNEGO (czyli wg naszego przykładu c:\metrec\data). Wobec tego położenie podkatalogu dziennego będzie takie: c:\metrec\data\yyyymmdd . Możemy jednak dowolnie zmieniać lokalizację i nazwę katalogu danych (data) - poprzez zmianę odpowiedniej linii w pliku konfigurującym metreca (opisane dalej, w pliku konfiguracyjnym).
Pliki.
Podstawowym plikiem generowanym z obserwacji jest plik .log, zawierający informację o wszystkich działaniach programu od jego uruchomienia aż do zakończenia danej sesji. Plik ten zapisywany jest w katalogu głównym jako kolejno log.log, log.001, log.002... itd. Jeśli dana sesja trwa, aktualnym plikiem jest zawsze plik log.log. Po rozpoczęciu następnej sesji metreca nazwa poprzedniego pliku log.log jest zmieniana na kolejną po ostatniej istniejącej (log.000, log.001, log.002... itd.) Są to pliki, z którymi należy uruchamiać postproca w celu redukcji danych (według założeń Sirko Molau).
Tutaj mała dygresja - w katalogu dziennym obserwacji znajduje się kopia pliku log.log z danej obserwacji, z której można korzystać przy redukcji o ile nie zamierzamy przesyłać danych do IMO. Jest to dobry sposób, ponieważ wywołując plik log z katalogu, którego nazwą jest data obserwacji trudno się pomylić, a także dlatego, że pliki log.log, log.000, log.001... itd. pozostają katalogu głównym i stanowią kopię zapasową. Jeśli natomiast zamierzamy wysyłać dane do IMO - musimy podporządkować się zasadom ustalonym przez Sirko Molau - przy redukcji korzystać z plików z katalogu głównego programu. Pliki w katalogu głównym o nazwach log.000, log.001. log.002 itd. są niestety anonimowe (ich nazwa nie mówi, której nocy zostały wygenerowane) a w dodatku "znikają" po przeprowadzeniu redukcji - ich nazwy w związku z tym nie są unikatowe. Łatwo o pomyłki, szczególnie jeśli redukuje się kilka nocy. Ponadto każde "ręczne" uruchomienie metreca poza harmonogramem obserwacji generuje dodatkowe, śmieciowe logi, trafiające do katalogu głównego i pogłębiające chaos.
Z drugiej strony łatwiej jest wywoływać pliki do redukcji z katalogu głównego programu (nie trzeba "skakać" po folderach dziennych obserwacji) - a jest to wręcz konieczne, jeśli przesyłamy dane do IMO. Można sprawić, aby automatycznie uruchamiający się metrec (za pomocą wyżej opisanego skrótu w autostarcie) zapisywał logi w katalogu głównym programu w formacie yyyymmdd.log . W tym celu należy edytować plik start.bat i zmienić pierwszą linię:
metrec metrec.cfg %date:~0,4%%date:~5,2%%date:~8,2%.log
Żeby sposób poprawnie zadziałał sposób kodowania daty musi być dostosowany do tego, jakim posługuje się komputer. Sprawdzamy to wpisując w oknie dosowym komende:
echo %date% [Enter]
Jeśli w wyniku otrzymamy yyyy-mm-dd to powyższą linię można zastosować bez modyfikacji. W innym wypadku trzeba ją zmienić. Linia pobiera cyfry do nazwy pliku z daty systemowej wg następującego schematu: pierwsze dwie liczby rozdzielone przecinkiem kodują rok, drugie miesiąc, trzecie dzień. Liczba przed przecinkiem oznacza pozycję (miejsce), od którego z daty systemowej pobierane będą cyfry, liczba po przecinku oznacza liczbę pobieranych cyfr. Miejsce oznaczone jako zero znajduje się "przed datą". Widoczne w linii liczby 0,4;5,2 i 8,2 oznaczają, że z daty w formacie yyyy-mm-dd pobrane zostaną 4 cyfry po pozycji 0 (yyyy), 2 cyfry po pozycji 5 i 2 cyfry po pozycji 8.
_0|_1|_2|_3|_4|_5|_6|_7|_8|_9|10 (pozycja pobieranych cyfr)
____y__y__y__y__-__m__m__-__d__d (data w danym formacie
____0,4_________5,2______8,2 (kod pobierania - od miejsca zero 4 cyfry itd.)
yyyymmdd - wynikowa linia w nazwie generowanego pliku
Uwaga: jeśli kolejny raz uruchomimy metreca tego samego dnia nazwa poprzedniego pliku yyyymmdd.log zostanie zamieniona na yyyymmdd.000, yyyymmdd001 itd.
Pozostałe pliki generowane z obserwacji umieszczane są w katalogu dziennym. Każde zjawisko ma plik .bmp będący obrazem sumy (nazwa hhmmss.bmp - godzina, minuta, sekunda), pliki .bmp poszczególnych klatek (hhmmssnn.bmp, gdzie nn to numer kolejny klatki), oraz pliki hhmmss.inf i hhmmss.bnd. Pozostałe pliki w katalogu nie dotyczą pojedynczych zjawisk lecz zawierają dane zbiorcze.
Praca w okienku dosowym.
Celem niniejszego akapitu nie jest wgłębianie się w mroczną otchłań MS DISK OPERATING SYSTEM (włącznie z zagadnieniem, czy czarne okienko w XP to rzeczywiście dos a jeśli nie - to co właściwie) a tylko kilka porad dla osób, które z tym tematem stykają się po raz pierwszy. Dlatego też nie podaję tu zbyt wielu rozmaitych "sztuczek" umożliwiających w dosie zrobienie tego czy owego szybciej i na skróty - kto będzie zmuszony, ten sam się wciągnie. W internecie jest mnóstwo materiału na ten temat.
Aby wywołać którykolwiek z modułów metreca po pierwsze należy uruchomić owo okno dosowe - "czarne okienko" - czyli otworzyć linię poleceń. Kryje się ona pod przyciskiem START/AKCESORIA pod nazwą WIERSZ_POLECENIA (albo szybciej: START/URUCHOM i z klawiatury cmd [ENTER]). Po uruchomieniu widzimy mniej więcej to, co szczęśliwy posiadacz komputera w końcu lat 80-tych – wspaniały czarny ekran, na którym miga kursor, poprzedzony literą dysku i ścieżką do folderu, w którym obecnie się znajdujemy. Teraz należy skorzystać z rad odnośnie prostoty położenia oraz nazwy katalogu, do którego wgraliśmy pakiet. Załóżmy, że ów katalog jest na dysku c: w katalogu root (nie jest podfolderem żadnego katalogu) i nadaliśmy mu nazwę metrec. Dos nie rozpoznaje wielkości liter. Wpisujemy:
c: [ENTER] aby zmienić dysk (z innego) na c:
cd\ [ENTER] jeśli jesteśmy w złym miejscu dysku c: - przejdziemy do katalogu root na c:,
cd metrec [ENTER]aby dojść do katalogu metrec,
cd metrec\data [ENTER]aby dojść do podkatalogu data katalogu metrec,
Lub po kolei cd metrec [ENTER], cd data [ENTER]
Jeszcze szybciej i wygodniej można korzystać z okna dos jeśli z elementu menu "wiersz polecenia" - przeciągając go prawym klawiszem myszy na pulpit - utworzymy skrót, następnie go edytujemy (prawy klawisz myszy - właściwości) i w polu "rozpocznij w:" wpiszemy ścieżkę do katalogu głównego programu (wg naszego przykładu c:\metrec). Wówczas po dwukrotnym kliknięciu w skrót otworzy się okno dosowe od razu w podanym katalogu.
Aby wywołać jakikolwiek program w czarnym okienku, polecenie musi być wydane z katalogu, w którym znajduje się wywoływany program. Jeżeli program grab.exe znajduje się w katalogu c:\metrec - to aby wywołać program musimy być w katalogu c:\metrec - to znaczy, że w oknie dos, przed migającym kursorem, widoczna jest ścieżka c:\metrec:
c:\metrec>_
Wówczas możemy z klawiatury wpisać grab i zatwierdzić enterem:
c:\metrec>grab [ENTER]
Z ułatwień można polecić klawisz F3 powodujący wpisanie w linni poleceń ostatniej komendy (którą można edytować), a jeśli trzeba sięgnąć głębiej - strzałki góra-dół (zostaną wyświetlone jeszcze wcześniejsze/późniejsze polecenia).
Generalnie wywołanie każdego z modułów metreca bez wymaganych parametrów - lub z błędnymi parametrami - skutkuje wyświetleniem podpowiedzi w postaci wszystkich możliwych parametrów i ich składni. Przykładowo wywołany w ten sposób jak wyżej moduł grab wyświetli taki wynik:
Rys. 2 - Efekt uruchomienia grab.exe bez wymaganych parametrów POWIĘKSZ
Parametry konieczne wyświetlane są w klamrach, znak łamania oznacza, że można wprowadzić tylko jedną wartość danego parametru, w nawiasach kwadratowych są parametry opcjonalne. Parametry powinny być wpisane po nazwie wywoływanego programu, oddzielone spacjami. Parametr zaczyna się zawsze znakiem - (minus).
Dark - jałowy sygnał kamery
Poniższe dwa rozdziały należy sobie dobrze przyswoić. Samo wykonanie obrazków dark i referencyjnego trwa kilka minut i zdaje się banalne, jednak podczas tej prostej czynności ustalane są automatycznie parametry, istotne później, podczas pracy metreca. W zasadzie nie ma możliwości poprawy tych parametrów ręcznie, bez straty dla jakości generowanych danych. Jedynym wyjściem jest więc powtórne użycie modułu grab. Z kolei aby poprawnie wykonać obrazek dark, trzeba już wiedzieć, jakie parametry b i c (brightness i contrast) będą właściwe dla naszego typu kamery i zaświetlenia nieba przy wykonywaniu obrazka referencyjnego. Tym samym konieczne jest pewne doświadczenie - lub należy wykonać wiele obrazków (np. 5 - 10) na różniących się ustawieniach, aby mieć z czego wybrać.
Każda kamera, nawet w absolutnej ciemności, generuje unikatowy obraz, na który składają się defekty i szumy własne matrycy oraz elektroniki. Obraz taki można zapisać, a następnie odejmować go w procesie obróbki od klatek wideo, aby zminimalizować wpływ wad kamery na pracę programu. Zabieg ten nie jest istotny, jeśli nie wysyłamy danych do IMO (nie wpływa na wykrywanie meteorów jako takie). Natomiast jeśli wysyłamy dane do IMO użycie darka jest istotne, gdyż poprawia obliczanie jasności gwiazd.
Aby wykonać darka, przed ostatecznym zamocowaniem kamery należy zakryć obiektyw nasadką a całą kamerę dla pewności okryć dokładnie ciemną tkaniną. Do kamery nie powinno przedostawać się żadne światło (włączając obecną niekiedy z tyłu obudowy diodę). Uzyskamy w ten sposób mapę hotpixeli oraz "nierówności" samej matrycy. Możliwość wykorzystania darka do optymalizacji pracy kamery występuje od wersji 5.1 - tym niemniej dobrze jest taki obrazek wykonać i zachować nawet mając instalację metreca 5.0 - dzięki temu przy przejściu na wyższą wersję unikniemy zruszenia kamery.
Aby Wykonac darka należy się upewnić, że kamera generuje obraz (okno podglądu nie jest absolutnie czarne). Wpisujemy w kinię poleceń:
c:\metrec> grab -2 -pal -full dark.bmp
Po ukazaniu się okna graba ustawiamy wartości b i c jak dla obrazka referencyjnego, wciskamy klawisz i aby uzyskać maksymalna integracje klatek (64) po czym przyciskamy enter, co zapisuje obrazek i spowoduje wyjście z modułu grab. Opcje -2 i -pal omówione zostaną niżej, przy wykonaniu darka istotna jest opcja -full, której używamy, jeśli w pliku konfiguracyjnym metreca ustawimy rozdzielczość na max. Obraz dark powinien mieć rozdzielczość identyczną z tą, w której ma pracować metrec. Dla starych metrecowców jest to bardzo mylące - dotychczas opcja full - ale w pliku cfg metreca, jako wartość zmiennej InternalResolution - oznaczała pracę z połową rozdzielczości - zaś w grabie od wersji 5.0 występuje ona jako oznaczenie rozdzielczości pełnej - Sirko ma to usunąć w następnej wersji. Tak więc z opcji -full w grabie nie korzystamy - poza wykonaniem darka, który powinien być wykonany w rozdzielczości takiej, w jakiej pracuje metrec*. Obecnie na większości stacji metrec pracuje w rozdzielczości pełnej, oznaczonej w configu jako max - czyli 768x576. Taką rozdzielczość należy wybrać o ile tylko komputer na nią pozwala.
*Nie jest to ścisłe określenie. W rzeczywistości metrec pracuje zawsze na połowie rozdzielczości (to jest 384x288) - ale jeśli zmienna InternalResolution jest ustawiona w pliku metrec.cfg na max - pliki wynikowe (obrazki sumy jak i pojedyncze klatki) zapisywane będą w rozdzielczości pełnej 768x576.
Reasumując: obrazek dark wykonujemy w takiej rozdzielczości, w jakiej pracować będzie metrec (takiej, jaką ustalimy w pliku cfg metreca) - czyli najpewniej 768x576 - max - i w tym celu wywołując moduł grab używamy w poleceniu opcji -full. Drugą istotną sprawą, jest wykonanie darka z takimi samymi ustawieniami b i c (brightness i cotrast) jak dla obrazka referencyjnego, który wykorzystamy następnie w module refstars dla klakulacji siatki współrzędnych. Aby prawidłowo wykonać darka należy się zaznajomić z poniższym rozdziałem poświęconym obrazkowi referencyjnemu.
Obraz referencyjny.
Przed przystąpieniem do obserwacji musimy metrecowi pokazać, gdzie są gwiazdy. W tym celu należy stworzyć obrazek, a jeszcze lepiej kilka obrazków referencyjnych, do czego służy moduł grab (dla porządku nadmieniam, że kiedy zabieramy się za tę robotę muszą być widoczne gwiazdy). Przed wykonaniem obrazka referencyjnego należy zakończyć wszelkie prace przy kamerze. Powinna ona być już na stałe, trwale i pewnie zamocowana, mieć dobrze ustawioną ostrość i nie powinno się jej już więcej dotykać (otwierać obudowy a tym bardziej robić cokolwiek przy samej kamerze). Kierunek, w którym patrzy kamera powinien być uzgodniony z PFN.
UWAGA! Przypominam, nie należy korzystać z opcji -full (poza, ewentualnie, wykonaniem darka j.w.), bo otrzymamy obrazek w pełnej rozdzielczości, którego nie przyjmie później moduł refstars. Natomiast opcja -ts 2 pozwala wkopiować w obrazek datę i czas jego zapisania (bardzo wygodne później). Obrazki nieba (na potrzeby modułu refstars) wykonujemy zawsze w połowie rozdzielczości (384x288) - i NIE korzystamy wtedy z opcji -full.
Aby wywołać moduł grab trzeba ustalić, jaki rodzaj karty Matrox mamy zainstalowany (Meteor I lub II - opcja -1 lub -2) oraz w jakim systemie działa kamera (PAL lub NTSC - opcja -pal lub -ntsc). Wiedząc to (załóżmy, że Matrox II i PAL) wpisujemy w linię komend:
c:\metrec> grab -2 -pal -mean -ts 2 plik.bmp
gdzie plik.bmp to nazwa, jaką chcemy nadać plikowi wynikowemu, zakończona rozszerzeniem .bmp. Opcja -mean uśrednia obrazy. Jeśli nie pomyliliśmy niczego (dos nie wybaczy nawet jednej literki) a hardware jest prawidłowo połączone zobaczymy obraz z kamery. Powinniśmy widzieć gwiazdy - jeśli widać je gołym okiem za oknem a nie widać ich na obrazie z kamery, to prawdopodobnie źle ustawiona jest ostrość (mowa oczywiście o sytuacji, kiedy mimo, że nie widać gwiazd z całą pewnością kamera jest sprawna - generuje realny, choć nieostry obraz świata zewnętrznego). W takiej sytuacji najpierw trzeba się przeprosić z drabiną i poprawić ostrość. Kiedy wszystko już jest OK i widać gwiazdy, można przejść do wykonania obrazków.
Rys. 3 - Okno grab.exe POWIĘKSZ
Poniżej okienka z obrazem z kamery dostępne będą opcje, z których interesują nas:
- Bright. [b/B] - 128 (jasność, domyślna wartość 128 w przedziale 0-255)
- Contr. [c/C] - 128 (kontrast, zakres j.w.)
- Integr. [i/I] - 1 frame (integracja klatek, zakres 1-64, domyślnie 1)
- Histogram [h/H] - no (histogram, czyli jak wykorzystana jest matryca kamery, domyślnie no)
Wciskanie klawisza “małego i dużego” (to jest bez lub z shiftem) powoduje zwiększanie bądź zmniejszanie danej wartości. Po pierwsze korzystamy z klawisza i aż pokaże się wartość 64 - oznacza to, że obraz, który widzimy składa się z zsumowanych 64 klatek. W ten sposób pozbędziemy się szumu. Następnie można manipulować ustawieniami jasności i kontrastu w celu optymalizacji obrazu - wymaga to jednak wyczucia. Nie należy przesadzać ustawiając wartości na maksymalne. Należy podbić jasność, aż (w późnych godzinach nocnych, przy czystym powietrzu, bez chmur, mgły i bez Księżyca) kolor nieba nie będzie czarny a ciemnoszary (niewiele jaśniejszy od czerni). Następnie można delikatnie podbić kontrast, co powinno spowodować poczernienie nieba a wydobycie gwiazd. Na ogół wartość kontrastu powinna być nieco większa, bądź równa wartości jasności. Osoby wiedzące co widać na histogramie mogą się nim posiłkować. Generalnie wartości b i c powinny być ustawione powyżej wartości średnich (domyślnych - 128). Sam autor oprogramowania zaleca ustawienie kontrastu na maksimum a jasności w taki sposób, aby tło było lekko szare a nie całkiem czarne. Należy jednak mieć na uwadze, że dotyczy to nieco innych kamer niż nasze tayamy.
Kiedy uznamy, że wszystko jest dobrze wciskamy [ENTER] i obrazek referencyjny zostanie zapisany pod podaną wcześniej nazwą w głównym katalogu programu. Takich obrazków dobrze zapisać jest kilka - w ciągu jednej lub kilku nocy (w sumie 3-5, oczywiście pod różnymi nazwami, grab nadpisze plik nie pytając o zgodę jeśli podamy taką samą nazwę pliku wynikowego). Na tym rola modułu grab się kończy.
Najlepszą metodą jest wykonanie "hurtowo" kilku obrazków z ustawieniami brightness i contrast różniącymi się o interwał np. 10 począwszy od 140 - szczególnie za pierwszym razem ocena, czy dobraliśmy optymalne wartości może być trudna. Pliki wynikowe należy nazwać tak, aby z nazwy wiadomo było, jakie wartości w danym pliku zostały ustawione (np. g150170.bmp dla wartości b/c 150/170). Jeśli nazajutrz okaże się, że wartości są dobrane źle (np. obraz z kamery jest za ciemny) - nie będziemy musieli ponownie "grabić" a wykorzystamy gotowy obrazek z innymi ustawieniami. Dla każdego obrazka z innymi ustawieniami b i c wykonujemy z identycznymi ustawieniami darka.
Jest też inna, sprytna metoda, na określenie prawidłowych wartości b i c, chociaż przypomina problem "paragrafu 22". Wymaga ona uruchomienia modułu metrec. Podczas jego pracy możemy zawiesić tymczasowo wykrywanie meteorów (ctrl-u) a następnie klawiszami b/B i c/C manipulować jasnością i kontrastem obrazka. Wykrywanie przywracamy sekwencją klawiszy ctrl-r. Metodą prób i błędów można ustalić właściwe wartości b i c - a następnie użyć ich przy wykonywaniu obrazków referencyjnego i darka.
Należy tu wyraźnie odróżnić wykonywanie kilku obrazków referencyjnych po to, aby do mierzenia gwiazd wykorzystać je wszystkie, zwielokrotniając dokładność, od wykonywania kliku obrazków po to, by utrafić we właściwe wartości b i c. W pierwszym przypadku obrazki powinny być wykonywane co np. godzinę lub w różne dni o różnych porach, chodzi o to, aby znalazło się na nich jak najwięcej różnych gwiazd. W drugim wypadku chodzi o dobranie właściwych wartości b i c, można je więc wykonywać "hurtowo".
Plik refstars.osc - ustalenie współrzędnych stacji
Przed użyciem modułu refstars należy dopisać swoją stację do znajdującego się w katalogu programu pliku refstars.osc. Plik ten należy wypełnić bezbłędnie. Informacja pobierana z tego pliku wpływa bezpośrednio na jakość obserwacji a także - szczególnie - na dane wysyłane do IMO. Zawiera on współrzędne i wysokość nad poziomem morza stacji - wiele z nich jest w nim wpisana domyślnie - ale raczej nie dotyczy to naszych kamer. Jeśli naszej stacji nie ma to plik należy edytować wpisując własne dane. Prawidłowe określenie współrzędnych geograficznych oraz wysokości nad poziomem morza jest bardzo istotne dla jakości danych generowanych następnie przez program w czasie obserwacji. Należy zwrócić uwagę na format danych - współrzędne geograficzne często są zapisywane w mierze kątowej (stopnie, minuty, sekundy) - i wówczas trzeba je przeliczyć na zapis dziesiętny (stopień i po kropce dziesiętny ułamek stopnia). Współrzędne geograficzne można odczytać z portalu Geoportal - tam też można w przybliżeniu (ze skanów map) odczytać wysokość nad poziomem morza. Bardzo dobrą wysokość nad poziomem morza można uzyskać z mapy zasadniczej z zasobów lokalnego ośrodka geodezji. Normalnie zakup takiej mapy to kilkadziesiąt złotych ale w większości wypadków można takie dane uzyskać “po prośbie” za darmo. UWAGA - geodeci chętnie podzielą się także współrzędnymi ale są to współrzędne w układzie odniesienia “Układ 2000”. Nie są one tożsame ze współrzędnymi geograficznymi ani też nie są na nie łatwo przeliczalne we własnym zakresie (choć można poprosić o to samych geodetów). Inną metodą jest skorzystanie z urządzenia GPS. Współrzędne geograficzne powinny być podane w formacie dziesiętnym (tzn. 50o 30’ należy podać jako 50.5o). Dane powinny być zapisane w jednej linii (resztę wpisów dotyczących innych stacji można usunąć), oddzielone spacjami, w kolejności:
place longitude latitude altitude sitecode
czyli:
miejsce_obs. długość_geogr. szerokość_geogr. wysokość_n.p.m. kod_stacji
Poszczególne wartości nie mogą zawierać spacji ani polskich liter. Jako znak oddzielający jedności od dziesiątych musi być kropka. Wartość długości geograficznej należy podać z minusem dla zachodnich, z plusem dla wschodnich, podobnie dla szerokości plus oznacza północną a minus południową. Wysokość n.p.m. musi być liczbą całkowitą. Kod stacji można otrzymać od Sirko ale nie ma on żadnego znaczenia dopóki nie zdecydujemy się przesyłać danych do IMO. Linie dotyczące innych stacji można wykasować.
Maska.
Maska służy do zasłonięcia przeszkód w polu widzenia, w szczególności takich, które mogą generować fałszywe detekcje. Jest to plik .bmp z kamery (oczywiście wykonany po jej zamocowaniu na stałe), na którym zaznaczyliśmy na czarno obszary niepodlegające wykrywaniu meteorów - czyli miejsca, w których pole widzenia jest zasłonięte przeszkodami - takimi jak horyzont, budynki, drzewa, pojawiające się stale w jednym miejscu odblaski czy obudowa obiektywu. Maska musi być plikiem jednobitowym bmp (bitmapą czarno-białą - nie w skali szarości) w połowie rozdzielczości 384x288 pixeli - najprościej adaptować w tym celu obrazek referencyjny. Na masce obszary białe oznaczają miejsca, gdzie meteory będą wykrywane, natomiast czarne te, gdzie metrec będzie “ślepy”. Maskę można zrobić z dowolnego pliku z danej kamery, dostosowując rozdzielczość i dokonując progowej konwersji do b/w a szczegóły poprawiając ręcznie. Metoda nie jest istotna - ważne jest aby obrazek miał wyżej wymienione parametry. Prawidłowo wykonana maska nie zawęża pola widzenia i nie zmniejsza zdolności wykrywania meteorów - natomiast zapobiega zapychaniu dysku oraz zaoszczędza dużo czasu przy redukcji danych. Właściwe zamaskowanie przeszkód widzenia jest niezbędne, jeśli zamierzamy przesyłać dane do IMO - na podstawie maski kalkulowane jest rzeczywiste pole widzenia kamery.
Refstars - wskazanie metrecowi gwiazd.
Następnym krokiem jest rozpoznanie gwiazd na wykonanych obrazkach referencyjnych. Podczas tego procesu zostaną skojarzone informacje o lokalizacji stacji oraz położeniu widocznych gwiazd w określonej chwili - dzięki czemu w każdym momencie metrec będzie wiedział, na jaki wycinek nieba aktualnie patrzy kamera. Refstars od wersji 5.0 umożliwia wczytanie więcej niż jednego obrazka referencyjnego. Ponadto od tej wersji pakietu metrec zapisuje pozycje wykrytych gwiazd do pliku yyyymmdd.ref w katalogu dziennym, który po łatwej optymalizacji można i należy wykorzystywać przy detekcji.
Najważniejszy jest pierwszy z obrazków wczytywanych do refstarsa, gdyż moduł grab koduje w nagłówku pliku wynikowego .bmp ustawione przez nas wartości brightness i contrast (jasności i kontrastu) a do modułu refstars są one wczytywane właśnie z pierwszego obrazka w kolejce. Możliwe są różne “sztuczki” pozwalające użyć jako obrazków referencyjnych plików powstałych bez użycia modułu grab, ale pierwszy wczytywany obrazek powinien być plikiem wygenerowanym przy optymalnych ustawieniach przez moduł grab o dobrej porze nocy i bezchmurnym (oraz bezksiężycowym) niebie.
Moduł refstars wywołujemy następująco:
refstars [-num n] [1.bmp 2.bmp 3.bmp … n.bmp] [nazwa.ref] [maska.bmp]
gdzie:
n - liczba wczytywanych obrazków (pominąć parametr, jeśli jeden)
1.bmp ... n.bmp - nazwy wczytywanych obrazków referencyjnych
nazwa.ref - nazwa jaką chcemy nadać tworzonemu plikowi .ref
maska.bmp - nazwa pliku .bmp, który jest naszą maską (o ile ją mamy, jeśli nie - pominąć).
Na marginesie: nie ma sensu wczytywać tych obrazków zbyt dużo (linia komend dos ma bodaj 200 znaków). Wg słów Sirko "kilka" będzie OK. Przypominam jedynie, że najważniejszy jest pierwszy, gdyż z niego są pobierane ustawienia jasności i kontrastu. O ile zamierza się optymalizować plik .ref automatycznie zapisany przez metreca po pogodnej nocy - w ogóle wystarczy jeden porządnie wyklikany obrazek. Na obrazku mamy szansę ręcznie wyklikać 30-50 gwiazd, po pogodnej nocy pozycji gwiazd w dziennym pliku .ref będzie kilka-kilkanaście tysięcy. Taka jest przewaga pliku automatycznie zapisanego a nastepnie zoptymalizowanego nad ręcznie wyklikanym.
Jeśli wszystko poszlo OK po wywołaniu refstarsa zobaczymy nieco bardziej skomplikowany od graba interfejs gdzie będziemy musieli dokonać kilku ustawień a następnie ręcznie wskazać programowi gwiazdy widoczne na obrazkach referencyjnych.
Bardzo dobre efekty daje postępowanie iteracyjne. Wczytujemy jeden obrazek grab, wykonujemy refstars jak niżej - po pogodnej nocy sprawdzamy poprzez opcję -update w refstars (patrz optymalizacja plików referencyjnych) czy automatycznie wyszukane gwiazdy pokrywają całe pole widzenia, plik optymalizujemy refstars -update, wpisujemy do loga jako obrazek referencyjny - powtarzając te kroki można małym nakładem wysiłku po 2-3 iteracjach otrzymać bardzo dobry obrazek referencyjny ze średniej jakości obrazka grab wczytanego na początku.
Mamy do dyspozycji 6 okien, po 3 w 2 kolumnach. W pierwszym od lewej i od góry (Input, oznaczone na rysunku jako 1) pojawiają się monity refstarsa - a kiedy przejdziemy do właściwego wykrywania gwiazd znajdzie się tam pomoc (klawiszologia). Następnie mamy okno 2 (Data Screen), w którym widać wprowadzone dane, poniżej okno 3 (Reference Stars), którym będą się pojawiać parametry rozpoznanych gwiazd.
Rys. 4 - Okno refstars.exe zaraz po uruchomieniu POWIĘKSZ
W drugiej kolumnie od góry jest okno 4 lupy powiększającej rozpoznawany fragment pola (Zoom), poniżej, w 5-tym widzimy rozpoznawany obrazek referencyjny (Reference Image - po nim numer obrazka - jeśli wczytaliśmy więcej niż jeden), a na dole 6 - stosowny wycinek mapy nieba (Star Catalog), wg którego będziemy prowadzić rozpoznanie.
Po uruchomieniu refstarsa po pierwsze należy wprowadzić dane stacji. Dane są odczytywane z pliku refstars.osc należy więc za pomocą klawiszy strzałek odnaleźć swoją stację na liście i zatwierdzić enterem. Następnie program pyta, czy nasza kamera jest nieruchomo zamocowana (unguided - u) czy prowadzona (guided - g). Wybieramy opcję u i zatwierdzamy enterem (oczywiście, chyba, że ktoś posiada kamerę prowadzoną). Z kolei należy ustawić współczynnik gamma kamery. Jeśli kamera umożliwia zmianę tego parametru (np. do wartości 0.5 zamiast 1) to w tym miejscu należy podać wartość ustawioną na kamerze (0.5). Następnie program prosi o wprowadzenie daty i czasu - chodzi o datę i czas wykonania obrazka referencyjnego programem grab - tu się bardzo przydaje wkopiowanie tych danych na obrazek (opcja -ts 2 w module grab) - także dlatego, że czas jest wkopiowany w setnych sekundy - co pozwala lepiej zaokrąglić czas do pełnych sekund. Po wprowadzeniu danych zatwierdzamy enterem.
Następnie musimy zdefiniować pole widzenia (center plate). Klawiszami strzałek można przesuwać środek pola widzenia, zaś + i - zmieniać jego średnicę. W naszym wypadku większość kamer daje użyteczny obraz na całej matrycy (tzn. jest on prostokątny) i w takim wypadku nie ruszając położenia środka pola należy klawiszem + powiększyć promień aż okrąg wyjdzie poza narożniki kadru. W wypadku, kiedy użyteczny obraz jest kołem (np. jeśli założymy obiektyw 1/3” do kamery 1/2” i będziemy mieć silne winietowanie) należy oczywiście dopasować wielkość pola widzenia do wielkości użytecznego obrazu. Zatwierdzamy enterem.
Kolejnym zadaniem jest ustawienie progu wykrywania gwiazd (threshold). Musimy ustawić poziom, od którego miejsca jaśniejsze niż tło zostaną uznane za potencjalne gwiazdy. Jest to istotna operacja, wpływająca na kalkulację lm - do dyspozycji mamy klawisze + i - (używanie z shiftem przyspiesza zmiany). W oknie 6 widzimy potencjalne gwiazdy wydobyte z tła obrazka przy aktualnym ustawieniu. Najpierw należy użyć klawisza - (minus) tak, aby liczba widocznych w oknie 6 “gwiazd” była równa lub mniejsza od liczby gwiazd dobrze widocznych w oknie 5 na rzeczywistym obrazku. Następnie klawiszem + powodujemy stopniowe zwiększanie liczby wydobywanych “gwiazd”, w pewnym momencie będzie ich więcej niż tych widocznych na rzeczywistym obrazku, należy jednak kontynuować aż do natrafienia na wyraźny moment, w którym kolejne naciśnięcie + spowoduje masowe pojawienie się “gwiazd” na całym polu. Właściwe ustawienie uzyskamy po jednokrotnym naciśnięciu - (minus) co zatwierdzamy enterem (tzn. ustawiamy wartość podprogową przed owym masowym wysypem).
Kolejne zadanie to odnalezienie na mapie nieba tego fragmentu, który widać na obrazku referencyjnym. Dla osób nieobeznanych jest to najtrudniejszy moment, szczególnie jeśli liczba gwiazd na obrazku referencyjnym jest niewielka. Jeśli ktoś ma małe pojęcie o gwiazdozbiorach to powinien się do tej chwili dobrze przygotować - choćby instalując program typu planetarium (np. Cartes du Ciel). W programie takim można ustawić kierunek patrzenia oraz datę i godzinę i wstępnie rozpoznać, do jakich gwiazdozbiorów należą gwiazdy oraz czego się spodziewać na obrazku referencyjnym. Trzeba mieć na uwadze, że refstrars nie ma w swoich mapach części obiektów (planet, Księżyca, mgławic). Mimo, że mogą się one znaleźć na obrazku referencyjnym to są bezużyteczne i jedynie wprowadzają w błąd. Podobnymi “rozpraszaczami” są także hotpixele - łudząco podobne do gwiazd. Warto wcześniej wykonać darka - hotpixele zostaną na nim dobrze uwidocznione, znajomość ich położenia również zaoszczędzi nam sporo nerwów.
Rys. 5 - Dopasowanie mapy nieba do obrazka referencyjnego POWIĘKSZ
Dopasowanie mapy nieba do obrazka przebiega w oknach 5 (gdzie widzimy obrazek) i 6 (gdzie jest wyświetlana mapa). Klawisze strzałek przesuwają środek pola widzenia, +/- zwiększają/zmniejszają wielkość mapy, b/f wyświetlają jaśniejsze/słabsze gwiazdy, r/l obracają mapę, g wyświetla pomocniczą siatkę, dzięki której łatwiej jest “spasować” obrazki. Shift przyspiesza wszystkie operacje zaś e zmienia układ współrzędnych (mapa będzie inaczej reagowała na wciskane klawisze). Dodatkową pomocą jest możliwość ustawienia punktu, od którego rozpoczynamy poszukiwania na Oriona, Wielką Niedźwiedzicę lub Krzyż Południa (ctrl-o/u/x).
Manipulując strzałkami, +/- i r/l należy odnaleźć na mapie fragment nieba widoczny na obrazku referencyjnym. Następnie należy go możliwie dokładnie dopasować (to znaczy spowodować, aby gwiazdy na obrazku i na mapie były w odpowiadających sobie miejscach kadrów). Tutaj bardzo pomocna jest siatka (g). Dokładne dopasowanie jest istotne, przy czym przede wszystkim należy dopasować gwiazdy na skraju pola (postępując odwrotnie przy szerokokątnym obiektywie możemy spodziewać się dużych niezgodności na krawędzi). Po uzyskaniu zadowalającego wyniku zatwierdzamy go enterem.
W tym momencie rozpoczyna się właściwe wskazywanie gwiazd. W oknie 5 mamy nadal rozpoznawany obrazek referencyjny, w oknie 6 odpowiadający mu wycinek mapy nieba. Na obu znajdują się krzyże celownicze. Małe okno 4 pokazuje powiększony fragment nad którym znajduje się aktualnie krzyż celowniczy na obrazku. Krzyżem na obrazku poruszamy klawiszami strzałek (shift przyspiesza) - krzyż na mapie porusza się adekwatnie jednak nie powtarza dokładnie ruchów a skacze od gwiazdy do gwiazdy. Od wersji 5.1 mamy do dyspozycji filtr górnoprzepustowy (s/S i p/P - promień i stopień) - pozwalający “wyostrzyć obraz” i wyciągnąć nawet najsłabsze gwiazdy z tła. Usprawnione są także krzyże celownicze - obecnie są dwa. Większy kopiuje dokładnie pozycję krzyża z obrazka referencyjnego. Mniejszy wskazuje proponowaną gwiazdę.
Rys. 6 - Rozpoznawanie gwiazd - dla uczytelnienia zaznaczono Lutnię POWIĘKSZ
Refstars proponuje nam wybór gwiazdy - krzyż na obrazku umiejscowia na jasnym punkcie a krzyż na mapie na prawdopodobnie odpowiadającej mu gwieździe. W tym momencie musimy sprawdzić, czy “jasny punkt” to rzeczywiście gwiazda i to ta właściwa - a nie hotpixel, planeta czy też po prostu szum. Dlatego tak ważne było “spasowanie” mapy i obrazka. Jeśli zrobiliśmy to dokładnie, to położenia “jasnego” punktu na obrazku i adekwatnej gwiazdy na mapie będą niemal identyczne (będą w tym samym miejscu kadru). Wystarczy więc porównać, czy krzyże wskazują dokładnie ten sam rejon obrazka - jeśli tak, jest to prawdopodobnie właściwa gwiazda. Od wersji 5.1. dostępna jest nowa opcja f. Po wskazaniu kilku gwiazd, po jej użyciu, mapa zostanie rozciągnięta wg aktualnie skalkulowanej siatki współrzędnych, a więc polepszy się jej dopasowanie do obrazka referencyjnego. Opcji f możemy używać wielokrotnie, po wskazaniu kolejnych gwiazd. Naciskając zaś F możemy przywrócić wyświetlanie mapy bez dopasowania do siatki.
Naciskając +/- zmieniamy wybór gwiazdy na mapie, odpowiadającej danemu “jasnemu punktowi” na obrazku. Jeśli “jasny punkt” to nie gwiazda naciskamy n i refstars proponuje nam następną gwiazdę. Jeśli wyczerpały się podpowiedzi refstarsa możemy sami przesuwć krzyż od jednej do drugiej gwiazdy na obrazku klawiszami strzałek. Zawsze przed zatwierdzeniem sprawdzamy, czy krzyż na obrazku i na mapie mają identyczne położenie.
Teraz korzystając z okna 4, czyli powiększonego fragmentu okolicy w którą celuje krzyż na obrazku, możemy dokładnie wyznaczyć położenie gwiazdy. W tym celu klawiszami e/E regulujemy kontrast aż najlepiej będziemy w stanie ocenić, gdzie znajduje się środek jasnego pola (czyli gwiazda). Następnie klawiszami strzałek naprowadzamy krzyż na to miejsce - można sobie pomóc klawiszem g, wyłączającym krzyż. Po ustaleniu pozycji zatwierdzamy gwiazdę enterem. Gwiazdy, które już wybraliśmy oznaczane są czarnym krzyżykiem.
Po każdym zatwierdzeniu enterem gwiazda zostaje dopisana do listy rozpoznanych w oknie 3. Jeśli przy zatwierdzeniu rozlegnie się dźwięk - znaczy to, że położenie wskazanej gwiazdy znacznie różni się od przewidywanego. Dźwięk ten należy ignorować, jeśli ogólna liczba wyklikanych gwiazd jest mała (do kilkunastu). Jeśli gwiazd mamy już koło 30 to prawdopodobnie faktycznie źle wskazaliśmy gwiazdę, przy mniejszej liczbie nie jest to oczywiste. Ogólnie w 5 kolumnie listy uwidoczniony jest błąd L1O danej gwiazdy. Staramy się, aby przy wyklikanych 20-30 gwiazdach błąd średniokwadratowy L1O całego zestawu (widoczny z kolei w przedostatnim wersie okna 2 - mean squared L1O position error) nie był większy od 10’.
W celu poprawy źle wyklikanych gwiazd dysponujemy kilkoma narzędziami. Po pierwsze po wyklikaniu pewnej liczby (~kilkunastu) gwiazd uaktywnia się możliwość wyboru stopnia równania opisującego powstającą siatkę współrzędnych (order of plate constans). Opcja ta zmieniana jest klawiszem o, który powoduje cykliczne przechodzenie pomiędzy stopniami siatki 1-2-3 (aktualny stopień jest widoczny w ostatnim wersie okna 2). Wybieramy taki stopień, przy którym błąd średni jest najmniejszy. Jeśli źle zaznaczyliśmy ostatnią gwiazdę - usuwamy ją klawiszem l (małe L). Wciskając c zobaczymy powstającą siatkę z naniesionymi gwiazdami - błąd pozycji uwidoczniony będzie wielkością znacznika danej gwiazdy (im większy znacznik - tym większy błąd). Możemy przesunąć krzyż w pobliże gwiazd z największym błędem i usunąć je (klawisz d - usuwa gwiazdę położoną najbliżej krzyża). Klawisz D generalnie usuwa gwiazdę z najgorzej określoną pozycją. Usunięte z listy gwiazdy możemy spróbować wyklikać ponownie - do skutku.
Możemy także hurtowo usunąć gwiazdy z dużym błędem pozycji - używając klawisza L - po czym należy podać maksymalną wartość błędu, powyżej której gwiazdy zostaną usunięte. Klawisz O usuwa gwiazdy z błędem większym niż podwojony średni błąd zestawu (opcja bezpieczniejsza, niż L). Pracę należy kontynuować, aż wyklikamy wszystkie widoczne na obrazku gwiazdy - powinniśmy uzyskać co najmniej dwadzieścia kilka - trzydzieści i więcej gwiazd, dla których średni błąd pozycji nie przekroczy 10’. Jeśli błąd jest większy - metrec może nieprawidłowo określać położenie trajektorii meteorów na niebie. Gwiazdy powinny być rozmieszczone na całym polu widzenia (także w rogach i przy krawędziach pola).
Paradoksalnie najtrudniej wyznaczyć pozycję najjaśniejszych gwiazd, ponieważ ich obrazy są "rozlane". W przypadku gwiazd położonych przy skaraju pola widzenia Sirko zaleca użycie klawisza x zamiast enter do zaznaczenia pozycji - co eliminuje gwiazdę z obliczeń lm (które to oblicznenia są zniekształcane w szczególności przez rozmyte obrazy gwiazd w pobliżu krawędzi pola). Jest to istotne jedynie jeśli przesyła się dane do IMO.
Jeśli wskazaliśmy już wszystkie gwiazdy na danym obrazku naciskamy escape. Jeśli wywołując refstarsa wczytaliśmy tylko jeden obrazek - zakończymy w ten sposób pracę z programem, jeśli zaś kilka - przejdziemy do następnego aż do ich wyczerpania. Dane zostaną zapisane do pliku o nazwie jaką podaliśmy wywołując refstarsa (plik.ref).
Konfigurowanie metreca - plik metrec.cfg.
Przed użyciem samego metreca należy dostosować do naszych potrzeb plik konfiguracyjny metrec.cfg, konfigurujący działanie programu. Plik ten, (jak zresztą wszystkie pozostałe, przewidziane do edycji) można otworzyć w dowolnym edytorze tekstu (np. notepad.exe) – są to niezależnie od posiadanych rozszerzeń pliki typu .txt . Plik metrec.cfg skonstruowany jest jako lista parametrów. Istotne jest, aby każdy parametr był w nowej linii (wersie). Znaki za symbolem wykrzyknika (!) są przez program pomijane (służą jedynie jako komentarze). Graficzny wygląd pliku (wyrównanie linii) nie ma znaczenia.
Linia ma postać:
parametr = wartość ! komentarz
Poniżej wstawiony plik cfg metreca jest plikiem oryginalnym wersji 5.1 "as is". UWAGA! W niektórych dystrybucjach metreca w pliku cfg brakuje linii "InterlacedVideo" - 9 linia od góry. W takim wypadku należy ją skopiować z poniższego pliku i wkleić do cfg we właściwe miejsce - inaczej program nie ruszy. Parametry są w pierwszej kolumnie. Ze względu na właściwe justowanie usunięto większość wykrzykników przed komentarzami (środkowa kolumna). W nawiasach kwadratowych podane są możliwe opcje wraz z ustawieniem domyślnym (default). Trzecia kolumna nie występuje oryginalnie w pliku i znajdują się w niej moje komentarze. W nawiasach kwadratowych podane są możliwe opcje. W pliku nie wolno zostawić pustych wersów.
Kolorem czerwonym oznaczone są ważne ustawienia - takie, których koniecznie trzeba dopilnować, aby program działał, lub aby generowane dane miały jakąkolwiek wartość. Kolorem zielonym oznaczono ustawienia istotne - ale nie krytyczne. Kolor czarny pozostawiono tam, gdzie zmian nie ma albo parametr, przynajmniej na początku, nie jest istotny. Plik trzeba "przeczytać" i skonfigurować od początku do końca - wszystkie zawarte w nim ustawienia mają swoje znaczenie. Nie można pominąć "czarnego koloru" komentarza. Pewne kwestie nabierają wagi wraz z coraz bardziej zaawansowanym korzystaniem z programu - a inne, kiedy decydujemy się przesyłać dane do IMO.
| AutoConfiguration = yes | ! Set some parameters to default values: SaveSingleFrames = no, SaveMeteorBand = yes, SaveSumImage = yes, SaveMeteorData = yes, TracingImage = yyyymmdd.bmp, FileNameRule = 2, EquatorialCoordinates = yes, CreatePosDatEntry = yes, [yes, no; default: yes] | - autokonfiguracja części parametrów, zmienić na NO |
| ULWindowContent = W URWindowContent = B LLWindowContent = A LRWindowContent = G |
! Content of the upper left, upper right, lower left and lower right MetRec window: W = raw image, X = raw image & blinking stars, I = mean subtracted image, R = regions of interest, S = sensitivity image, A = background image, F = flatfield, M = last meteor image (applicable if SaveSumImage = yes), P = meteor plot (applicable if EquatorialCoordinates = yes), L = last meteor plot (applicable if EquatorialCoordinates = yes), C = coordinate grid (applicable if EquatorialCoordinates = yes), B = backward tracing plots (applicable if EquatorialCoordinates = yes), 1..9 = backward tracing plot 1-9 (applicable if EquatorialCoordinates = yes) | - co widać w oknach, sugeruję zmienić URWindowContent = M (ostatni meteor) |
| FrameGrabberType = 2 | ! Type of your Matrox Framegrabber: 1 = Meteor I, 2 = Meteor II, [1..2] | - typ karty Matrox (ustawić wg posiadanej) |
| FrameGrabberDeviceNumber = 1 | ! Device Number of your Matrox framegrabber, 0 = Default, 1..4 = device 1..4, [0..4, default: 0] | nr karty (jeśli ktoś ma >1 w jednym komputerze) |
| VideoSignalType = PAL | ! Type of the video signal: PAL or NTSC, [PAL, NTSC] | - rodzaj sygnału generowanego przez kamerę, PAL lub NTSC |
| InterlacedVideo = yes | ! Is the video signal interlaced? I.e. is it a standard interlaced camera with an effective integration time of 1/50s (PAL) resp. 1/60s (NTSC) per video field, or is it a progressive scan or integrating camera with 1/25s (PAL) resp. 1/30s (NTSC) integration time per field?, [yes, no] | - czy sygnał jest z przeplotem - na razie wszyscy chyba 100% YES |
| TimeBase = 1 | ! What time base shall be used: 1 = current time (as determined from the computer clock), 2 = video clock (recognize a clock that is superimposed to the video image), 3 = video tape time (start time of the tape plus run time of MetRec), [1..3] | - źródło czasu - zostawić 1 |
| VideoClockOffset = 0 0 0 | ! Offset of the video clock at start time (h m s - in case the clock was not properly synchronized), (applicable if TimeBase = 2) [0..23 0..59 0..59] | - tylko dla taśm video, nie dotyczy |
| VideoTapeStartTime = 0 0 0 | ! Start time of the video tape (h m s). (applicable if TimeBase = 3) [0..23 0..59 0..59] | - nie dotyczy |
| TimeDriftCorrection = 0 | ! How many seconds per hour needs the time be corrected to match the drift of the computer clock or video tape? [-60...60] | - j.w., nie dotyczy |
| TimeZoneCorrection = -1 | ! Correction of the computer clock in hours, [-11..12] | - różnica czasu strefowego do UTC, najlepiej w komputerze ustawić GMT jako strefę i wyłączyć zmianę na czas letni - wówczas wartość TimeZoneCorrection ustawić na 0 |
| DSTCorrection = yes | ! The TimeZoneCorrection entry will be reduced by one during daylight saving time. [yes, no] | - czy uwzględniać zmiany czasu na letni przy powyższym rozwiązaniu NO |
| DateBase = 1 | ! What start date shall be used: 1 = current date (as determined from the computer clock), 2 = video clock (recognize a clock that is superimposed to the video image), 3 = video tape date (start date of the tape),[1..3] | data początku obserwacji - zostawić 1 |
| VideoTapeStartDate = 1 1 2000 | ! Start date of the video tape (d m y). (applicable if DateBase = 3), [1..31 1..12 1951..2050] | - nie dotyczy |
| DateCorrection = yes | ! The date for file and directory names will be corrected by -1 day if the observation started between midday (important for European observers), [yes, no] | - zostawić |
| VideoClockXPosition = 15 33 51 69 88 106 197 215 233 251 270 288 324 342 | - nie dotyczy | |
| VideoClockYPosition = 260 260 260 260 260 260 260 260 260 260 260 260 260 260 | X and Y position of the superimposed clock digits. (applicable if TimeBase = 2 or DateBase = 2) | - nie dotyczy |
| ! The date for file and directory names will be corrected by -1 day if the observation started between midday (important for European observers), [yes, no] | - zostawić | |
| RecognitionEndTime = 6 30 0 | ! End time of recognition. [0..23 0..59 0..59] | - koniec obserwacji (godzina, minuta, sekunda), ustawienie pomijane jeśli EquatorialCoordinates = yes (wówczas koniec pracy wg parametru MaximumSolarAltitude) |
| AutoRestart = no | ! Shall MetRec suspend the observation at the end time and restart at the next evening? [yes, no] | - czy metrec ma zakończyć obserwację rano i wznowić wieczorem, działa jeśli komputer pozostaje stale włączony, w przeciwnym wypadku bez znaczenia |
| AutoRenameLogfile = yes | ! Shall the logfile be renamed at observation restart? (applicable if EquatorialCoordinates = yes, AutoRestart = yes and Logfile name = yyyymmdd.log), [yes, no] | - czy metrec ma zmienić nazwę pliku log w ww. wypadku (komputer stale włączony) |
| RecognitionRestartTime = 16 0 0 | ! Restart time of recognition. (applicable if AutoRestart = yes) [0..23 0..59 0..59] | - czas wznowienia obserwacji, pomijane jeśli WaitForDusk = yes |
| QuitBehaviour = 0 | ! How shall MetRec be finished: 0 = quit with confirmation, 1 = quit without confirmation, 2 = quit and shutdown without confirmation, (applicable if AutoRestart = no), [0..2, default: 0] | - jak metrec ma się zamykać: 1 - po potwierdzeniu, 2 - bez potwierdzenia, 3 - bez potwiedzenia powodując wyłączenie komputera. Wg uznania, w przypadku automatycznego uruchamiania komputera ustawienie 3 pozwala automatycznie go wyłączać. |
| MaximumSolarAltitude = -9 | ! Maximum altitude of the Sun, at which the recognition is forced to end, (applicable if EquatorialCoordinates = yes), [-18..0] | - wysokość Słońca pod horyzontem, przy której metrec ma się wyłączać, ustawić doświadczalnie do możliwości kamery aby nie było przepaleń nieba |
| WaitForDusk = yes | ! Shall MetRec wait until the Sun has reached at least the specified altitude?, (applicable if EquatorialCoordinates = yes), [yes, no] | - czy rozpoznawanie meteorów ma się zaczynać dopiero po osiągnięciu ww. wysokości Słońca - YES |
| MinimumLunarDistance = 0 | ! Minimum distance of the Moon from the center of field of view. MetRec will not start if it the distance becomes smaller during the observation (applicable if EquatorialCoordinates = yes), [0..90] | - tylko dla posiadaczy wzmacniaczy światła, zostawić 0 |
| DelayTime = 0 | ! Delay in ms after each frame grab to reduce the frame rate. [0..999, default: 0] | - zostawić 0 |
| FrameBufferCount = 300 | ! Number of internal buffers allocated for the frame ring buffer. For each buffer an amount of 440/308 kB if it is set to max required. [25..300, default: 300] | - zostawić jak jest, chyba, że problemy z pamięcią |
| DisplayRefreshRate = 10 | ! Defines, after how many frames the display is refreshed. Increase this number to achieve higher performance. [1..100] | - co ile klatek ma być odświeżany obraz live w oknie RAW (lewe górne domyślnie), kwestia estetyki, może zostać |
| InternalResolution = full | ! At what resolution shall MetRec run internally? [full, max, default: full] | zmienić na max, chyba, że maszyna nie daje rady |
| MeteorElongation = 1 | ! Defines, whether meteor are mainly point-like (0), slightly elongated (1), or strongly elongated (2) objects. [0..2; default: 2] | - zostawić |
| StartThreshold = 1.5 | ! Start threshold for meteor detection. [0.1..10] | - początkowy próg wykrywania, na początek zostawić, można zmienić, jeśli są problemy z czułością |
| ConstantThreshold = no | ! Shall the recognition threshold be kept constant? [yes, no; default: no] | - czy próg ma być stały, zostawić no |
| RecognitionThreshold = 0.9 | ! Given the current maximum noise value x, the threshold for meteor detection converges towards RecognitionThreshold * x. (applicable if ConstantThreshold = no), [0.1..10.0; default: below 1.0] | - regulacja czułości, na początek zostawić |
| FloorThreshold = 0.5 | ! Minimum threshold for meteor detection. (applicable if ConstantThreshold = no), [0.1..10.0; default: 0.5] | - minimalny próg wykrywania, na początek zostawić |
| ThresholdHistory = metrec.thr | ! Development of the recognition threshold to be saved when leaving MetRec. (applicable if ConstantThreshold = no). [filename] | - zostawić |
| FlashThreshold = 5 | ! Minimum number of pixel clusters exceeding the recognition threshold, at which a flash and not a meteor is detected. Set it to zero to deactivate flash detection. [0, 2..20; default 5] | - zmienić na 0 |
| FlashRecoveryFrameCount = 50 | ! Number of frames that are ignored after a flash was detected. [0..300; default 50] | - zmienić na 0 |
| SaveFlashImage = no | ! Shall the video frame with the flash be saved? [yes, no; default: no] | - zostawić |
| SaveBackgroundRate = 0 | ! Defines, after how many minutes a background image shall be saved (0 = never). [0..1439; default 0] | - częstotliwość zapisywania obrazków tła, wg uznania, 0 wyłącza |
| MinimumFrameCount = 3 | ! Minimum number of frames exceeding the meteor detection threshold before a meteor is reported. MinimumFrameCount is automatically set to 1 if StopDetectionOnSave is yes [1..5; default: 3] | - Na ilu klatkach musi zostać przekroczony próg, aby zaszła detekcja, zostawić |
| Beep = no | ! Beep if a meteor is detected? [yes, no] | - sygnał dźwiękowy w razie detekcji, wedle życzenia |
| SendSerialPing = no | ! Shall information be sent to the serial port? [yes, no] | - czy wysłać po detekcji sygnał na port |
| SerialPingPort = 1 | ! Serial port to which the information shall be sent. (applicable if SendSerialPing = yes). [1..4] | - jeśli tak, który port |
| SerialPingType = BF | ! Which information shall be send: A - alive ping every 10s, B - ping at begin of meteor, E - ping at end of meteor, F - ping at flash, I - detailed information at end of meteor (applicable if SendSerialPing = yes), [ABEFI] | - jaki rodzaj sygnału ma być wysłany |
| FrameSize = 70 | ! Apparent vertical size of a video frame in degree. Give not the size of the visible fov of your camera, but the size of the whole video frame along the y axis. [3..180] | - pionowy kąt widzenia kamery w stopniach |
| MinimumMeteorVelocity = 2.5 | ! Minimum apparent meteor velocity at zenith in degrees per second. [1..5; default 2.5] | - minimalna prędkość kątowa meteoru w zenicie - można obniżyć do 1.5, mogą wystąpić częstsze detekcje samolotów i ptaków |
| MaximumMeteorVelocity = 40 | ! Maximum apparent meteor velocity at zenith in degrees per second. [37-50; default 40] | - maksymalna prędkość kątowa meteoru w zenicie - można zwiększyć, efekty jak wyżej |
| PositionAngleOffset = 0 | ! Offset for the computed position angle of meteors. If the offset is 0, the angle is given in the mathematical sense, i.e. 0 deg along the positive x-axis and 90 deg along the positive y-axis. [0..359; default 0] | - poprawka kątowa - zostawić 0 |
| UseInputMask = no | ! Using a mask for the frame grabber input? [yes, no; default: yes] | - czy używać maski (używać, tylko trzeba ją sobie zrobić) |
| InputMask = dummy.bmp | ! An uncompressed b/w BMP-File (384*288 pixel) used to mask the frame grabber input. (applicable if UseInputMask = yes), [filename] | - nazwa pliku bmp maski |
| DarkField = dark.bmp | ! An uncompressed 8-bit BMP file of the same resolution as the video input (e.g. 768x576 or 384*288 pixel) that will be subtracted from each video frame for darkfield compensation (optional parameter), [filename] | - nazwa pliku darka, jeśli nie używamy wykasować tą linię bądź ją zaremować (od ver. 5.1) |
| UseOldFlatField = no | ! Using the flatfield from a previous meteor recognition for initialization? [yes, no; default: no] | - zostawić no |
| OldFlatField = metrec.ffd | ! Old flatfield to load for initialization. (applicable if UseOldFlatfield = yes), [filename] | - zostawić |
| NewFlatField = metrec.ffd | ! New flatfield to be saved when quitting. [filename] | - zostawić |
| FlatFieldSmooth = 2 | ! How strong shall the flatfield be smoothed? Choose a higher value if you have strong pixel jitter. | - zostawić |
| ! [0..5; default 2] | stopień wygładzania pola, można zwiększyć przy dużym szumie | |
| ! New flatfield to be saved when quitting. [filename] | - zostawić | |
| FlatFieldSmoothDirection = 0 | ! Direction in which the flatfield is smoothed. If your camera is not guided, choose the direction of star drift. 0 = symmetric smoothing, 1 = smooting up, 2 = smoothing up right, 3 = smoothing right, 4 = smoothing down right, 5 = smoothing down, 6 = smoothing down left, 7 = smoothing left, 8 = smoothing up left, [0..8] | - kierunek wygładzania pola. Wybrać kierunek odpowiadający ruchowi gwiazd w kadrze, 0 - symetrycznie, 1 - do góry, 2 - do góry i w prawo, 3 - w prawo, 4 - w prawo i w dół, 5 - w dół, 6 - w dół i w lewo, 7 - w lewo, 8 - w lewo i w górę |
| ! How strong shall the flatfield be smoothed? Choose a higher value if you have strong pixel jitter. | - zostawić | |
| SensitivityImage = metrec.bmp | ! Sensitivity image when MetRec is left. [filename] | - zostawić |
| TracingImage = metrad.bmp | ! Backward tracing image when MetRec is left. [filename] | - zostawić |
| TimeStamp = 0 | ! Shall a time stamp be written to each single frame, sum image and flash? 0 = no time stamp, 1 = only time, 2 = date & time,[0..2] | czy w klatki ma być wkopiowywany czas, lepiej nie - zostawić 0 |
| TimeStampXPosition = 384 | ! Backward tracing image when MetRec is left. [filename] | - zostawić |
| TimeStampYPosition = 288 | ! X and Y position of the time stamp.(applicable if TimeStamp = yes) [0..384][0..288] | - jeśli powyższe tak, pozycja wkopiowania |
| ! Shall a time stamp be written to each single frame, sum image and flash? 0 = no time stamp, 1 = only time, 2 = date & time,[0..2] | czy w klatki ma być wkopiowywany czas, lepiej nie - zostawić 0 | |
| SaveSingleFrames = no | ! Shall the video frames be saved if a meteor is detected? [yes, no, first; default: no] | - czy zapisywać pojedyncze klatki. Koniecznie! Zmienić na yes |
| SaveMeteorBand = yes | ! Shall the image bands containing the meteor be saved? [yes, no; default: yes] | - zostawić |
| SaveSumImage = yes | ! Shall a sum image of the meteor be computed and saved? [yes, no: default: yes] | - zostawić |
| SavePreFrameCount = 3 | ! How many frames shall be saved before the first frame on which the meteor is detected? (applicable if SaveSingleFrames = yes or SaveSumImage = yes), [0..10; default 3] | - ile klatek zapisać przed detekcją, zmienić na 10 |
| SavePostFrameCount = 3 | ! How many frames shall be saved after the last frame on which the meteor was detected? (applicable if SaveSingleFrames = yes or SaveSumImage = yes), [0..10; default 3] | - ile klatek ma być zapisanych po detekcji, zmienić na 10 |
| RealTimeFluxUpload = no | ! Shall flux data be uploaded in real-time to the central VMO server? (applicable if EquatorialCoordinates = yes and the computer has a permanent internet connection), [yes, no] | - od ver. 5.1 czy uploadować fluxy na żywo, zostawić no (yes, o ile wszystko jest dograne z wysyłaniem danych do IMO) |
| CameraName = MYCAMERA | ! Name of the camera that fits to the corresponding section in the PostProc.VMO file, used for real-time flux upload only. (applicable if RealTimeFluxUpload = yes) [cameraname] | - ważne, jeśli na powyższe odpowiedziano YES, nazwa kamery z pliku VMO |
| BaseDirectory = data | ! Directory (relative or absolute name) in which the images are stored. [dirname] | - katalog danych, ścieżka względna bądź bezwzględna |
| FileNameRule = 2 | ! Which name shall the images get? 1 = meNNN.bmp and meNNN_FF.bmp, 2 = HHMMSS.bmp and HHMMSSFF.bmp, with NNN - meteor number, HHMMSS - appearance time, FF - frame number, (applicable if SaveSingleFrames = yes or SaveSumImage = yes), [1..2; default: 2] | - nazewnictwo klatek, zostawić 2 |
| ClockSync = no | ! Shall the computer clock be synchronized with an external DCF-77 clock? [yes, no] | - synchroniczacja z odbiornikiem DCF, zostawić no (no chyba, że ktoś ma) |
| ClockType = 2 | ! Type of the external DCF-77 clock? 1 = Conrad DCF Clock, 2 = Hopf ClockMouse (applicable if ClockSync = yes). [1..2] | - typ DCF, nie dotyczy |
| ClockSyncRate = 0 | ! Defines, after how many minutes the internal clock is synchronized (0 = only at startup). (applicable if ClockSync = yes). [0..1439; default 0] | - interwał synchronizacji DCF, nie dotyczy |
| ClockSyncPort = 1 | ! Serial port where the DCF clock is installed. (applicable if ClockSync = yes),[1..4] | - port DCF, nie dotyczy |
| EquatorialCoordinates = yes | ! Shall the x-y-coordinates be converted to right ascension and declination, the brightness be computed, and the meteor shower be determined? yes, no; default: yes) | - czy współrzedne mają być przeliczone na układ równikowy, TAK - to ważne ustawienie warunkujące działanie wielu innych, zostawić |
| SaveMeteorData = yes | ! Shall detailed position data of each meteor be saved for orbit calculation from double station observations? (applicable if EquatorialCoordinates = yes, SaveSumImage = yes and SaveSingleFrames or SaveMeteorBand = yes), [yes, no; default: yes] | - zostawić |
| ReferenceStars = dummy.ref ! | File with reference star coordinates. (applicable if EquatorialCoordinates = yes), [filename] | - nazwa pliku referencyjnego, według którego będą rozpoznawane gwiazdy (z modułu refstars) |
| MaximumMeteorTilt = 0 | ! Maximum tilt (in ř) of a meteor trail. If the backward prolongation of a meteor still misses the radiant area of a given diameter, the meteor does not belong to this shower. (applicable if EquatorialCoordinates = yes), [0..10; default: 0] | - zostawić (szczególnie, jeśli dane mają iść do IMO) |
| MaximumMeteorShift = 0 | ! Maximum shift (in ř) of a meteor trail. If the backward prolongation of a meteor still misses the radiant area of a given diameter, the meteor does not belong to this shower. (applicable if EquatorialCoordinates = yes) [0..10; default: 0] | - zostawić, jw. |
| CreatePosDatEntry = yes | ! Shall an PosDat entry for each meteor be created? (applicable if EquatorialCoordinates = yes), [yes, no; default: yes] | - zostawić |
Pierwszym krokiem jest zmiana w powyższym parametrze (AutoConfiguration) wartości na no, gdyż m.in. zamierzamy zapisywać pojedyncze klatki. Pozostałe wartości (w następnych linich) należy wpisać zgodnie z potrzebą, nie odbiegają one od poprzedniej wersji. Ważne jest ustawienie czasu – najlepiej ustawić czas bez poprawki – taki jak na zegarze komputera, zegar komputera ustawić zaś na UTC (bez uwzględniania strefy - GMT) i wyłączyć zmiany na czas letni. Należy też zapewnić stałą synchronizację zegara komputera poprzez sieć (np. programem nettime).
Prowadzenie obserwacji - metrec.
Po dostosowaniu i zapisaniu pliku metrec.cfg możemy wreszcie przystąpić do obserwacji. Metreca uruchamiamy poleceniem:
ścieżka\metrec plik.cfg plik.log]
gdzie:
- ścieżka - ścieżka do katalogu programu metrec
- plik.cfg - plik konfiguracyjny metreca (domyślnie metrec.cfg)
- plik.log - plik, do którego trafią obserwacje (najlepiej log.log)
Jeśli wszystko poszło poprawnie zobaczymy główne okno programu, składające się z czterech podokien (których zawartość możemy ustawić w pliku cfg). Jeśli ustawiliśmy w cfg WaitForDusk=no lub w danym momencie godzina zmierzchu wyliczona przez metreca już nastąpiła - w lewym górnym oknie zobaczymy obraz z kamery. Jeśli godzina zmierzchu nie nastąpiła - wszystkie okna będą czarne. Stąd wniosek, że do eksperymentowania w dzień parametr WaitForDusk należy ustawić na no.
Rys. 7 - Metrec.exe zaraz po uruchomieniu POWIĘKSZ
Jeśli program działa (tzn. prowadzone jest rozpoznawanie meteorów) w lewym górnym oknie widać obraz z kamery. Zawartość okien można ustalić w pliku .cfg bądź w czasie pracy programu, wciskając klawisz F1-F4 (wybierający okno do zmiany) oraz klawisz zawartości (legenda-screensaver pokaże się po wciśnięciu klawisza dowolnej litery podczas pracy programu). W lewej kolumnie zmienia się liczba klatek od momentu rozpoczęcia obserwacji (frame count), zaś na dole tej kolumny widoczna jest liczba zarejestrowanych meteorów (# meteors). Przed tą liczbą (która jest w nawiasie, poprzedzona krzyżykiem #) wyświetlana jest liczba aktualnie interesujących metreca rejonów pola widzenia (tzn. takich, na których "coś się dzieje"). Jeśli program pracuje z właściwą czułością powinny tam nieustannie zmieniać się cyfry w zakresie 0-kilka.
Dostrajaniem czułości steruje przede wszystkim parametr RecognitionTreshold (próg wykrywania) w pliku .cfg . Parametr ten można zmienić w czasie pracy metreca, jednak zmiany te nie zostaną automatycznie zapisane do cfg i przy następnym uruchomieniu nie zostaną uwzględnione. Tym niemniej zamiast restartować metreca po wpisaniu zmian do .cfg wygodniej jest po jego uruchomieniu zawiesić detekcję (CTRL-U), zmienić próg wciskając t lub Shift-t (odpowiednio: zmniejsza/zwiększa próg, czyli zwiększa/zmniejsza czułość), po czym wznowić detekcję CTRL-R - i metodą prób i błędów doprowadzić program do pożądanej czułości. Każdorazowo nowo ustawiona wartość RecognitionTreshold jest możliwa do odczytania w oknie pokazującym linie zapisywane do loga (na dole po lewej). Ostatecznie dobraną wartość należy wpisać później we właściwe miejsce do pliku .cfg (zmienna RecognitionThreshold). Wprowadzając zmiany progu wykrywania trzeba mieć na względzie, że metrec potrzebuje chwili czasu (kilku minut) aby dynamicznie dostosować się do nowych ustawień.
Działający program nie wymaga żadnej obsługi, można więc iść spać. Program założy w katalogu danych podkatalog YYYYMMDD w którym umieści wszystkie pliki z danej nocy (między innymi kopię pliku log z katalogu głównego zapisaną pod nazwą jaką podaliśmy, tzn. wg powyższej sugestii log.log). Zasadniczy (głowny) plik log zostanie zapisany w katalogu głównym programu jako log.log. Plik o nazwie log.log w katalogu głównym jest zawsze ostatnim plikiem log jaki wygenerował metrec - to znaczy jeśli metrec działa, jest on aktualnie otworzonym, aktywnym plikiem. Jeśli metrec nie jest uruchomiony - plik log.log w katalogu głównym jest ostatnim wygenerowanym plikiem log. Plik ten - po następnym uruchomieniu metreca - będzie miał nazwę zmienioną na n.log (001.log, 002,log, …, n.log) w ten sposób, że otrzyma trzycyfrowy numer, kolejny po istniejącym już w katalogu głównym, poczynając od 001, z rozszerzeniem .log.
Metrec "na skróty" - jak szybko zacząć obserwacje.
Rozdział przeznaczony jest dla osób nieco zaawansowanych. Osoby początkujące nie powinny raczej iść na skróty.
Aby MetRec mógł działać – potrzebuje pliku referencyjnego. Wykonanie pliku referencyjnego wymaga obrazu referencyjnego – a to wiąże się z wyrzeczeniami: wyczekiwaniem na pogodę i zarywaniem nocy, kiedy jest na nią nadzieja. Często jest też tak, że instalujemy nową kamerę i w zasadzie powinniśmy zrobić po kolei obraz a potem plik referencyjny, zanim w ogóle rozpoczniemy obserwacje, co przy splocie niesprzyjających okoliczności bywa, że trwa długo - tracimy zatem bezproduktywnie wartościowy czas obserwacyjny.
Można to wszystko wykonać na skróty i bez ślęczenia nocami, rejestrując przy okazji pełnowartościowe dane. Schemat jest prosty:
1. Instalujemy kamerę, kierujemy ją w pożądane miejsce, ustawiamy ostrość.
2. Musimy mieć jakikolwiek plik referencyjny, aby metrec w ogóle ruszył.
3. Plik ten edytujemy i ustawiamy pożądane wartości brightness i contrast.
4. W pliku .cfg wpisujemy nazwę tego pliku i ustawiamy zapis obrazów tła.
5. Włączamy metreca i idziemy spać.
6. Metrec w ciągu kolejnych nocy dokonuje rejestracji i zapisuje obrazy tła.
7. Z obrazów tła na których są gwiazdy sporządzamy plik referencyjny.
8. Nowy plik referencyjny wpisujemy do .cfg
9. Po kolejnej pogodnej nocy wykonujemy optymalizację pliku referencyjnego
10. Obserwacje z poprzednich nocy redukujemy z użyciem zoptymalizowanego pliku.
Metrec będzie prowadził rejestrację, dodatkowo w ustalonych interwałach dokonując zapisu obrazu tła. Obrazy te są uśrednione, więc świetnie nadają się na obrazy referencyjne. Prędzej czy później trafimy na pogodę i w efekcie będziemy dysponować obrazem referencyjnym lub kilkoma. Częstokroć nawet pozornie całkowicie niepogodne noce okazują się mieć godzinę czy pół "okna".
Jak to działa w szczegółach.
ad.1 - sprawa jest oczywista. Kamera musi patrzeć w interesującą nas stronę nieba i musi dawać ostry obraz. Ostrość można ustawić na możliwie odległy fragment krajobrazu, z tym że przysłona musi być maksymalnie otworzona - w przypadku kamer z obiektywami autoiris należy to robić kiedy jest ciemno. Chodzi o to, aby możliwie najmniejsza była głębia ostrości.
ad.2 – Aby metrec rozpoczął wykrywanie musi mieć przygotowane pliki potrzebne do działania. Musimy zapewnić mu plik referencyjny i obraz dark. Plik referencyjny możemy pożyczyć z innej kamery albo nawet od kolegi z PFN – jedynym zastrzeżeniem jest, aby kamera z której go pożyczamy nie była choćby minimalnie skierowana pod horyzont, bo wówczas będziemy potrzebować maski na piksele, które wg pożyczonego pliku ref są pod horyzontem Do potrzeb zapisu obrazów tła maska nie jest konieczna (a poza tym może maskować część kadru, która w rzeczywistości na naszej kamerze jest aktywnym polem widzenia). Wykonanie obrazu dark (zrzutu jałowego sygnału matrycy) jest opisane szczegółowo w instrukcji – w skrócie polega na wykonaniu obrazka referencyjnego w pełnej (nie połówkowej) rozdzielczości przy zasłoniętym całkowicie obiektywie z integracją 64 klatek (patrz rozdział grab – dark i obraz referencyjny).
ad.3 Plik referencyjny edytujemy np. notepadem (jest to plik tekstowy) i ręcznie wpisujemy pożądane wartości videobrightness, videocontrast oraz gamma (na początku pliku). Pożądane to znaczy właściwe dla kamery, którą dysponujemy. Jeśli kamera nie ma regulacji gammy – to przyjmujemy 1.0 (uwaga – w plikach metreca jako znak dziesiętny stosowana jest kropka a nie przecinek). Każdy obserwator ma wypraktykowane wartości videobrightness i videocontrast. Można przyjąć, że wartości te na poziomie 170-180 są bezpieczne dla szumiących kamer jak Tayama.
ad.4 W pliku cfg musimy wpisać nazwy tak spreparowanego pliku referencyjnego, darka i (ewentualnie) maski w liniach odpowiednio ReferenceStars, DarkField i InputMask. Jeśli używamy maski parametr UseInputMask należy ustawić na YES. Ponadto ustawiamy parametr SaveBackgroundRate na pożądany interwał w minutach (20 minut jest rozsądnym kompromisem).
ad.5 Włączamy metreca. Jeśli jest za wcześnie, możemy w pliku konfiguracyjnym ustawić WaitForDusk=NO – wówczas metrec nie będzie czekał do zmierzchu. Jeśli metrec działa możemy zostawić komputer.
ad.6 Metrec będzie w nocy normalnie działał, aczkolwiek generowane dane będą błędne z powodu złego pliku .ref (złych współrzednych). Tym niemniej będzie je można później przekonwertować według właściwych współrzędnych, zaś zapisane obrazy tła wykorzystać w roli obrazów referencyjnych.
ad. 7 Kiedy przeglądając obrazy z nocy uznamy, że dysponujemy dostatecznie dobrymi obrazami referencyjnymi – wykonujemy wg standardowej procedury plik referencyjny za pomocą modułu refstars (patrz rozdział refstars – wskazanie metrecowi gwiazd).
ad.8 Plik ten wpisujemy przed kolejną obserwacją do .cfg (parametr ReferenceStars) jako nowy plik referencyjny.
ad.9 Po kolejnej pogodnej nocy automatycznie generowany plik (w folderze obserwacji, nazwa wg schematu yyyymmdd.ref) będzie zawierał kilka-kilkanaście tysięcy gwiazd. Optymalizujemy go (patrz optymalizacja plików referencyjnych) i wpisujemy do .cfg (parametr ReferenceStars) jako nowy plik referencyjny.
ad 10 Obserwacje dokonane od momentu włączenia kamery w danym położeniu konwertujemy do współrzędnych wynikających ze zoptymalizowanego pliku – stosując przy redukcji opcję postproc -ref nazwa_nowego_pliku.ref plik.log . W ten sposób od momentu pierwszego uruchomienia kamery z pożyczonym plikiem ref mamy pełnowartościowe obserwacje prawidłowo zredukowane – oraz zoptymalizowany plik .ref.
Metrec - rozwiązywanie problemów.
Wszystko tu jest omówione szczegółowo w instrukcji, a w tym rozdziale podane skrótowo i ze wskazaniem na "drobne niuanse", aby ułatwić jak najszybsze zdiagnozowanie problemu.
Metrec ZASADNICZO działa natychmiast po wgraniu na dysk, o ile tylko w komputerze jest zainstalowana odpowiednia karta Matrox. Program po włączeniu powinien podjąć rejestrację, jeśli tylko jest noc lub w pliku .cfg ustawiono WaitForDusk=no (testując zestaw należy tymczasowo tak właśnie ustawić ten parametr - w innym wypadku metrec będzie czekał do zmierzchu). Nie ma zasadniczego znaczenia (poza samą jego obecnością) plik referencyjny, lokalizacja stacji, czas i strefa czasowa ani to, czy do karty w ogóle dochodzi sygnał wideo. Tymczasem częstokroć metrec nie uruchamia się, generując zdawkowe komunikaty - problem kryje się niuansach stojących za słowem "zasadniczo". Metrec będzie bowiem ZASADNICZO działał - ale o ile wykryje kartę wideo i nie dopatrzy się sprzeczności we wprowadzonych przez nas danych.
Komunikat "ERROR: MsysAlloc failed" (błąd alokacji pamięci) oznacza, że problemem jest karta wideo. Albo nie ma jej w komputerze, albo nie kontaktuje, albo nie ma sterowników. W najgorszym zaś razie nie współpracuje z płytą główną naszego komputera lub jest uszkodzona. Jeśli karta fizycznie znajduje się w komputerze należy sprawdzić, czy jest widoczna w menedżerze systemu (w panelu sterowania XP). Jeśli nie, należy spróbować przełożyć ją do innego gniazda. Jeśli to nie skutkuje, to albo jest uszkodzona, albo w konflikcie z płytą główną. Wówczas pozostaje wymiana karty bądź płyty. Jeśli karta jest obecna, ale oznaczona żółtym trójkątem ("problem"), to należy sprawdzić, czy jest zainstalowane jej oprogramowanie (dystrybuowane wraz z metrecem, w folderze drivers). Jeśli wszystko jest w porządku, a wymieniony komunikat nadal pojawia się, popatrzmy, czy nie mamy już uruchomionego metreca na tej karcie. Jeśli nie, to ostatnim powodem może być parametr FrameGrabeDeviceNumber w pliku .cfg. Oznacza on numer karty w komputerze i jest przewidziany dla komputerów, w których jest więcej niż jedna karta. Domyślnie, przy jednej karcie, ów parametr powinien być ustawiony na zero (FrameGrabeDeviceNumber=0) co należy sprawdzić, ewentualnie spróbować innych nastaw w zakresie 0-4. Są przypadki, kiedy pojedyncza karta działa z tym parametrem różnym od zera. Ostatecznym sprawdzianem hardwaru jest uruchomienie graba linią grab -2 -pal -dev x nazwa.bmp (gdzie za x podstawiamy liczbę ustaloną dla FrameGrabeDeviceNumber w pliku .cfg - parametr -dev pomijamy dla wartości 0). Jeśli grab się uruchomi to znak, że karta i jej sterownik funkcjonują prawidłowo. Nie ma znaczenia, czy do karty faktycznie dochodzi sygnał wideo.
Mimo, ze hardware działa prawidłowo i grab pokazuje obraz możemy czasem zobaczyć komunikat:
"ERROR: Missing valid entry 'InterlacedVideo' in configfile!". Znaczy to "brak parametru 'InterlacedVideo' w pliku konfiguracyjnym". Mamy dystrybucję metreca, w której pliku konfiguracyjnym brakuje wpisu 'InterlacedVideo'. Powinien on znajdować się pomiędzy parametrami FrameGrabberDeviceNumber i VideoSignalType. Należy go po prostu wkleić w to miejsce. Wpis ten dla kamer z przeplotem (czyli praktycznie wszystkich) ma następującą treść:
InterlacedVideo=yes
Jeśli karta działa prawidłowo to w razie kłopotów najczęściej możemy zobaczyć dwa następujące komunikaty:
"ERROR: Could not open input mask 'nazwa.bmp' for read!"
"ERROR: Input mask 'nazwa.bmp' is not a supported BMP file type! An uncopressed b/w Windows-BMP-File of 384 x 288 pixels is expected."
W tłumaczeniu pierwszy komunikat brzmi: "nie można otworzyć pliku maski 'nazwa.bmp'". Zamiast pliku maski (input mask) może w komunikacie wystąpić inny (dark, referencyjny itd.). Komunikat ten oznacza, że pliku takiego nie ma fizycznie w folderze programu. Jest jego nazwa wpisana w pliku konfiguracyjnym .cfg, nie ma natomiast pliku o takiej nazwie w folderze programu (czyli tam, gdzie znajduje się uruchamiany plik metrec.exe). Należy sprawdzić, czy pliki są tam gdzie trzeba i czy prawidłowo wpisaliśmy ich nazwy do .cfg. Są to pliki: referencyjny (.ref), dark (.bmp), maska (.bmp). Pliki te muszą się znaleźć w folderze programu a ich nazwy muszą być wpisane w pliku konfiguracyjnym (.cfg). Jeśli metrec czytając plik .cfg nie odnajdzie w folderze programu pliku odpowiedniego do wpisanej nazwy - wyłączy się.
Drugi komunikat w tłumaczeniu brzmi: "plik maski 'nazwa.bmp' ma niewłaściwy format! Wymagana jest nieskompresowana, czarno-biała bitmapa Windows 384x288 pikseli". Podobnie jak poprzednio, w komunikacie może wystapić inny plik niż maska. Należy sprawdzić, czy wymienione pliki są prawidłowe - zgodne z wymaganiami metreca i nieuszkodzone. W szczególności dotyczy to plików dark i maski. Pierwszy powinien być plikiem w pełnej rozdzielczości w skali szarości, a drugi w połowie rozdzielczości i monochromatyczny (jednobitowy). Jeśli metrec odkryje, że np. plik maski ma niewłaściwe parametry (przykładowo jest w skali szarości) - wyłączy się.
Jeśli wszystko powyższe jest w porządku a problem występuje, to prawdopodobnie metrec uważa, że patrzy w ziemię (pod horyzont). Wówczas generuje komunikat, że część pola widzenia znajduje się pod horyzontem:
"ERROR: A part of the active field of view points below the horizon! You may need an input mask to restrict the active field of view. Make sure that the time in your reference star file is given in UT and that your TimeZoneCorrection parameter is set correctly."
W tłumaczeniu komunikat brzmi: "część aktywnego pola widzenia znajduje się pod horyzontem! Należy ograniczyć pole widzenia maską. Upewnić się, że czas podany w pliku referencyjnym jest czasem UT a parametr TimeZoneCorrection (strefa czasowa) podany prawidłowo.
Może być kilka powodów takiej sytuacji.
Pierwszy to zły czas, jaki otrzymuje metrec. Wszystkie gwiazdy, pominąwszy okołobiegunowe, zachodzą. Jeśli czas jest zły, może się zdarzyć, że z danej lokalizacji stacji i czasu wynika, że gwiazdy widoczne na obrazie referencyjnym są poniżej horyzontu. Zły czas może wynikać z trzech błędów:
- złego ustawienie zegara komputera,
- niewyłączeniem w pliku .cfg poprawek czasu w związku z dryfem, czasem letnim lub strefą czasową,
- błędnym podaniem momentu wykonania obrazu referencyjnego w trakcie procedury tworzenia pliku referencyjnego.
Jeśli komputer ma ustawiony inny czas niż "czysty" UT bez uwzględniania czasu letniego - powiedzmy CEST - to metrec własnymi poprawkami stara się "odkręcić" na powrót CEST do UT. Zdarzają się przy tym rozmaite problemy, tak wynikające z błędów obserwatora jak i z bugów w samym programie.
Aby uniknąć problemów należy bezwzględnie ustawić zegar systemowy komputera na "czysty" czas UT bez czasu letniego oraz wyłączyć w pliku .cfg poprawki dodawane przez samego metreca. W komputerze należy ustawić strefę czasową Greenwich (strefa GMT) i wyłączyć uwzględnianie czasu letniego (opcje dostępne po dwukrotnym kliknięciu w zegar systemowy w prawym dolnym rogu ekranu). Na drugiej zakładce okna ustawiamy właściwą strefę i wyłączamy czas letni, na trzeciej zakładce włączamy synchronizację czasu systemowego przez internet. Dzięki temu czas systemowy będzie zawsze aktualnym czasem uniwersalnym (UT).
Aby wykluczyć natomiast błędy powodowane poprawkami dawanymi przez samego metreca (dryf, strefa, czas letni), należy upewnić się, że w pliku .cfg parametr TimeBase=1, TimeDriftCorrection=0, TimeZoneCorrection=0 oraz DSTCorrection=no . Ustawienie czasu w komputerze na UT i wyłączenie czasu letniego oraz poprawek jest jedynym pewnym sposobem na uniknięcie zawikłanych błędów pojawiających się "nie wiadomo skąd" w czasie obserwacji. Poprawienie błędów czasu w zarejestrowanych obserwacjach jest ze względu na złożoność bardzo żmudne, dlatego też bezwzględnie zalecana jest praca na "czystym" czasie UT.
Ostatnia kwestia związana z czasem to podanie właściwego momentu wykonania obrazu referencyjnego podczas tworzenia pliku referencyjnego. Refstars pyta nas, w jakiej chwili wykonano obraz referencyjny, który właśnie obrabiamy. Chodzi o dzień i moment, w którym dokonaliśmy zrzutu obrazu z matrycy modułem grab. Źródłem błędów jest próba wpisania dnia lub czasu aktualnego (w momencie jego wpisywania do refstars) lub też wpisanie czasu z innej strefy lub z inną poprawką, niż jest ustawiona w pliku .cfg. Moduł grab może wdrukować czas w obrazek (opcja -ts 2), a w każdym razie data ta i czas będą zapisane we właściwościach powstałego ze zrzutu pliku bmp. Data ta i czas odpowiadają dacie i czasowi systemowym. Jeśli więc przykładowo zrzutu dokonaliśmy mając zegar ustawiony na CEST (czas letni środkowoeuropejski), to po przestawieniu komputera na czas UT musimy uwzględnić poprawkę -2 h. Jeśli nastąpiło to do 2 godzin po północy - zmieni się także data.
Inny powód problemów z patrzeniem pod horyzont to złe współrzędne stacji. Przesunięcie w długości geograficznej o 15 stopni jest równoważne błędowi czasu 1 h, skutkującemu jak wyżej. Podobnie przesunięcie w szerokości sprawia, że zmieniają się czasy wschodów i zachodów gwiazd. Najczęstsze źródło błędu to zamiana długości geograficznej stacji z jej szerokością w pliku .osc, z którego dane te są pobierane do pliku referencyjnego. W pliku .osc najpierw powinna być wpisana długość (odmiennie od polskich zwyczajów). Typowe liczby to 21 stopni długości i 52 szerokości (dla Warszawy). Dla obszaru Polski wartości te zmieniają się w zakresie 14-24 stopni długość, 49-55 szerokość. Innym częstym błędem jest wpisanie tych danych w innym formacie niż stopień i części dziesiętne po kropce (nie przecinku, przykładowo 50 stopni 30' powinno być przekonwertowane do zapisu dziesiętnego i wpisane do pliku .osc jako 50.5). Liczby te powinny być dla Polski dodatnie (bez znaku plus). Analogicznym źródłem błędów jest pomyłka w wyborze miejsca obserwacji z gotowej listy widocznej w czasie sporządzania pliku referencyjnego w refstarsie.
Ostatni powód to faktycznie, choćby częściowo, skierowana pod horyzont kamera. Jeśli staramy się ustawić kamerę tak, aby dolny brzeg kadru pokrywał się z horyzontem to jest duże prawdopodobieństwo, że rogi kadru znajdą się na skutek dystorsji poniżej niego. Rozwiązaniem jest podniesienie kamery lub zamaskowanie (kolorem czarnym w pliku maski) pikseli, które znajdują się poniżej horyzontu. Problem ten spowoduje nawet jeden piksel znajdujący się pod teoretycznym horyzontem. Błędem skutkującym podobnie jest odwrócenie kolorów na masce maskującej części pod horyzontem - prawidłowo białe części maski są przezroczyste, czarne maskują.
Trzeba sobie uzmysłowić, że metrec nie myśli, tylko przeprowadza obliczenia na podstawie wprowadzonych danych, wg modelu. Model implementowany w metrecu nie zawiera informacji o rzeczywistym kształcie Ziemi - metrec "nie wie" tak naprawdę, jaki kształt powinien mieć horyzont w miejscu obserwacji. Jeśli horyzont będzie wyżej z powodu wysokiej góry w polu widzenia to metrec nie będzie uważał, że kamera patrzy w ziemię, a jeśli horyzont będzie obniżony poprzez umieszczenie kamery bardzo wysoko - to przeciwnie. Krótko mówiąc, jeśli metrec wyłącza się ponieważ uważa, że kamera patrzy pod horyzont - oznacza to tyle i tylko tyle, że dostarczone przez nas dane pokazują w wyniku, że promienie światła docierające do pikseli na matrycy pochodzą spod teoretycznego horyzontu.
Reasumując, źródła błędów należy szukać:
- w złych nazwach plików referencyjnego, maski i dark wpisanych do pliku .cfg lub nieobecności tych plików w folderze programu
- w złym formacie lub uszkodzeniu ww plików
- w złych współrzędnych stacji w pliku .osc (lub źle wybranego z listy miejsca obserwacji), pobranych do pliku referencyjnego
- w złym czasie wykonania obrazu referencyjnego wprowadzonym podczas tworzenia pliku referencyjnego
- w złym czasie ustawionym na komputerze, lub w źle wprowadzonych parametrach TimeBase, TimeDriftCorrection, TimeZoneCorrection lub DSTCorrection w pliku .cfg
- w niezamaskowaniu cześci pola widzenia kamery leżącego pod horyzontem lub odwróceniu kolorów maski.
Najważniejsze parametry w pliku .cfg, powiązane z tą problematyką (pozostałe wymienione są powyżej):
- UseInputMask = no (czy użyć maski, YES, jeśli zamierzamy jej użyć),
- InputMask = nazwa.bmp (nazwa pliku maski, nieskompresowana bitmapa jednobitowa 384x288 piksela)'
- DarkField = nazwa.bmp (nazwa pliku dark - zrzutu jałowego sygnału matrycy, bitmapa w pełnej rozdzielczości w skali szarości),
- ReferenceStars = nazwa.ref nazwa pliku referencyjnego.
Redukcja danych - postproc.
Obowiązkiem obserwatora jest regularne przeglądanie zapisanych danych i odrzucenie fałszywych detekcji. Służy do tego moduł postproc, który uruchamiamy z plikiem log z interesującej nas nocy jako parametrem
Program postproc posiada dużo opcji ale w wersji podstawowej wywołujemy go następująco:
ścieżka1\postproc ścieżka2\plik.log
gdzie:
- ścieżka1 - scieżka do programu postproc
- ścieżka2 - ścieżka do pliku log
Opisany wyżej sposób nie powinien być (podkreślam raz jeszcze) stosowany przy wysyłaniu danych do IMO (to zostało opisane dalej). Jeśli katalog danych jest podkatalogiem programu to ścieżka2 może być podana względnie, jeśli nie - trzeba podać pełną ścieżkę literą dysku.
Interfejs postproca składa się z dwóch zasadniczych części - po prawej stronie widzimy obrazek sumy (czyli “portret”) zjawiska - a po lewej parametry domniemanego meteoru. Jeśli postproc uważa, że jakiś parmetr odbiega od normy (co by wskazywało, że zjawisko w rzeczywistości nie jest meteorem) to podświetla go na biało.
Rys. 8 - Postproc.exe POWIĘKSZ
Redukcja danych polega przede wszystkim na wzrokowej ocenie zjawiska na obrazku sumy. Meteorami nie są:
- zjawiska, które zakręcają, przyspieszają lub zawracają (ale uwaga na dystorsję obiektywu)
- które latają w stadach
- takie, które pojawiają się “w odcinkach” co sekundę - parę sekund (ale uwaga - metrecowi zdarza się pociąć prawdziwe zjawisko)
- mające na obrazku sumy nierównomierną szerokość przerw lub jasnych miejsc (dotyczy raczej ciemnych zjawisk, a nie ewidentnie jasnych)
- samoloty, ćmy, sowy, koty, pająki i nietoperze. I śnieżynki.
W miejscach dobrze oświetlonych latarniami ulicznymi zjawiska łudząco podobne do meteorów generują obiekty przelatujące mniej więcej prostoliniowo przed kamerą - jak ptaki (w nocy widoczne jako białe punkty na czarnym tle), które postanowiły przelecieć przed kamerą bez kolegów lotem ślizgowym i po linii prostej. ćmy itp. A także śnieżynki. Innym świetnym generatorem fałszywek jest pajęczyna n wietrze, świecąca blikiem od pobliskiej latarni.
Pomiędzy zjawiskami poruszamy się za pomocą strzałek kursora góra/dół. W celu dyskryminacji zjawisk fałszywych mamy do dyspozycji kilka narzędzi. Po pierwsze możemy uczytelnić zjawisko wciskając l/L (linia obwodząca zjawisko/groty wskazujące początek i koniec). Przycisk m powoduje odtworzenie “filmu” z przelotu o szerokości kilkunastu pixeli wzdłuż osi zjawiska na tle obrazka sumy. Przycisk s spowoduje odtworzenie filmu na całym kadrze. Opcja S jak wyżej - klatka po klatce.
Wszystkimi tymi metodami powinniśmy się posiłkować - aby usunąć zjawiska fałszywe. Problem dotyczy z reguły zjawisk słabych (niezbyt jasnych). Ostatecznie możemy przejrzeć jakimkolwiek programem umożliwiającym “pokaz slajdów” pliki bmp zjawiska w oryginalnej rozdzielczości (w oknie postproca są one pomniejszone). Zwykle w rozdzielczości 1:1 szybkie oglądanie klatek jedna po drugiej pozwala wykryć machanie skrzydłami czy inne anomalie. Ostateczną metoda jest zrobienie zwolnionego filmu z dwukrotnym powiększeniem.
Symultaniczny zapis zjawisk - generowane pliki.
Stosunkowo często zdarza się, że metrec wykryje równolegle dwa zjawiska. Zdarza się w takiej sytuacji, że jedno z nich jest fałszywą detekcją, w której tle został niejako przy okazji uchwycony meteor. Jeśli w postprocu nad oknem z obrazem sumy meteoru zamiast napisu "meteor image" pojawia się na białym tle napis "nearest meteor image" - to znak, że na jednym zestawie klatek metrec wykrył więcej niż jedno zjawisko - a to, które jest aktualnie wyświetlane nie ma przypisanych własnych plików inf, bnd i bmp a istnieje wyłącznie jako linie w pliku log. Należy tej sytuacji poświęcić więcej uwagi, ponieważ kasując zjawisko fałszywe skasujemy przy okazji klatki zjawiska prawdziwego.
Jeśli metrec wykryje w małym odstępie czasu kilka zjawisk - zapisze tylko jeden zestaw klatek, jeden obraz sumy zjawiska, jeden plik inf oraz jeden bnd. Wszystkie te pliki zostaną przypisane do jednego i tylko jednego z wykrytych w tym zestawie zjawisk. Pozostałe zjawiska nie będa mieć odrębnej sumy ani pozostałych plików - będa jedynie liniami w pliku .log. Podczas redukcji w obrębie tego zestawu będziemy widzieć cały czas jeden obraz sumy zjawiska - aczkolwiek zmieniać będą położenie znaczniki meteora (l/L).
Suma, klatki i pliki przypisane są do zjawiska, nad oknem z sumą którego jest napis "meteor image". Pozostałe zjawiska z tego zestawu będa miały oznaczenie "nearest meteor image" i nie będą podczas ich wyświetlania działały opcje m, s, S (wyświetlenie filmu bądź pojedynczych klatek). Jeśli w zestawie takim prawdziwe zjawisko nie ma przypisanych plików, a są one przypisane do zjawiska fałszywego - należy pozostawić oba. Skasowanie w tej sytuacji zjawiska fałszywego spowoduje również usunięcie związanych z nim obrazów i plików - a prawdziwe zjawisko pozostanie jedynie jako linia w logu. Z punktu widzenia danych przesyłanych do PFN należy pozostawić zjawisko fałszywe, do którego przypisane są pliki jak i właściwe, uchwycone w tle. Osoby pragnące przesyłać dane do IMO powinny zaznajomić się z odmiennym sposobem postępowania w tej sytuacji (w dalszej części instrukcji)
Jeśli uznamy, że dane zjawisko jest prawdziwe - naciskamy k (keep) bądź po prostu strzałkę w dół (przechodzimy do następnego). Jeśli uważamy, że jest fałszywe - naciskamy d (delete). Po przejrzeniu całej nocy (i upewnieniu się, że niczego nie przeoczyliśmy) naciskamy escape - mamy wybór - po ponownym naciśnięciu escape wrócimy do poprzedniego okna, po wciśnięciu y zatwierdzimy zmiany - po wciśnięciu n wyjdziemy z programu bez zapisywania zmian.
Po wciśnięciu y program zapyta nas, czy chcemy uwzględnić przerwy w teff (add breaks) - wybieramy yes. Obliczanie teff działa poprawnie od wersji 5.1 pod warunkiem, że mamy dobry plik referencyjny (metrec "widzi" gwiazdy). Dla PFN teff metreca nie jest istotny, ale pozwala obserwatorowi orientować się w skuteczności stacji. NAtomiast przy wysyłaniu danych do IMO dodanie przerw do teff jest obowiązkowe. Plik referencyjny jest dobry, jeśli metrec generuje dużo pozycji w automatycznych plikach ref (patrz optymalizacja plików referencyjnych). Następnie program zapyta, czy chcemy wygenerować wykres trajektorii (plik metrad.bmp) - jest to wizualna informacja o położeniu zarejestrowanych meteorów, wyłącznie dla orientacji obserwatora.
Następnie może sie pojawić ostrzeżenie, że wygenerowana wartość fluxów sporadyków (SPO flux)jest anomalna - i pytanie, czy w związku z tym powinna być usunięta (shall lm and flux files be deleted - odpowiadamy yes) - istotne tylko przy wysyłaniu danych do IMO. Z kolei program pyta nas, czy niektóre pliki (cfg, log etc.) powinny być przeniesione do katalogu danych - JEŚLI NIE WYSYŁAMY DANYCH DO IMO - jest to bez znaczenia.
Na tym działanie postproca kończy się - aby wyjść z programu należy nacisnąć enter. Pozostaje przesyłać regularnie zredukowane dane “do centrali”.
Czasami zdarza się, że postproc z danym plikiem log nie uruchamia się - otrzymujemy komunikat o błędzie. Może to być komunikat samego postproca (pojawiający się w "czarnym okienku" w którym uruchomiliśmy program) wówczas przyczynę mamy podaną w komunikacie. Jeśli natomiast otrzymujemy komunikat Windows - to po pierwsze należy zajrzeć do pliku log i porównać go z innymi, typowymi plikami. Częstym problemem są np linie z błędami (oznaczone *WARNING*). Linie te należy wykasować. Dobrze jest zbackupować pliki, które zamierzmy ręcznie naprawiać. Jeśli wykasujemy z loga linie to później musimy ręcznie wykasować odpowiadające im pliki .bmp. .inf i .bnd. Innym problemem jest plik pozbawiony linii podsumowania (summary). W takim wypadku należy skopiować podsumowanie z innego pliku i ręcznie wprowadzić znane dane (początek i koniec obserwacji, teff) a następnie wykonać postrproc z opcjami -posdat i -count. Od wersji 5.1. dostępna jest opcja -summary, która samoczynnie odbudowuje podsumowanie.
Innym problemem może być sytuacja, kiedy z jednej nocy mamy kilka logów - z jakichkolwiek powodów metrec danej nocy restartował. Wówczas w efekcie mamy jeden katalog dzienny a nim wszystkie pliki (.bmp, .inf, .bnd i pozostałe) z całej nocy ale tylko jeden plik log - ten z ostatniego uruchomienia. Pozostałe pliki log z tej nocy dostępne są jedynie w katalogu głównym (zapisane jako log.001, log.002... patrz instalacja pakietu - pliki). Najpierw trzeba wyszukać wszystkie potrzebne pliki log i zbackupować. Załóżmy, że mamy dwa takie pliki - plki 1, wcześniejszy i plik 2 - późniejszy. Działamy wg schematu:
- z pliku 2 wyrzucamy początek łącznie z linią "start of recognition"
- resztę pliku 2 wklejamy do pliku 1 za ostatnią linią zawierającą dane meteora lub za ostatnią linią zapisu obrazka tła - zależnie co było ostatnie. Najlepiej przed wklejeniem stworzyć kilka pustych linii, aby wklejona treść była wyraźnie wydzielona
- z tej części pliku 1, która znalazła się za wklejonym plikiem 2 usuwamy wszystkie linie oprócz statystyki Będą to linie związane z kończeniem pracy programu - jeśli metrec został niewłaściwie zamknięty np. po zaniku napięcia to linii tych nie będzie - plik 1 będzie się kończył linią zapisu meteora bądź obrazka tła. Wówczas plik 2 należy wkleić na końcu
- należy poprawić jedną ze statystyk - data i godzina rozpoczęcia z pliku 1, zakończenia z pliku 2, należy zsumować teff oraz obszar detekcji (collection area). Pozostałych wartości nie poprawiać. Jeśli w pierwszym pliku brak statystyki to możemy jedynie ustalić datę i czas rozpoczęcia i przybliżony teff - biorąc jako początek godzine na początku linii "start of recognition". Po dokonaniu poprawek drugą, zbędną już statystykę usunąć. Usunąć także puste, wcześniej dodane dla orientacji miejsca. Plik powinien wyglądać jak "normlny" plik log.
- uruchomić postproc z tak utworzonym plikiem z opcjami -count i -postdat (statystyka zostanie poprawiona)
Jeśli mamy więcej plików log, to postępujemy wg powyższego schematu aż do scalenia wszystkich w jeden. Od wersji 5.1 sprawa jest uproszczona dzięki opcji -summary. Z pierwszego pliku wyrzucamy wszystko za ostatnim meteorem, a z drugiego wklejamy w to miejsce wszystko od pierwszego meteoru. Następnie używamy opcji -summary -posdat i -count.
Masowe fałszywe detekcje. Ich pojawienie się może mieć dwie podstawowe przyczyny - źle dobrany (za niski) parametr recognition threshold (poprawiamy ctrl-u, t/T, ctrl-r, ostatecznie dobraną wartość wpisujemy do cfg). Druga przyczyna to niekorzystna zmiana obserwowanego pola - pojawienie się na nim ruchomych obiektów, niemożliwych do zamaskowania, generujących fałszywe detekcje. Mogą to być poruszające się chmury czy też dym z komina. Możemy podnieść znacznie próg wykrywania (co zresztą i tak stanie się automatycznie), ale to spowoduje znaczne zmniejszenie czułości. Możemy też nic nie robić, a fałszywe detekcje odsiać przy redukcji danych. Tym niemniej przebijanie się przez kilka czy kilkadziesiąt tysięcy fałszywych zjawisk (wśród których jest np. 10 prawdziwych) to wyzwanie. Możemy ułatwić sobie pracę, wywołując najpierw postproca z opcją -maxcount m, gdzie m to liczba zjawisk występująca po sobie w czasie 3 s. Jeśli np. wpiszemy:
c:\metrec\postproc -maxcount 4 log.log
to jeśli w ciągu 3 sekund wystapią 4 zjawiska - zostaną one odrzucone. Aby stało się automatycznie wpiszemy:
c:\metrec\postproc -maxcount 4 -noint log.log
Opcja -noint spowoduje, ze cały proces odbędzie się bez naszego udziału. Generalnie pomimo wielu prób nie stwierdziłem ani razu, aby w ten sposób odrzucane były rzeczywiste zjawiska (choć jest to oczywiście możliwe). Po użyciu tej opcji z kilku tysięcy "zjawisk" zostaje kilkadziesiąt - kilkaset. Należy zwrócić uwagę, że jednorazowo postproc może obrobić 10 tysięcy zjawisk. Jeśli jest ich więcej w pliku log - postproc obrobi pierwsze 10 tysięcy. Należy wówczas opcję maxcount zastosować ponownie.
Optymalizacja plików ref.
Na początek uwaga praktyczna - zapisując plik .ref po niżej opisanej optymalizacji refstars zachowuje jego oryginalną, nienaruszoną kopię z rozszerzeniem .bak, gdyż nie ma opcji undo. Jeśli jednak będziemy zmuszeni wyjść z refstarsa poprzez zamknięcie okna krzyżykiem (np. program zawiesi się) - kopia nie zostanie zapisana. Można dość łatwo spowodować sytuację, w której kopia jeszcze nie zostanie zapisana a oryginalny plik będzie już bezpowrotnie zmieniony. Dlatego przystępując do uaktualniania pliku .ref należy zrobić jego kopię w innym miejscu dysku.
Nowy metrec w czasie pracy wykrywa gwiazdy i zapisuje ich pozycje w pliku yyyymmdd.ref w katalogu dziennym (danej obserwacji). Po pogodnej nocy może być tych pozycji tysiąc - kilkanaście - kilkadziesiąt tysięcy (zależnie od czystości nieba, sprzętu itd. - a także od jakości pierwotnego, ręcznie wyklikanego pliku ref).
Jeśli mamy taki dobry plik po pogodnej nocy - możemy go zoptymalizować, a następnie używać zamiast tego, który ręcznie wyklikaliśmy. Będzie znacznie lepszy, bo będzie zawierał kilkaset-kilka-dziesiąt tysięcy dobrych pozycji gwiazd (podczas, gdy ręcznie możemy ich wyklikać z jednego obrazka 20-50). Do optymalizacji służy opcja -update. Po wczytaniu pliku, na obrazek referencyjny nałożą się wszystkie zapisane pozycje gwiazd (jeśli jest ich dużo - chwilę to potrwa). Następnie mamy możliwość eliminacji pozycji gwiazd z błędem większym od zadanej wartości. Trzeba tylko uważać, aby nie skończyło się na tym, że zmniejszając dopuszczalny błąd wytniemy wszystkie gwiazdy z brzegów pola.
Ważne jest, aby pierwotny plik ref (ten który wyklikaliśmy sami ręcznie) był jak najlepszy. Powinien zawierać ok. 30 gwiazd możliwie na całym polu widzenia. Pierwszorzędne znaczenie ma dopasowanie siatki (order of plate constans) osiągane opcją o. Im szersze pole widzenia tym wyższy rząd równania potrzebnego do jego "spłaszczenia". Jeśli plik pierwotny (ręcznie wyklikany) będzie kiepski, metrec nie będzie rozpoznawał gwiazd, ponieważ z jego punktu widzenia będą w złych miejscach - i pliki .ref generowane podczas obserwacji będą albo puste, albo będą zawierały mało wpisów.
Normalna ilość wpisów w takim pliku po dobrej nocy to ponad tysiąc - u mnie ta liczba po pogodnej nocy trwającej circa 12 godzin zależnie od kamery waha się - od 5 do 25 tysięcy. Oczywiście składa się na to wiele czynników - w szczególności (oprócz pogody i długości nocy) - jasność obiektywu, czułość kamery i poziom jej szumów. Przy gorszym obiektywie (lub w czasie pełni) miałem wyniki rzędu 1,5 - 2 tysięcy. Dlatego też nie można podać jakiejś wartości progowej. Po prostu trzeba obserwować liczbę wpisów - powinna ona dobrze korelować z pogodą w nocy. Jeśli tak się nie dzieje i wpisów jest zawsze mało - pierwotny plik ref, ten ręcznie wyklikany - jest zły.
Wizualnie łatwo to stwierdzić obserwując w czasie pracy metreca okno z surowym obrazem z kamery (raw image), okno z wykrytymi kandydatami na gwiazdy (segmented star image) i okno z gwiazdami wykrytymi (limiting magnitude plot). Okno segmented star image pokazuje "kandydatów na gwiazdy", czyli jasne, niemal nieruchome punkty w polu kamery - możemy porównać z raw image, aby stwierdzić, które z nich są rzeczywiście gwiazdami (uwzględniając przy tym istnienie planet, mgławic etc.). Okno limiting magnitude plot pokazuje na szaro gwiazdy, które metrec powinien widzieć, a na biało zaś te, które widzi (widzi - to znaczy, że kandydat na gwiazdę znajduje się w danej chwili dokładnie w miejscu, w którym pasuje do siatki z pliku referencyjnego). Pozycja gwiazdy wynikająca z siatki oznaczona jest wielokątem, zaś wykryta krzyżykiem. Jeśli plik referencyjny jest dobry a niebo czyste, to większość punktów w oknie limiting magnitude plot powinna być biała (a krzyżyki wewnątrz wielokątów). Jeśli zaś są wykryci kandydaci na gwiazdy a nie ma wykrytych gwiazd - to znaczy, że plik referencyjny jest zły. Metrec dopuszcza tutaj pięciokrotna wartość średniokwadratowego błędu zestawu gwiazd jako limit dopasowania. Krótko mówiąc jeśli sami zawalimy robotę, to metrec za nas jej nie poprawi - wówczas nie ma czego optymalizować - trzeba jeszcze raz, porządnie zrobić podstawowy, ręcznie wyklikiwany plik ref.
Aby zoptymalizować istniejący plik yyyymmdd.ref uruchamiamy program refstars z opcją -update:
refstars -update plik.bmp ścieżka\yyyymmdd.ref
gdzie:
- plik.bmp - jakikolwiek* plik bmp o parametrach właściwych dla refstarsa (tzn. w skali szarości, zmniejszony do polowy rozdzielczości - może być zdjęcie koleżanki)
- ścieżka - miejsce, gdzie znajduje się plik ref, który chcemy obrobić (to znaczy plik ref wygenerowany przez metreca podczas nocy i zapisany w katalogu dziennym danej obserwacji - a nie plik ref, który ręcznie wyklikaliśmy
- yyyymmdd.ref - nazwa pliku, który chcemy załadować.
*Uwaga o ładowaniu "jakiegokolwiek" pliku .bmp dotyczy sytuacji, kiedy z istniejącego pliku yyyymmdd.ref chcemy usunąć pozycje gwiazd z największym błędem a nie dodawać do niego nowe z nowego obrazka referencyjnego. Dla porządku wspominam, że ta druga opcja również jest możliwa - wówczas oczywiście obrazek ma być konkretnym obrazkiem zrobionym grabem a nie "jakimkolwiek". Wtedy także jest sens użyć innych opcji (załadować więcej obrazków referencyjnych i załadować maskę) - ale jeśli chodzi tylko o usuwanie pozycji gwiazd z największym błędem z pliku ref wygenerowanego przez metreca podczas pogodnej nocy - nie ma to znaczenia.
Nie wolno nic zmieniać w odpowiedzi na pojawiające się po wczytaniu komendy pytania (miejsce obserwacji, data, rozmiar pola, próg wykrywania gwiazd, orientacja na niebie etc.) - wciskamy enter, enter, enter - aż dojdziemy do głównego okna, w którym normalnie wyklikuje się gwiazdy. Kiedy już przebrniemy przez powyższe standardowe pytania początkowe wyświetli się załadowany obrazek, na który czarnymi krzyżykami zostaną naniesione wszystkie pozycje gwiazd, jakie zostały zapisane w pliku .ref, który wczytaliśmy (może to chwilę potrwać i obrazek może się zaczernić). Nasza rola nie polega tym razem na wskazywaniu gwiazd - a na ich usuwaniu poprzez zdefiniowanie maksymalnego błędu, z jakim może być określona pozycja gwiazdy. Dostępne są te same narzędzia co dotychczas (wszystko działa dokładnie tak samo), opcje które nas interesują to L, D.
Opcja SHIFT-L usuwa pozycje gwiazd z błędem pozycji większym niż przez nas zadany. Błąd średniokwadratowy L1O całego zestawu gwiazd jest widoczny po wczytaniu pliku w środkowym panelu lewej kolumny programu (mean squared L1O position error) w postaci liczby z apostrofem (np 7.30' - minuty kątowe). Jeśli z tego zestawu chcemy usunąć wszystkie pozycje gwiazd, dla których ich własny błąd jest większy od powiedzmy 10.00' - przyciskamy L a następnie po monicie programu (please enter the maximum L1O position error: _) wpisujemy 10 [enter]. Zwykle wyliczony następnie nowy błąd średniokwadratowy jest wyraźnie mniejszy, niż wprowadzone kryterium maksymalne - wyniesie np. 5.00'.
Optymalizując plik nie należy przesadzać. W zestawie są zapewne pozycje gwiazd z błędem L1O 20' czy nawet 30+'. Zaczynamy więc od ograniczenia wielokrotnie większego od wyświetlanego błędu zestawu - np. właśnie od 10'. Posuwamy się zmniejszając limit aż doprowadzimy do usunięcia około 10% gwiazd z pierwotnej puli - i nie więcej. Ostateczny błąd wyjściowy zestawu L1O powinien wynosić około 5'. Najlepiej osiągnąć to w jednej operacji. Ponieważ refstars nie ma undo, skazani jesteśmy na metodę prób i błędów, a ponieważ należy to zrobić w jednej operacji, to w efekcie najpewniejszym sposobem jest restartowanie refstarsa od nowa z tym samym plikiem - aż utrafimy we właściwą wartość nakładanego ograniczenia. Tutaj właśnie może się przydać niezależne backupowanie tego pliku. Od wersji 5.1 wprowadzono ułatwienie - po podaniu limitu błędu pojawia się komunikat, jaki procent gwiazd zostanie usunięty i jeśli przekracza on 10% możemy się wycofać i podać wyższy limit.
Jeśli bardzo szybko tracimy gwiazdy z krawędzi - może oznaczać to, że źle wybraliśmy stopień równania opisującego siatkę, kiedy wykonywaliśmy refa ręcznie - można to próbować poprawić (opcja o) ale niewiele to da, bo z powodu złej siatki metrec nie rozpoznawał gwiazd w pobliżu krawędzi pola i w związku z tym nie zapisał ich do pliku.
Jeśli wszystko jest już OK to wychodzimy przyciskiem escape - refstars zapyta, czy chcemy zakończyć pracę z tym obrazkiem, co potwierdzamy. Następnie pojawi się komunikat, że dane zostały zapisane do pliku yyyymmdd.ref - tego, który wczytaliśmy, do tej samej lokalizacji. Refstars zapyta, czy ma w pliku metrec.cfg wprowadzić plik data.ref jako referencyjny - odpowiadamy no. Odpowiedź yes nie warunkuje automatycznie wprowadzenia nazwy zoptymalizowanego przed chwilą pliku do metrec.cfg w katalogu głównym - a więc nie warunkuje automatycznie, że przy następnych uruchomieniach zoptymalizowany własnie plik zostanie przez metreca użyty jako referencyjny.
Wiąże się to z tym, że jeśli obsługuje się program zgodnie z założeniami Sirko to po każdej redukcji w katalogu dziennym zapisywane są pliki ważne dla niego przy dalszym opracowaniu obserwacji - między innymi kopiowany tam jest plik konfiguracyjny metreca z katalogu głównego, z nazwą zmienioną na yyyymmdd.cfg. Jeśli na powyższe pytanie odpowiemy yes, to zapisywany plik ref zostanie wpisany do tegoż yyyymmdd.cfg jako plik referencyjny. Ale uwaga - po pierwsze warunkiem jest, aby w tym samym katalogu co plik ref był plik cfg (co ma miejsce, o ile odpowiedzieliśmy yes na pytanie o przekopiowanie niektórych plików podczas redukcji danej nocy), a po drugie nawet jeśli ten plik tam jest to jako położony (jak i yyyymmdd.ref) w katalogu dziennym danej obserwacji nie będzie miał wpływu na pracę metreca. Nie należy więc korzystać z tej opcji, a zwyczajnie przekopiować zoptymalizowany plik ref do katalogu głównego programu i ręcznie dopisać go w naszym pliku cfg.
Przesyłanie danych do IMO.
Przesyłając wyniki obserwacji do IMO stwarzamy PFN-owi szansę uczestniczenia w obróbce danych z zasobów tej organizacji, gra więc warta jest świeczki. Trzeba sobie jednak na początku uświadomić, że chcąc przesyłać dane do IMO musimy się całkowicie podporządkować filozofii działania tamtej sieci. Należy zdać sobie sprawę, że metody stosowane przez PFN i IMO sa diametralnie odmienne. Sieć IMO bazuje na danych liczbowych, generowanych przez metreca w czasie obserwacji oraz postproca w czasie redukcji - pojedyncze klatki ze zjawisk mają być usunięte przed przesłaniem, a obrazki sum przyjmowane są w rozdzielczości 50% (284x288). Sieć PFN przeciwnie, bazuje przede wszystkim na analizie pojedynczych klatek poszczególnych zjawisk. Redukcja danych w sieci PFN jest w zasadzie jedynie prostą dyskryminacją zjawisk fałszywych - zaś prawdziwa analiza przeprowadzana jest "w centrali". W sieci IMO wręcz odwrotnie - redukcja jest podstawowym zadaniem obserwatora, a od sposobu jej przeprowadzenia zależy całkowicie jakość danych jakie otrzyma IMO. Wynika z tego konieczność dwukrotnej redukcji danych: pierwszy raz dla PFN, a po ich przesłaniu bądź zarchiwizowaniu - powtórnie dla IMO.
Przesyłanie danych do IMO ma dwa etapy. Pierwszy z nich to przesyłanie aktualnych fluksów rojów, w trakcie każdej redukcji. Ta faza wymaga jedynie konfiguracji plików (niżej opisanej) i odbywa się podczas codziennej, zwykłej (to jest przeprowadzanej w sposób typowy dla PFN) redukcji. Drugi etap polega na jednorazowym, raz na miesiąc, przesłaniu kompletu danych do IMO - i to te dane muszą być zredukowane po raz drugi, w sposób wymagany w IMO.
Podstawowe wymagania obejmują:
- koniecznośc uzyskania kodu IMO stacji
- prawidłowe wypełnienie plików mających związek z generowaniem plików dla IMO (m. in. refstars.osc, postproc.vmo)
- korzystanie z plików log z katalogu głównego postaci log.log, log.000, log.001 ... log.n - a nie z pliku log.log z katalogu dziennego
- zastosowanie innych reguł redukcji m. in. dla zjawisk podwójnych, przy drugiej redukcji przed comiesięcznym przesłaniem danych
- preparację danych przed comiesięcznym wysłaniem (usunięcie pojedynczych klatek, zmianę rozdzielczości obrazków sum itd.)
Wdrożenie innego podejścia do danych nie jest szczególnie trudne - o ile od początku zdajemy sobie sprawę, z czego te różnice się biorą i dlaczego należy postępować w taki a nie inny sposób. Pakiet metrec jest rozwijany od kilkunastu lat i jako taki ma wypracowaną własną filozofię z pewnymi zaszłościami, niezupełnie czytelną, szczególnie jeśli użytkownik jest przyzwyczajony do jego obsługi w sposób, w jaki robimy to w PFN. Kwestie zupełnie nieistotne dla PFN są żywotne dla IMO. Dla przykładu, jeśli wysokość stacji nad poziomem morza zostanie wpisana do pliku osc z wartościami dziesiętnymi po przecinku (to jest po kropce) to kod IMO stacji nie zostanie przez refstars przeniesiony z pliku osc do pliku ref. Jeśli nie będzie go w pliku ref - nie zostanie uwzględniony w plikach dziennych generowanych z obserwacji, jak log, dzienny ref oraz pliki posdat. To z kolei spowoduje konieczność manualnej korekty wszystkich obserwacji przez Sirko (ze stosownym komentarzem zwrotnym). Podobnie się stanie, jeśli w ogóle kodu tego nie wpiszemy w linię w pliku osc.
Plik postproc.vmo
Żeby móc przesyłać dane do IMO trzeba po pierwsze napisać w tej sprawie do Sirko (podając mu nazwy kamer), aby założył dla nas katalogi na serwerze, na który który wędrować będą nasze wyniki. Otrzymamy także kod miejsca obserwacji (sitecode) do wpisania w pliku refstars.osc. Następnie należy wpisać swoje dane do pliku postproc.vmo. Postproc.vmo znajduje się w głównym katalogu metreca. Jest to plik (mimo innego rozszerzenia) tekstowy. Domyślnie są tam dane Sirko, które należy zastąpić (chyba, że napisałem przy danej pozycji by zostawić) swoimi.
Sekcja dotycząca samej (pojedynczej) kamery to:
! Camera n specific data gdzie n to numer kolejny naszej kamery.
Wszystkie parametry dotyczące danej kamery mają ten numer jako ostatnie dwa znaki swojej nazwy. Jest niezwykle istotne, aby ten plik wypełnić starannie, gdyż dane czerpane z tego pliku umieszczane są w innych wysyłanych do IMO - w razie problemów (w sprawie których napisze do nas Sirko) ręczne poprawianie wpisów w kilku plikach z każdej nocy jest dość niewdzięczne.
Sekcji powinno być tyle (numerowanych 01, 02, 03, ...), ile kamer (w pliku domyślnie są cztery). Niepotrzebne sekcje można wykasować. Jeśli mamy jedną kamerę - wypełniamy pierwszą sekcję, resztę możemy wykasować. Jeśli mamy kilka zestawów kamera-komputer, to albo na każdym mamy inny plik .vmo z wypełnioną pierwsza sekcję (z właściwą nazwą kamery), reszta wycięta - albo tworzymy jeden wspólny plik, w którym będą wszystkie nasze kamery i umieszczamy jego kopię na każdym kompie. Wersji z kilkoma kamerami na jednym komputerze nie testowałem, ale zapewne trzeba je wszystkie wpisać do jednego pliku vmo. W pliku, za wykrzyknikami są komentarze, nie czytane przez program. Ważne jest, aby każdy parametr był w osobnym wersie.
| ! Default data for observation upload to archive server | |
| ArchiveServer www.meteoros.de | ! name of archive server - zostawić |
| ArchiveUser ftp | ! ftp user - zostawić |
| ArchivePassword sirko@molau.de | ! ftp password - nasz adres e-mail |
| ArchiveUploadDir /me/meteoros.de/incoming | ! upload directory of ftp server - zostawić |
| ! Data for upload of flux files | |
| FluxServer vmo.imo.net | ! name of flux server - zostawić |
| FluxForm vo/postflx? | ! name of flux form - zostawić |
| ! Camera 01 specific data - dane 1 kamery | |
| ObserverFirstName01 Sirko | ! first name of observer - imię obserwatora |
| ObserverMiddleName01 | ! middle initials of observer (empty if none) pierwsza litera drugiego imienia (puste, jeśli nie ma) |
| ObserverLastName01 Molau | ! last name of observer - nazwisko |
| ObserverCode01 MOLSI | ! IMO code of observer - kod imo (3 pierwsze litery nazwiska i 2 imienia) |
| ReporterFirstName01 | ! first name of reporter (empty if equal to observer) - imię przesyłającego dane (puste, jeśli przesyła obserwator) |
| ReporterMiddleName01 | ! middle initials of reporter (empty if equal to observer) - pierwsza litera drugiego imienia przsyłającego dane (puste jeśli j.w.) |
| ReporterLastName01 | ! last name of reporter (empty if equal to observer) - nazwisko przesyłającego dane (puste jeśli j.w.) |
| ObservingSiteName01 Seysdorf | ! name of observing site - nazwa miejsca obserwacji |
| ObservingSiteCountry01 Germany | ! country of observing site - kraj obserwacji |
| CameraName01 MINCAM1 | ! name of camera - nazwa kamery |
| CameraType01 Mintron 12V1 EX | ! type of camera - typ kamery |
| IntensifierType01 none | ! type of image intensifier or none typ wzmacniacza światła lub jeśli nie ma none |
| LensType01 Computar HG 0808 AFCS | ! type of lens - typ obiektywu |
| LensFocalLength01 8 | ! focal length of lens (in mm) - ogniskowa obiektywu w mm |
| LensFStop01 0.8 | ! f-stop of lens - przysłona obiektywu (kropka, nie przecinek!) |
| ! Camera 02 specific data - dane II kamery itd. |
Istotne jest, przy wywoływaniu polecenia postproc, korzystanie z plików log zapisanych w katalogu programu (log.log, log.001, log.002... itd.) a nie z plików log.log z katalogu dziennego danej obserwacji. Dotyczy to również pierwszej redukcji, wykonywanej na potrzeby PFN. Cały proces mimo udogodnień poczynionych ostatnio przez Sirko wymaga nieco pracy i dodatkowego czasu.
Codzienne przesyłanie danych polega na uruchomieniu postproca z parametrem -uploadflx c , gdzie c to nazwa kamery jaką wstawiliśmy w pliku postproc.vmo. Załóżmy, jeśli mamy kamerę pav35 to komenda powinna być:
postproc -uploadflx pav35 xxx.log (gdzie xxx.log to nazwa właściwego pliku log z katalogu głównego programu - 001.log, 002.log itd.)
Warunkiem skutecznego przesłania danych (codziennych - fluksów) do IMO jest odpowiedź YES na pytanie, czy chcemy przenieść niektóre pliki wynikowe (m.in. config, log, maskę i postdat) do katalogu danych (ostatnie pytanie przy codziennej redukcji danych). Jeśli odpowiemy NO - zostanie przeprowadzona "normalna redukcja" bez wysyłania danych. Jeśli YES - zobaczymy jak pokazują się kolejne linie (tworzenie zipa, przesyłanie itd.). Kiedy wyjdziemy z postproca (trzeba jeszcze raz stuknąć enter) - pojawi się informacja o udanym przesłaniu danych (everything OK...). Efektem wysłania danych do IMO będzie (z naszego punktu widzenia) przeniesienie wyżej wymienionych plików do katalogu dziennego obserwacji - oraz, co istotne - zniknięcie z katalogu programu pliku xxx.log, który podaliśmy w poleceniu uruchamiającym postproca jako parametr. Plik ten pojawi się natomiast w katalogu dziennym jako yyyymmdd.log.
Jeśli pojawi się potrzeba ponownego uruchomienia postproca z plikiem log przeniesionym już do katalogu dziennego (yyyymmdd.log) - w sytuacji, kiedy już wykonaliśmy raz redukcję jak wyżej - konieczne jest użycie w komendzie parametru -archive, aby poprawnie załadowały się obrazki.
postproc -archive ścieżka\yyyymmdd.log (gdzie ścieżka wiedzie do aktualnego położenia danego katalogu dziennego).
Korzystając z parametru archive możemy też nadpisać wysłane wcześniej fluksy (jeśli np. odkryliśmy błędy). Wówczas wpiszemy:
postproc -archive -uploadflx c ścieżka\yyyymmdd.log (gdzie c to nazwa kamery z pliku vmo)
W ten sposób wysyła się codziennie "fluksy" a raz na miesiąc trzeba wysłać pozostałe dane. "Pozostałe" w tym wypadku to wszystkie pliki zapisane w poszczególnych katalogach dziennych - wg standardu IMO.
Redukcja danych przed comiesięcznym przesłaniem do IMO.
W trakcie ponownej redukcji należy dopilnowac, aby został zaktualizowany teff oraz usunięte fluxy, jeśli są mniejsze od 10 lub większe od 100 (pojawia się stosowne ostrzeżenie przy zakończeniu redukcji danych). W przeciwnym wypadku co miesiąc będziemy otrzymywać laurkę od Sirko... Podkreślam, że redukcję dla IMO należy robić dopiero po przesłaniu bądź zarchiwizowaniu do osobnego folderu danych przeznaczonych dla PFN. Redukcja wykonana zgodnie z wymogami IMO usuwa część wartościowych z punktu widzenia PFN danych.
Redukcję powtórną wykonujemy stosując inne kryteria niż w PFN w stosunku do zjawisk problematycznych, jak meteory uchwycone w tle bądź pocięte (jeden meteor zapisany jako dwa lub więcej zjawisk).
Przed przejściem dalej należy zaznajomić się ze sposobem w jaki metrec generuje pliki wynikowe i linie w logu przy symultanicznym wykryciu dwóch lub więcej zjawisk. Zrozumienie tego procesu jest bardzo istotne dla prawidłowej, powtórnej redukcji danych, które mają być wysłane do IMO. Możemy mieć do czynienia z następującymi sytuacjami:
- Jeden meteor, pocięty przez metreca, zapisany w logu jako dwa (lub więcej) odrębne zjawiska, z których każde ma własną sumę i pozostałe pliki (inf, bnd i pojedyncze klatki). Z takiego zjawiska pozostawiamy tą część, która jest najdłuższa
- Meteor, zapisany w tle fałszywej detekcji. Na sumie jest zaznaczony jako meteor (oznaczony markerami), jednak suma jest opisana na górze jako "nearest meteor image". Oznacza to, że meteor istnieje tylko jako linie w logu, zaś suma oraz pozostałe pliki zostały przypisane do fałszywej detekcji. Należy usunąć fałszywą detekcję, pozostawiając prawdziwą.
- Meteor zapisany w tle fałszywej detekcji - nie rozpoznany przez metreca. Nie został zapisany do loga, nie jest oznaczony na sumie markerami, istnieje jedynie na sumie i poszczególnych klatkach. Zjawisko należy usunąć.
- Prawdziwy meteor z ewidentnie fałszywie wyznaczoną trajektorią (markery nie pokrywają się ze zjawiskiem) - należy użyć opcji blink (klawisz b) w postprocu, pokazuje ona lepiej wyznaczoną trajektorię na tle gwiazd. Jeśli nadal jest ona fałszywa - zjawisko skasować.
- Brak statystki na końcu loga (program zamknął się nieprawidłowo). Statystykę należy odbudować: fluxów nie da się odtworzyć, teff należy policzyć ręcznie jak najdokładniej, następnie należy ponownie uruchomić postproca z użyciem opcji -posdat i -count (poprawi to bazę danych oraz policzy meteory). Od wersji 5.1 statystyka jest odbudowywana automatycznie po użyciu w refstarsie opcji -summary (patrz łączenie logów
).
Po dokonaniu powtórnej redukcji (zabiera ona dużo mniej czasu niż ta pierwsza, cały miesiąc można z łatwością obrobić w kilka minut), należy przygotować dane do wysyłki do IMO. Musza one zachować standard, jakiego wymaga ta organizacja. Standard ten oznacza:
- usuniecie plików obcych (jak np. nasze z indry)
- usunięcie pojedynczych klatek (single frames, czyli plików hhmmssxx.bmp)
- usunięcie plików tła (backgroundów)
- konwersję obrazków sum i filmów .bnd programem redres.exe do rozdzielczości full (tzn 50%, chyba, że ktoś w takiej działa, wówczas sumy są oczywiście od razu w dobrej rozdzielczości).
Reasumując, pliki, które z poszczególnych katalogów dziennych powinny zostać wysłane to:
- *.bmp (tylko sumy i maska)
- *.flx
- *.dbf
- *.bnd
- *.inf
- *.cfg
- *.log
- *.mag
- *.vmo
Ponieważ ręczna robota byłaby wielce mozolna stworzyłem skrypt (czeka na prawdziwego programistę :) ). Skrypt kopiuje do podkatalogów katalogu [mettemp] tylko sumy, maskę i resztę potrzebnych plików (*.flx, *.dbf, *.bnd, *.inf, *.cfg, *.log, *.mag, *.vmo), oraz redukuje rozdzielczość beempów. Chciałem też uniknąć konieczności wklepywania każdej daty z osobna, więc trzeba tylko podać miesiąc, o który nam chodzi. W efekcie w katalogu [mettemp] tworzone są kopie katalogów dziennych z danego miesiąca, zawierające wyłącznie pożądane przez IMO pliki. Ostatnim krokiem jest zrobienie z tego wszystkiego zipów (jedna noc - jeden zip) i wysłanie ftp na serwer www.meteoros.de.
Dane należy przekopiować do katalogu metdata. W ten sposób dane PFN pozostaną bezpieczne i nienaruszone. Następnie należy przeprowadzić w katalogu metdata powtórną redukcje wg standardów IMO. Po czym użyć skryptu, w efekcie czego w katalogu mettemp utworzone zostaną dane gotowe do wyłania do IMO.
Skrypt zawiera 31 razy powtórzoną jedną frazę z drobnymi modyfikacjami:
@if not exist e:\metdata\2011%101 goto 2
mkdir e:\mettemp\2011%101
copy e:\metdata\2011%101\??????.bmp e:\mettemp\2011%101
copy e:\metdata\2011%101\*.flx e:\mettemp\2011%101
copy e:\metdata\2011%101\*.dbf e:\mettemp\2011%101
copy e:\metdata\2011%101\*.bnd e:\mettemp\2011%101
copy e:\metdata\2011%101\*.inf e:\mettemp\2011%101
copy e:\metdata\2011%101\*.ref e:\mettemp\2011%101
copy e:\metdata\2011%101\*.cfg e:\mettemp\2011%101
copy e:\metdata\2011%101\*.log e:\mettemp\2011%101
copy e:\metdata\2011%101\*.mag e:\mettemp\2011%101
copy e:\metdata\2011%101\*.vmo e:\mettemp\2011%101
redres e:\mettemp\2011%101
:2
@if not exist e:\metdata\2011%102 goto 3
mkdir e:\mettemp\2011%102
copy e:\metdata\2011%102\??????.bmp e:\mettemp\2011%102
copy e:\metdata\2011%102\*.flx e:\mettemp\2011%102
copy e:\metdata\2011%102\*.dbf e:\mettemp\2011%102
copy e:\metdata\2011%102\*.bnd e:\mettemp\2011%102
copy e:\metdata\2011%102\*.inf e:\mettemp\2011%102
copy e:\metdata\2011%102\*.ref e:\mettemp\2011%102
copy e:\metdata\2011%102\*.cfg e:\mettemp\2011%102
copy e:\metdata\2011%102\*.log e:\mettemp\2011%102
copy e:\metdata\2011%102\*.mag e:\mettemp\2011%102
copy e:\metdata\2011%102\*.vmo e:\mettemp\2011%102
redres e:\mettemp\2011%102
... dalsze etykiety od :3 do :30 ...
:31
@if not exist e:\metdata\2011%131 goto end
mkdir e:\mettemp\2011%131
copy e:\metdata\2011%131\??????.bmp e:\mettemp\2011%131
copy e:\metdata\2011%131\*.flx e:\mettemp\2011%131
copy e:\metdata\2011%131\*.dbf e:\mettemp\2011%131
copy e:\metdata\2011%131\*.bnd e:\mettemp\2011%131
copy e:\metdata\2011%131\*.inf e:\mettemp\2011%131
copy e:\metdata\2011%131\*.ref e:\mettemp\2011%131
copy e:\metdata\2011%131\*.cfg e:\mettemp\2011%131
copy e:\metdata\2011%131\*.log e:\mettemp\2011%131
copy e:\metdata\2011%131\*.mag e:\mettemp\2011%131
copy e:\metdata\2011%131\*.vmo e:\mettemp\2011%131
redres e:\mettemp\2011%131
:end
@echo ZROBIONE!
W powyższym kodzie:
- 2011 to rok, z którego dane skrypt ma przerabiać - należy zamienić na rok aktualny
- e:\metdata oznacza katalog, w którym znajdują się podkatalogi dzienne danych po redukcji
- e:\mettemp oznacza katalog, w którym powstaną kopie tych podkatalogów na potrzeby IMO
- 35m.bmp to (w moim przypadku) nazwa pliku maski (wyciąć, jak ktoś nie używa).
Całość (po uzupełnieniu brakujących etykiet, zamianie nazw folderów na wam odpowiadające (metodą znajdź i zamień) - oraz zamianie roku należy zapisać jako plik tekstowy (z rozszerzeniem .txt) a następnie zmienić rozszerzenie na .bat (plik wykonywalny). Wywołanie (w oknie dosowym) polega na wpisaniu nazwy tego pliku plus po spacji dwucyfrowe oznaczenie miesiąca. Plik należy wywoływać z folderu, w którym się znajduje.
Dla porządku dodam, że istnieje metoda na codzienne wysyłanie tych danych parametrem -upload c z postproca przy redukcji - niestety pozostaje problem "obcych" (czyli naszych) plików indry. Reszta się wówczas robi w locie i nie narusza plików w folderze. Napisałem do Sirko, żeby wprowadził zmianę powodującą, aby przy zastosowaniu tego sposobu na serwer były wysyłane jedynie pliki jemu potrzebne - zobaczymy, czy coś z tego wyniknie...
- Zaloguj się by odpowiadać
Polish
English