Działająca przez WWW przeglądarka do plików FITS dla eksperymentu π of the Sky.

Transkrypt

1 Marcin Krzysztof Mazur Działająca przez WWW przeglądarka do plików FITS dla eksperymentu π of the Sky. Praca dyplomowa inżynierska pod kierunkiem doc. dr inż. Tomasza Traczyka Instytut Automatyki i Informatyki Stosowanej Politechniki Warszawskiej Warszawa, Czerwiec 2009

2 Spis treści Wprowadzenie 3 Cel pracy Motywacja Wymagania Projekt π of the Sky Cel projektu Główne działania projektu Obserwacja błysków gamma Wykrywanie pozostałych zjawisk astrofizycznych Największe osiągnięcie projektu Miejsce tej pracy w projekcie π of the Sky Standard FITS Struktura plików FITS Nagłówek bloku danych Format wartość przechowywanych w tabeli podstawowego bloku danych Pliki FITS używane w projekcie π of the Sky Format zapisu obrazu Fragmenty obrazów Używane słowa kluczowe Paczki obrazów Opis zaimplementowanej przeglądarki plików FITS Wybrana technologia i wykorzystywane biblioteki Struktura aplikacji Reprezentacja obrazu Przetwarzanie list plików Pobieranie paczek plików oraz plików FITS Możliwość rozszerzenia aplikacji

3 3.4 Przekazywanie parametrów apletowi Połączenie z bazą danych projektu Zastosowane metody i algorytmy Korekcja kontrastu obrazu Korekcja gamma obrazu Sposób wykonywania operacji graficznych na obrazie Algorytm wyznaczania współrzędnych niebieskich Podsumowanie 49 2

4 Wprowadzenie Cel pracy Celem pracy jest stworzenie narzędzia, działającego jako usługa WWW, umożliwiającego przeglądanie obrazów zapisanych w formacie FITS. Format ten stosowany jest w celu przechowywania oraz transmitowania obrazów pozyskanych w celach naukowych. Narzędzie ma pozwolić przede wszystkim na oglądanie zdjęć w szesnastobitowej skali szarości. Aplikacja powinna pozwalać na wykonywanie podstawowych operacji graficznych oraz powinna zapewniać możliwość poprawy jakości wyświetlanych obrazów poprzez udostępnienie odpowiednich metod przetwarzania obrazu. Ponieważ implementowany program tworzony jest na potrzeby eksperymentu π of the Sky musi on być dostosowany do plików FITS, używanych w projekcie oraz do formy ich przechowywania. Program powinien również dać się dostosować do istniejącego już interfejsu WWW projektu. Dodatkowym celem jest zapewnienie możliwości porównania informacji zawartych na przetwarzanym zdjęciu z dotychczas zgromadzonymi przez projekt danymi, przez połączenie z roboczymi bazami danych eksperymentu. Motywacja Istnieje duża liczba programów umożliwiających prezentacje oraz przetwarzanie obrazów zapisanych w formacie FITS. Do najbardziej rozpowszechnionych można zaliczyć takie przeglądarki jak SAOImage ds9, Iris, audela. Oprócz nich istnieją także aplikacje działające przez WWW, np. SIP (Sky Image Processor) oraz BRT Fits Viewer. Są to w większości ogólnie dostępne darmowe aplikacje. Jednakże nie posiadają one pełnej funkcjonalności zawiązanej z plikami FITS używanymi w projekcie π of the Sky. Przede wszystkim nie dostarczają funkcji związanych z wyznaczaniem współrzędnych niebieskich punktu na obrazie, na podstawie danych zawartych w nagłówkach plików pochodzących z teleskopu eksperymentu, oraz nie są w stanie połączyć się z bazą danych projektu. Głównym zadaniem aplikacji ma być usprawnienie czynności mających na celu weryfikację czy wykry- 3

5 te przez teleskop projektu zdarzenie jest zjawiskiem astrofizycznym czy też nie. W przypadku używania jednego z wyżej wymienionych programów, osoba analizująca dane zmuszona jest najpierw pobrać tzw. paczkę na lokalny komputer, zdekompresować ją oraz zdearchiwizować. Dopiero wtedy może przeglądać zdjęcia obrazujące zaobserwowane zjawisko astrofizyczne przez ręczny wybór plików wchodzących w skład listy opisującej jedno zjawisko. Zaimplementowana tu przeglądarka robi to tymczasem automatycznie przez pobranie paczki spod danego adresu URL i samodzielne wykonanie procesu dekompresji i dearchiwizacji. Następnie wyświetlane jest okno wyboru plików list pozwalające na dodanie plików znajdujących się na liście do okna nawigacji programu. Dzięki temu użytkownik może przeglądać obrazy przedstawiające wybrane zdarzenia przez wybór pozycji w oknie nawigacji aplikacji. Wymagania Przed aplikacją postawiono następujące wymagania: Prezentacja obrazu zapisanego w podstawowym bloku pliku FITS: w szesnastobitowej skali szarości, w dowolnym formacie lub z możliwością rozszerzenia aplikacji tak, aby można było spełnić tę funkcjonalność. Wykonywanie następujących operacji graficznych, na aktualnie wyświetlanym obrazie: skalowania, odbicia względem osi OX i osi OY kartezjańskiego układu współrzędnych, powiększania zaznaczanego fragmentu zdjęcia. Implementacja metod przetwarzania obrazu w celu korekcji kontrastu: automatycznej metody poprawy kontrastu stosowanej podczas wyświetlania zdjęcia, metod, które umożliwią ręczną korekcję przez użytkownika. Wyświetlanie oryginalnej wartości piksela obrazu i odpowiadających mu współrzędnych (x, y) oraz współrzędnych niebieskich. Otwieranie plików przetwarzanych przez aplikacje spod zadanego adresu URL. 4

6 Zapisywanie przetwarzanego obrazu do innych plików graficznych takich jak: JPG, BMP, GIF, PNG. Przetwarzanie list plików oraz paczek plików: utworzenie okna nawigacji po plikach w interfejsie użytkownika aplikacji, utworzenie przycisków w interfejsie użytkownika, umożliwiających nawigację po plikach. Połączenie z bazą danych projektu i pobranie spisu gwiazd znajdujących się na wyznaczonym obszarze przetwarzanego zdjęcia. Dodatkowym wymaganiem, jakie zostało określone po wyborze technologii wykonania programu, było jego zaimplementowanie w formie apletu Javy oraz w formie analogicznej aplikacji, napisanej również w języku Java. 5

7 Rozdział 1 Projekt π of the Sky 1.1 Cel projektu Celem projektu π of the Sky jest obserwacja optyczna nieba w krótkich skalach czasowych. Dzięki obserwacji nieba można zarejestrować szereg zjawisk astrofizycznych, które pomagają zrozumieć procesy zachodzące we Wszechświecie oraz są podstawą do wyjaśnienia początku Wszechświata. Podstawowym obiektem zainteresowania projektu jest obserwacja optycznych odpowiedników błysków gamma (ang. Gamma Ray Burst GRB). Istnienie błysków zostało odkryte przypadkowo przez amerykańskiego satelitę Vela w okresie zimnej wojny. Zadaniem satelity była obserwacja nieba w poszukiwaniu testów broni jądrowej wykonywanych przez Związek Radziecki. Nie wykryto wówczas testów nuklearnych, ale zauważono istnienie źródeł promieniowania gamma w kosmosie. Błyski gamma są dotychczas uważane za zjawiska emitujące największą energię we Wszechświecie, których źródła znajdują się w odległych galaktykach. Dzieli się je na dwie kategorie: krótkie błyski trwające mniej niż 2 s i długie błyski trwające dłużej niż 2 s. Energia emitowana przez krótki błysk szacowana jest na około erg 1, natomiast energia emitowana podczas długiego błysku szacowana jest na około erg i można ją porównać do energii jaką emituje Słońce podczas 10 mld lat świecenia. Za przyczynę długiego błysku uważa się eksplozję ogromnych gwiazd, których masa jest nawet 30 razy większa niż masa Słońca. Ich eksplozja jest wynikiem przeważenia ciśnienia wewnątrz gwiazdy powodowanego przez reakcje termojądrowe przez ciśnienie powodowane przez siłę grawitacji gwiazdy. Wskutek tego gwiazda zapada się do swojego wnętrza i następuje gigantyczna eksplozja, podczas której energia emitowana jest między innymi jako promieniowanie gamma. Ma to miejsce gdy gwiazda zbliża się do końca swojego życia i kończy się jej paliwo. Jest to jedna z wersji powstawania supernowej. Po wybuchu gwiazda prze- 1 Jednostka pracy i energii w układzie miar CGS. [13] 6

8 kształca się w bardzo gęstą gwiazdę neutronową lub w czarną dziurę. Natomiast krótkie błyski są wynikiem zderzenia się dwóch ciał niebieskich znajdujących się w układzie podwójnym, czyli dwóch obiektów krążących wokół siebie. Mogą to być dwie gwiazdy neutronowe bądź gwiazda neutronowa oraz czarna dziura. Zderzenie zachodzi gdy gwiazdy tracą swoją energie i nie są wstanie zrównoważyć siły grawitacji działającej między nimi. Wskutek zderzenia powstaję masa krytyczna i następuje eksplozja po której powstaje czarna dziura. Od czasów odkrycia błysków gamma poczyniono duże postępy w wyjaśnieniu ich przyczyny, jednakże nadal nie jest wyjaśniony dokładny mechanizm wybuchu. Do poczynienia dalszych postępów niezbędne są dane opisujące błyski, a w szczególności optyczne odpowiedniki błysków, które mogą w znaczny sposób pomóc wytłumaczyć to zjawisko. Z powodu technicznych ograniczeń przez wiele lat optyczne odpowiedniki błysków obserwowane były parę godzin lub dni po zdarzeniu. Mimo, że sytuacja ta zmieniła się, zjawisko to zarejestrowano optycznie w trakcie jego trwania tylko kilkakrotnie. Istnieje również cała gama innych zjawisk astrofizycznych, które można obserwować i których czas trwania może być liczony w sekundach lub dniach. Najważniejszymi z nich, którymi zajmuje się projekt π of the Sky, są: Nowa klasyczna zjawisko zachodzące w systemie podwójnym, w którym znajduje się biały karzeł oraz gwiazda z której biały karzeł pobiera materie. Pobrana materia gromadzi się na powierzchni białego karła, po pewnym czasie nagromadzona materia przekracza masę krytyczną i na powierzchni gwiazdy następuje wybuch spowodowany reakcją termojądrową. Zjawisko to może powtarzać się i nazywane jest wtedy jako nowa powrotna. Zdarzenie to jest rejestrowane jako nagły wzrost jasności gwiazdy w porównaniu do wcześniejszych jej obserwacji lub jako pojawienie się nowego obiektu. Gwiazdy zmienne gwiazdy, które okresowo zmieniają swoją jasność. Zmienność jasności może mieć wymiar od milisekund do dni i lat. Typowym rodzajem gwiazdy zmiennej jest gwiazda rozbłyskowa, który gwałtownie i nieprzewidzianie zmienia swoją jasność na skutek nieprzewidywalnej eksplozji powiązanej z uwolnieniem energii magnetycznej. Przyczyna eksplozji jest taka sama jak przyczyna rozbłysku słonecznego, jednakże eksplozja gwiazdy zmiennej jest nawet tysiąc krotnie jaśniejsza. Zmienność gwiazdy rozbłyskowej charakteryzuję się gwałtownym, nieregularnym dużym wzrostem jasności w porównaniu do łagodnego spadku jasności. Szacuje się, że gwiazdy rozbłyskowe stanowią około 1% wszystkich gwiazd. Galaktyki aktywne w szczególności blazary jest to typ galaktyki, która posiada aktywne jądro, co jest spowodowane absorpcją materii takiej jak pył i gaz międzygwiezdny przez masywną czarną dziurę znajdującą się 7

9 w jej wnętrzu. W wielu przypadkach obserwowane są strugi materii mogące rozciągać się na bardzo dużą odległość, które są najprawdopodobniej wydzielane w kierunku obrotu czarnej dziury. Jeżeli kierunek strug materii jest skierowany w stronę Ziemi to taka aktywna galaktyka nazywana jest blazarem. Ten typ galaktyki charakteryzuje się szybką zmianą promieniowania w bardzo szerokim zakresie promieniowania elektromagnetycznego. Obserwacja takich obiektów oraz informowanie o ich aktywności jest bardzo ważna dla obserwacji prowadzonych przez duże teleskopy. Supernowe procesy związane ze śmiercią masywnych gwiazd powodowane naruszeniem równowagi między ciśnieniem wywoływanym przez siłę grawitacji gwiazdy oraz ciśnieniem powodowanym przez reakcje termojądrowe. Czego skutkiem jest zapadnięcie się gwiazdy powodującej ogromny wybuch o energii równej w przybliżeniu erg. Rocznie odkrywanych jest około 400 supernowych, lecz większości z nich towarzyszy rozbłysk, który jest niedostrzegalny przez aparaturę projektu. Jednak nie wyklucza to możliwości odkrycia takiego zjawiska. Powyższa lista jest tylko częścią procesów jakie są obiektem obserwacji projektu π of the Sky. W większości przypadków głównym celem obserwacji i analizy optycznej nieba jest odkrycie nowego zjawiska i powiadomienie o jego istnieniu dużych teleskopów mających większe możliwości w zakresie analizy i badania odkrytego obiektu. 1.2 Główne działania projektu Obserwacja błysków gamma Standardowe podejście w obserwacji błysków gamma polega na otrzymywaniu informacji o zaistnieniu zdarzenia i skierowaniu kamer na obszar nieba, w którym wystąpiło zdarzenie. Jednakże wykrycie takiego zjawiska i określenie jego współrzędnych nie jest sprawą oczywistą, ponieważ promieniowanie gamma jest silnie tłumione przez atmosferę ziemską. Powoduje to, że nie można wykryć zdarzenia za pomocą detektorów promieniowania gamma znajdujących się na powierzchni Ziemi. Wykrycie promieniowania gamma możliwe jest dzięki zainstalowaniu detektorów w satelitach okołoziemskich. Pierwsze satelity wyposażone w czujniki promieniowania gamma nie były wstanie określić położenia obiektu, który wyemitował promieniowanie. Sytuacja ta zmieniła się gdy w roku 1991 NASA wystrzeliła na orbitę okołoziemską obserwatorium Comptona CGRO (Compton Gamma Ray Observatory) [9]. Jedną z części satelity był BASTE (Burst And Transient Source 8

10 Experiment), który składał się z ośmiu bardziej czułych niż stosowane wcześniej detektorów promieniowania gamma znajdujących się na krańcach satelity. Dzięki mu możliwa była obserwacja słabszych błysków gamma oraz określenie pozycji błysku z dokładnością do 1 o. BASTE wraz z CGRO znajdował się na orbicie do roku Przez ten czas zarejestrował 2704 błysków, co w przeliczeniu na dni daje nam jeden błysk dziennie. Dodatkowo, jeżeli weźmiemy pod uwagę to, że nie mógł on wykonywać obserwacji przez cały czas z powodów technicznych oraz że część nieba zasłaniała mu Ziemia, szacuje się że był on wstanie zaobserwować 3 błyski dziennie. Satelita ten jednak miał jedną zasadniczą wadę z punktu widzenia obserwacji błysków gamma: nie potrafił określić w jakiej odległości znajduje się obiekt, który jest źródłem błysku. Problem ten rozwiązał włosko-holenderski satelita Bepposax [10], którego głównym zadaniem była rejestracja zjawisk astrofizycznych za pomocą kamer rentgenowskich. Na podstawie wykonanych przez niego obserwacji błysków gamma stwierdzono, że ich źródło znajduję się w bardzo odległych częściach Wszechświata. Aktualnie wszystkie obserwatoria, których celem jest obserwacja optyczna RGB pobierają informacje o zaistniałych zdarzeniach z GCN (Gamma ray bursts Coordinates Network) [8]. Jest to globalna sieć, która przekazuje informacje o wykrytych zjawiskach i ich współrzędnych za pomocą poczty elektronicznej, pagerów i gniazd telekomunikacyjnych do zarejestrowanych w niej użytkowników (rysunek 1.1). Dane które są dystrybuowane przez GCN pochodzą z satelitów: Rxte,Ipn, Integral, Swift, Fermi oraz Agile. Istnieje pewne opóźnienie pomiędzy wykryciem przez satelitę RGB a wysłaniem informacji o nim przez sieć, spowodowane czasem jaki jest niezbędny do obliczenia współrzędnych zjawiska. Czas ten wynosi około 5 sekund. Dodatkowo istnieje opóźnienie związane z transmisją danych, które w przypadku najszybszej formy, czyli gniazd telekomunikacyjnych, wynosi od 0.1 sekundy do 1 sekundy. Obserwatoria po otrzymaniu takiej informacji nakierowują swoje kamery na obszar zawierający współrzędne zjawiska, co również zajmuje czas. Z powodu występowania wyżej wymienionych opóźnień, udaje się obserwować błyski gamma jedynie po ich zakończeniu. Jedynie w niewielu przypadkach udało się zarejestrować optyczny odpowiednik błysku w czasie trwania eksplozji. Projekt Po of the sky zakłada odmienny sposób obserwacji RGB, polegający na ciągłym śledzeniu dużej części nieba za pomocą kamer wykonanych w technologii CCD, bez konieczności ich zmiany położenia. Aby zrealizować powyższe założenie, niezbędne jest skonstruowanie teleskopu, który będzie mógł stale śledzić duży wycinek nieba, co umożliwi zrejestrowanie zjawisk z dużym prawdopodobieństwem. Niemożliwa jest jednak realizacja tego za pomocą jednej kamery CCD, ponieważ wraz ze wzrostem pola widzenia kamery spada jej czułość i tym samym mniej zjawisk może zostać zaobserwowanych. Rozwiązaniem tego problemu jest instalacja wielu kamer, z których każda będzie pokrywać wybrany wycinek 9

11 Rysunek 1.1: Schemat sieci GCN nieba, co umożliwi obserwacje dużego obszaru nieba oraz szeroki zakres obserwowanych zjawisk. Jednym z założeń systemu jest możliwość obserwacji zjawisk, których jasność dochodzi do mag 2. Docelowy system ma składać się z 2 zestawów zawierających po 16 kamer każdy (rysunek 1.2). Pojedyncza kamera będzie pokrywała obszar widzenia 20 o x 20 o. W sumie cały teleskop będzie pokrywał pole widzenia jakie posiada satelita Swift czyli około 1/6 całego nieba. Dwa zestawy kamer będą zainstalowane w dwóch oddalonych od siebie o około 100 km obserwatoriach. Umożliwi to odrzucić błyski optyczne spowodowane przez obiekty znajdujące się blisko powierzchni ziemi za pomocą efektu paralaksy 3. System dokonuje akwizycji nieba z czasem naświetlania 10 sekund, jedno zdjęcie zawiera ok. 8 MB danych, co powoduje że jedna kamera generuje około 2,9GB danych w ciągu godziny. W ciągu nocy cały system wytwarza około 1,1TB i jest to zbyt duża ilość danych aby mogła być w całości przechowywana. Dodatkowo informacja o błysku pochodząca z sieci GCN jest otrzymywana z opóźnieniem. Powoduje to, że system musi posiadać moduł umożliwiający automatyczną detekcję rozbłysków i na podstawie jego wyników działania powinien zapisywać zdjęcia zawierające jedynie interesujące obserwacje. Detekcja nagłych pojaśnień odbywa się trzyeta- 2 Magnitudo jednostka wielkości gwiazdowej, poza układowej jednostki miary stosowanej do oznaczania blasku gwiazd. Najjaśniejsze gwiazdy mają wielkość 1 mag, najsłabsze, widoczne gołym okiem 6 mag skala odwrócona [14]. 3 Paralaksa efekt niepokrywania się dwóch obrazów wynikający z obserwowania obiektów z dwóch różnych kierunków [11]. 10

12 Rysunek 1.2: Pojedynczy zestaw kamer projektu π of the Sky. powo. Pierwszy etap jest najprostszy, gdyż musi być szybki ze względu na dużą ilość danych jakie musi przetworzyć. Jego głównym celem jest wyselekcjonowanie interesujących danych oraz odrzucenie nieznaczących danych. Zadaniem drugiego poziomu detekcji jest odrzucenie tej części spośród wcześniej wyselekcjonowanych zdjęć, na której wykryte błyski spowodowane były przez obiekty znajdujące się blisko powierzchni Ziemi, takie jak samoloty bądź sztuczne satelity. Trzeci ostatni poziom detekcji polega na bardziej szczegółowej analizie zdjęć, które zostały zaakceptowane przez dwa poprzednie poziomy. W czerwcu 2004 roku został uruchomiony prototyp systemu w Las Campanas Observatory (LCO) w Chile, gdzie może monitorować obszar nieba który jest w polu widzenia satelity Swift. Działa on do dziś, z kilkoma miesiącami przerwy, od czasu kiedy został utworzony. Głównym celem stworzenia prototypu było przetestowanie oprogramowania i sprzętu jaki ma zostać użyty w finalnej wersji systemu. W szczególności bardzo ważne było sprawdzenie efektywności działania algorytmów służących do automatycznej detekcji błysków. Prototyp składa się z dwóch kamer CCD, których konstrukcja została zaczerpnięta z projektu ASAS i ich łączne pole widzenia wynosi 21 o x 21 o (rysunek 1.3). Dzięki pełnej automatyzacji może być on w pełni kontrolowany za pomocą połączenia internetowego. Dodatkowo system samodzielnie reaguje na informacje o RGB przesyłane za pomocą GCN i sam zmienia położenie kamer aby móc obserwować zjawisko. Montaż na którym znajdują się kamery może zmienić swoje położenie, tak aby obserwować 11

13 Rysunek 1.3: Kamery prototypu projektu Pi of the Sky w LCO w Chile. dowolny punkt na niebie, w czasie krótszym niż minuta. Większość oprogramowania, które jest używane w eksperymencie, została samodzielnie zaprojektowana lub zaczerpnięta z projektu ASAS 4 (All Sky Automated Survey). Mimo iż prototyp nie działa bardzo długo ma już na swoim koncie sukcesy w skali światowej Wykrywanie pozostałych zjawisk astrofizycznych Wykrywanie nagłych rozbłysków optycznych i ich opis możliwy jest dzięki analizie off-line danych, które zostały wcześniej wykryte przez algorytmy automatycznej detekcji błysków. Pierwszy krok analizy zebranych zdjęć polega na analizie fotometrycznej, dzięki której odnajdywane są gwiazdy na obrazie i określane jest ich pozycja (x, y) oraz ich jasność. Następnym krokiem jest analiza astrometryczna zdjęć, która polega na przeliczeniu wcześniej uzyskanych współrzędnych obiektów (x, y) na współrzędne niebieskie czyli rektascensje 5 i deklinacje 6. Opis każdego 4 ASAS polski projekt automatycznych teleskopów stale monitorujących około 10 7 gwiazd na niebie. Zlokalizowany jest w Obserwatorium Las Campanas w Chile [3]. 5 Rektascensja kąt dwuścienny pomiędzy południkiem przechodzącym przez punkt Barana, a południkiem przechodzącym przez dany obiekt. Mierzy się ją od punktu równonocy wzdłuż równika i liczy w zakresie od 0 o do 360 o ale częściej podaje się jej wartość w mierze godzinnej (od 0h do 24h) [4]. 6 Deklinacja kąt środkowym między kierunkiem na dany obiekt a jego rzutem na płaszczyznę równika. Liczona jest od 0 o do 90 o dla punktów na półkuli północnej i od od 0 o do 90 o dla punktów na półkuli południowej [4]. 12

14 wykrytego obiektu na niebie za pomocą współrzędnych niebieskich zapewnia jego jednoznaczną identyfikacje. Tak uzyskane wyniki są następnie zapisywane w katalogu gwiazd, który jest zorganizowany za pomocą relacyjnej bazy danych DB2 Enterprise 9.5. Struktura bazy danych jest odpowiednio zoptymalizowana pod kątem specyficznych zapytań, które są wykorzystywane przez aplikacje mające za zadanie wykrywanie zjawisk astrofizycznych. Programy te wykorzystują dwa algorytmy. Pierwszy z nich wyszukuje nowe pozycje w bazie danych, które odpowiadają nagłym pojaśnieniom gwiazd, przez co stają się one widoczne. Przykładem takiego zdarzenia może być eksplozja gwiazdy nowej. Drugi z nich poszukuje nagłych zmian jasności gwiazd w stosunku do wcześniej wykonanych obserwacji. Odpowiada to gwieździe rozbłyskowej bądź aktywnej galaktyce, w szczególności blazarowi Największe osiągnięcie projektu Teleskop projektu π of the Sky 19 marca 2008 roku otrzymał informację o błysku gamma GRB080319A z sieci GCN, który został wykryty przez satelitę Swift. Standardową procedurą jest nakierowanie przez system kamer na część nieba, w którym miało miejsce zjawisko. Rejestracja zdarzenia zakłada dłuższą obserwację, po jego zajściu, obszaru nieba w którym zdarzenie miało miejsce. W tym właśnie czasie, 28 minut po błysku GRB080319A w polu widzenia, na które był skierowany teleskop, nastąpił drugi błysk GRB080319B i został on wykryty przez systemowy algorytm detekcji błysków. Dwie sekundy później promieniowanie gamma, które towarzyszyło zjawisku zostało zarejestrowane przez satelitę Swift. Informacja o jego wykryciu dotarła przez sieć GCN do innych teleskopów naziemnych dopiero 17 sekund później. Sam Swift wyposażony jest w pokładowy ultrafioletowy i optyczny teleskop pokładowy UVOT [7], jednakże zaczął on filmować zjawisko dopiero 51 sekund po wykryciu promieniowania. Dla porównania Very Large Telescope w Chile zaczął obserwacje zjawiska dopiero godzinę po jego zaistnieniu. Dzięki temu, że drugi błysk gamma miał miejsce w polu widzenia teleskopu projektu, udało się zarejestrować RGB w momencie eksplozji, a nie tylko poświaty optycznej, która zostaje po niej. Nigdy przedtem się to nie zdarzyło i jest to kluczowe do zrozumienia i wytłumaczenia tego zjawiska. Dodatkowo GRB080319B był najjaśniejszym błyskiem, jaki kiedykolwiek został zaobserwowany przez człowieka. Jasność jaką zarejestrował teleskop projektu wynosi 6 w skali magnitudo, co oznacza, że błysk był widoczny gołym okiem. Szacuje się, że eksplozja, która była źródłem błysku, była oddalona od Ziemi o 7,5 miliardów lat świetlnych, co odpowiada połowie odległości do krańców widzialnego Wszechświata. Najprawdopodobniej źródłem zdarzenia była śmierć masywnej gwiazdy, która dała początek czarnej dziurze [2]. Wykrycie powyższego zjawiska potwierdza słuszność metody działania jaką przyjął projekt π of the Sky. Mimo, iż na razie działa jedynie prototyp syste- 13

15 mu, to jest on wstanie wykryć bardzo znaczące zjawiska w zakresie zjawisk szybko zmiennych. 1.3 Miejsce tej pracy w projekcie π of the Sky Jednym z najważniejszych problemów z jakim styka się projekt π of the Sky jest wspomniana wcześniej detekcja nagłych pojaśnień w polu widzenia teleskopu, która działa w czasie rzeczywistym. Kluczowym elementem w tym zagadnieniu jest odrzucenie błysków pochodzących od obiektów znajdujących się blisko powierzchni Ziemi. Mogą to być przelatujące samoloty lub sztuczne satelity, które odbiją światło emitowane przez słońce. Co prawda odwzorowanie większości błysków takiej klasy obiektów posiada całkiem inny kształt, niż odwzorowanie błysku spowodowanego przez zjawisko astrofizyczne. Jednak nawet stosunkowo mała część zdarzeń pochodzących od obiektów znajdujących się blisko, może stanowić duży problem. W docelowym systemie rozwiązaniem tego problemu ma być działanie dwóch obserwatoriów oddalonych od siebie o 100 km. Dzięki nim będzie możliwe zastosowanie metody paralaksy do odrzucenia niepożądanych błysków. Pozycja zarejestrowanych zdarzeń spowodowanych przez obiekty nie będące gwiazdami względem pozycji ciał niebieskich, których pozycja jest ogólnie znana, będzie się różniła, jeżeli zostanie zmierzona z dwóch miejsc na Ziemi, oddalonych od siebie o stosunkowo duży dystans. W prototypowej wersji systemu zastosowano powyższą metodę jedynie tylko przez parę nocy. Było to możliwe dzięki współpracy z teleskopem RDOT [1], który znajduje się 30 km od teleskopu projektu π of the Sky. Na podstawie wykonanego eksperymentu potwierdzono poprawność działania powyższej metody: odrzucała ona przypadki błysków spowodowanych przez sztuczne satelity ziemskie. Podczas normalnego działania prototypu nie jest możliwe ciągłe użycie efektu paralaksy do odrzucania błysków pochodzących od satelitów. Dlatego w celu identyfikacji niepożądanych błysków używa się bazy danych, która zawiera trajektorie lotu wszystkich znanych satelitów. Każdej nocy pobierana jest zawartość bazy, która składa się z opisu około elementów znajdujących się na orbicie okołoziemskiej. Dla każdego wykonanego zdjęcia wyznacza się satelity, które mogą się na nim znajdować oraz ich współrzędne. Każdy błysk, który jest potencjalnym zdarzeniem jest porównywany z wyznaczonymi satelitami. Odrzucone zostają błyski, których odległość kątowa jest mniejsza niż 0, 5 o w stosunku do obliczonej pozycji wyznaczonego satelity. Baza danych obiektów znajdujących się na orbicie okołoziemskiej nie jest jednak kompletna. Nie zawiera ona wpisów dotyczących satelitów, których istnienie nie jest ogólnie znane lub jest tajne (np. satelitów szpiegowskich). W takim przypadku istnieje możliwość porównania kilka zdjęć następujących po sobie aby za- 14

16 obserwować tor lotu obiektu. W ten sposób odrzucana jest duża liczba samolotów i satelitów nie znajdujących się w bazie danych. Istnieje jednak prawdopodobieństwo, że satelity posiadające własne źródło światła i wykonujące ruch obrotowy wokół własnej osi nie zostaną odrzucone. Ostateczną częścią weryfikacji zjawiska jest jego ocena przez osobę która analizuje dane. Ma ona za zadanie ocenić czy algorytm wykrywania nagłych błysków zadziałał prawidłowo, ponieważ nie ma pewności, że wyżej wymieniony algorytm działa ze stuprocentową poprawnością. Weryfikacja prowadzona jest poprzez odczytywanie dokładnych wartości pikseli obrazu. Mogą one być porównywane z danymi zebranymi w bazie danych w ciągu trwania projektu bądź z danymi udostępnionymi przez inne jednostki badawcze takie jak inne obserwatoria lub satelity. Jest to możliwe dzięki algorytmowi, który wyznacza współrzędne niebieskie każdego piksela na podstawie danych zapisanych w nagłówku pliku FITS. Finalne wyniki obserwacji kopiowane są z obserwatorium na lokalny serwer znajdujący się w Warszawie. Zarówno wyniki obserwacji nieba zapisane w formacie FITS, jak i dane znajdujące się w bazie danych projektu dostępne są poprzez interfejs WWW. Umożliwia to ostateczną ocenę zaobserwowanych zjawisk i ich potwierdzenie w większości przypadków. Nie jest to jednak wystarczające, ponieważ istniejący interfejs nie ma możliwości wyświetlania obrazów oraz danych zapisanych w plikach FITS. Aktualnie obrazy prezentowane są za pomocą formatu JPG co powoduje, że nie ma możliwości pobrania wartości wybranych pikseli i nie da się określić ich współrzędnych niebieskich. Gdy potencjalny błysk wzbudza wątpliwości osoby analizującej zdarzenie, zmuszona jest ona do pobrania serii zdjęć na swój lokalny komputer. Dodatkowo serie obrazów przechowywane są w skompresowanych archiwach tar.gz, co powoduje konieczność wykonywania dodatkowych czynności związanych z ich dekompresją i dearchiwizacją. Dopiero wtedy można rozpocząć analizować zdjęcia w jednej z dostępnych przeglądarek plików FITS. Implementacja przeglądarki działającej przez WWW dla plików astronomicznych uzupełni istniejący interfejs w narzędzie do analizy wykrytych zjawisk przez system i dodatkowo da możliwość publikacji zjawisk wykrytych dla szerszej publiczności, która nie będzie zmuszona do instalacji dodatkowego oprogramowania na swoim komputerze. 15

17 Rozdział 2 Standard FITS FITS (Flexible Image Transport System) jest formatem, który został stworzony w celu przechowywania oraz transmitowania obrazów pozyskanych w celach naukowych. Głównym powodem jego utworzenia była standaryzacja formy przechowywania danych astronomicznych. Został on wprowadzony w latach siedemdziesiątych przez NASA (National Aeronautics and Space Administration) oraz Międzynarodową Unię Astronomiczną i jest wspierany poprzez te organizacje po dzień dzisiejszy. 2.1 Struktura plików FITS Podstawowymi elementami z których składa się każdy plik są bloki danych (Header and Data Unit HDU ) zawierające nagłówek oraz obszar danych. Plik posiada jeden lub więcej takich bloków, których długość wyrównana jest do 2880 bajtów. Pierwszym znajdującym się w pliku elementem jest podstawowy blok danych nazywany Primary HDU lub Primary Array. Składa się on z nagłówka oraz podstawowego obszaru danych zawierającego obraz zapisany za pomocą n-wymiarowej tablicy pikseli. Jeżeli plik zawiera tylko jeden blok HDU uznawany jest jako pojedynczy obraz FITS (Single Image FITS SIF), Natomiast plik zawierający wiele bloków danych określany jest jako FITS posiadający wiele rozszerzeń (Multi-Extension FITS file). Tablica znajdująca się w obszarze danych podstawowego bloku pliku może mieć od 1 do 999 wymiarów. Dane znajdujące się w tablicy prezentowane są jako strumień bitów, którego pierwszy element zapisany jest na pozycji pierwszego bitu podstawowego obszaru danych. Każdy piksel przechowywanego obrazu reprezentowany jest za pomocą pojedynczej komórki tablicy, której wielkość jest ściśle określona. Tablice posiadające więcej niż jeden wymiar zapisane są za pomocą sekwencji, w której indeks pierwszego wymiaru tablicy wzrasta najszybciej, nato- 16

18 miast indeks ostatniego wymiaru wzrasta najwolniej, czyli w przypadku tablicy dwuwymiarowej tablica jest zapisywana za pomocą sekwencji wierszy. Nie istnieje wolny obszar ani żaden specjalny znacznik, który oddzielałby zapis poszczególnych wierszy między sobą. Dodatkowo obszar danych każdego bloku HDU musi być wyrównany do długości Jeżeli tablica nie wypełnia do końca obszaru danych, to powinien on zostać uzupełniony bitami o wartości zero. Indywidualna wartość każdej komórki tablicy powinna być zapisana w konwencji big Endian, czyli najbardziej znaczące bity w bajtach reprezentujących wartość piksela powinny znajdować się na ich pierwszych pozycjach. Zarówno wymiar tablicy jak i rozmiar pojedynczej komórki przechowywany jest w nagłówku podstawowego HDU. Standard zakłada, że każdy z bloków następujących po podstawowym bloku danych posiada jedno z trzech rozszerzeń: Image Extension rozszerzenie o podobnej strukturze do podstawowego obszaru danych. Jest używane do przechowywania danych w n wymiarowych tablicach. Każda komórka tablicy przechowuje taką samą ilość danych. ASCII Table Extension rozszerzenie umożliwiające przechowywanie katalogów oraz tabel zawierających astronomiczne dane. Obszar danych reprezentuje tabela o ustalonej liczbie kolumn i dowolnej liczbie wierszy. Każda komórka tabeli może zawierać sekwencje znaków ASCII o dowolnej długości. Binary Table Extension podobnie jak ASCII Table Extension umożliwia przechowywanie danych astronomicznych w postaci tabeli. Różnica pomiędzy tymi dwoma rozszerzeniami polega na tym, że dane liczbowe znajdujące się w tabeli mogą być przechowywane w postaci binarnej. Dodatkowo każda komórka tabeli może zawierać tablice wartości liczbowych, a nie tylko pojedynczą wartość skalarną Nagłówek bloku danych Nagłówek każdego bloku danych składa się z rekordów zawierających słowa kluczowe, które opisują format przechowywanych danych w obszarze danych lub opisują pochodzenie danych. Jego długość jest wyrównana do 2880 bajtów. Każdy rekord nagłówka zawiera 80 znaków ASCII i ma on postać: KEYNAME = value/comment Gdzie KEYNAME jest unikalną nazwą słowa kluczowego w obrębie nagłówka, która składa się maksymalnie z ośmiu znaków ASCII, value jest wartością przypisaną do słowa kluczowego, a comment jest opcjonalnym komentarzem. Przypisywana wartość może mieć następujący format: sekwencji znaków ASCII z zakresu wartości 17

19 decymalnych , liczby całkowitej, liczby zmiennoprzecinkowej, stałej logicznej (prawda reprezentowana jest jako znak T, natomiast fałsz jako znak F ). Słowa kluczowe nagłówka mogą należeć do grupy słów, których znaczenie jest ściśle określone przez standard, lub mogą być dowolnymi opcjonalnymi słowami, których wartości mają znaczenie w konkretnym zastosowaniu. Wymagane jest, aby ostatnim elementem nagłówka było słowo kluczowe END bez przypisanej wartości i bez komentarza oraz aby pozostała część nagłówka potrzebna do wyrównania jego długości do 2880 bajtów została wypełniona znakami spacji. Standard określa zbiory słów kluczowych, które powinny znajdować się w nagłówku podstawowego HDU oraz w nagłówkach HDU posiadających rozszerzenie. Każde ze słów wchodzących w skład tych zbiorów posiada ściśle określone znaczenie oraz ściśle określony format, w jakim prezentowana jest przypisana do niego wartość. Są to słowa wprowadzone w celu jednoznacznego opisu formy, w jakiej zostały zapisane dane w obszarze danych poprzedzającym dany nagłówek, oraz w celu potwierdzenia standardu i ewentualnego określenia rozszerzenia HDU. Zakłada się także, że słowa te powinny znajdować się na początku nagłówka i powinny zostać wymienione w określonej kolejności. W skład słów kluczowych znajdujących się w nagłówku podstawowego obszaru danych wchodzą (słowa wymienione są w kolejności określonej przez standard): SIMPLE wartość słowa zawiera stałą logiczną, która określa czy dany plik posiada strukturę zgodną ze standardem. Pole jest obowiązkowe dla podstawowego HDU i nie może występować w nagłówkach bloków następujących po nim. BITPIX wartość przypisana do słowa powinna zostać określona za pomocą liczby całkowitej, która przedstawia rozmiar komórki tabeli, znajdującej w obszarze danych poprzedzającym nagłówek. Oznacza ona liczbę pikseli przy pomocy, których zapisany jest pojedynczy element obrazu. Tylko określone wartości mogą zostać przypisane do tego słowa. NAXIS - Słowo to zawiera nieujemną liczbę całkowitą określającą liczbę wymiarów tabeli która zawiera dane. Może ono przyjmować wartości od 0 do 999. W przypadku zera, nie istnieją żadne dane, które poprzedzają nagłówek w podstawowym HDU. NAXISn jest to format w jakim powinne być prezentowane słowa określające wielkość tabeli w każdej jej wymiarze, gdzie n jest indeksem wymiaru. Słowa te powinny być zapisane zgodnie ze wzrastającym indeksem. Rozmiar każdego z wymiarów powinien być przedstawiony za pomocą nieujemnej liczby całkowitej. Jeżeli choć do jednego ze słów przypisana jest wartość 0 oznacza to, że obszar danych następujący po nagłówku nie zawiera danych. 18

20 END słowo nieposiadające przypisanej wartości, oznaczające logiczny koniec nagłówka. Poza przedstawionymi wyżej słowami kluczowymi istnieją także dodatkowe wyrażenia, które muszą być wymienione w nagłówkach bloków danych posiadających rozszerzenie, są to: XTENSION, PCOUNT oraz GCOUNT. Pierwsze z nich określa rozszerzenie HDU i może przyjmować jedynie określone wartości zgodne z ustalonymi oznaczeniami rozszerzeń. Dwa pozostałe słowa opisują struktury danych jakie są zawarte w istniejących rozszerzeniach. Żadne z powyżej wymienionych słów nie może znajdować się w nagłówku podstawowego HDU. Oprócz obowiązkowych słów istnieje także zbiór słów zarezerwowanych. Ich format oraz znaczenie jest określone przez standard. Są one podzielone na następujące kategorie: ogólne słowa opisujące plik, słowa opisujące obserwacje zjawiska zawartego w pliku, słowa bibliograficzne, słowa zawierające komentarz, słowa opisujące tabele przechowujące dane oraz słowa opisujące rozszerzenia. Z punktu widzenia odczytu oraz prezentacji obrazów zawartych w plikach FITS w podstawowym bloku oraz w blokach o rozszerzeniu Image Extension, bardzo ważna jest grupa słów, która opisuje tabele przechowujące piksele obrazów. Niektóre z nich to: BSCALE słowo, które jest używane wraz ze słowem BZERO w celu liniowego przeskalowania wartości znajdującej się w każdej komórce tabeli do odpowiadającej jej fizycznej wartości. Wartość ta obliczana jest na podstawie równania 2.1. Wartość tego słowa powinna być zapisana za pomocą liczby zmiennoprzecinkowej. Jeżeli dane słowo nie występuję w nagłówku przyjmuje się jego domyślną wartość równą 1,0. BZERO drugie ze słów służących do liniowego przeskalowania wartości znajdujących się w tabeli do odpowiadających im wartości fizycznych. Przekształcenie wykonywane jest według wzoru 2.1. Słowo to również powinno być reprezentowane za pomocą liczby zmiennoprzecinkowej. y = BZERO + BSCALE y (2.1) Format wartość przechowywanych w tabeli podstawowego bloku danych Format danych, w którym zapisane są wartości w pojedynczej komórce tabeli, określony jest za pomocą słowa kluczowego BITPIX. Standard wymienia dozwolone typy danych oraz przypisuje im odpowiadającą wartość słowa BITPIX. Dozwolone wartość słowa to: 8 oznacza, że dana zawarta w komórce tabeli zapisana jest za pomocą ośmiobitowej liczby całkowitej bez znaku. 19

21 16 wartość komórki tabeli zapisana jest za pomocą dwóch bajtów przedstawiających liczbę całkowitą ze znakiem. 32 komórka tabeli przedstawia czterobajtową liczbę całkowitą ze znakiem. 64 komórka tabeli zawiera ośmiobajtową liczbę całkowitą ze znakiem. -32 komórka tabeli zawiera liczbę zmiennoprzecinkową, której reprezentacja zgodna jest ze standardem zapisu określonym przez ANSI/IEEE-754. Zapisana jest ona za pomocą czterech bajtów. -64 komórka tabeli zawiera liczbę zmiennoprzecinkową, której reprezentacja zgodna jest ze standardem zapisu określonym przez ANSI/IEEE-754. Liczba zapisana jest za pomocą ośmiu bajtów. Z uwagi na to, że standard FITS nie wspiera zapisu liczb całkowitych bez znaku (z wyjątkiem liczb całkowitych zapisanych za pomocą jednego bajta) niemożliwe jest przechowywanie liczb całkowitych bez znaku zapisanych za pomocą dwóch, czterech lub ośmiu bajtów. Proponowanym rozwiązaniem tego problemu przez standard jest przesuniecie zakresu liczb bez znaku do zakresu liczb ze znakiem. Realizowane jest to poprzez określenie wielkości przesunięcia w słowie kluczowym BZERO oraz przypisaniu słowu kluczowemu BSCALE wartości 1.0. Podczas odczytu prawidłowa wartość liczby powinna zostać określona za pomocą wzoru Pliki FITS używane w projekcie π of the Sky Wszystkie zdjęcia nieba wykonane przez teleskop projektu π of the Sky zapisywane są za pomocą formatu FITS. Zaliczają się one do kategorii Single Image FITS, czyli zwierają tylko podstawowy blok danych przedstawiający obraz. Wszystkie dane opisujące dokonaną obserwacje zapisywane są za pomocą słów kluczowych, znajdujących się w nagłówku Format zapisu obrazu Obraz pochodzący z kamery CCD projektu zapisywany jest za pomocą dwuwymiarowej tablicy danych. Każdy piksel przedstawiony jest w szesnastobitowej skali szarości i reprezentowany jest za pomocą dwubajtowej liczby całkowitej bez znaku. Daje to możliwych odcieni w skali szarości. Z uwagi na to, że format FITS nie obsługuje liczb całkowitych bez znaku, wartości obrazu są przesuwane w zakres dwubajtowych liczb całkowitych ze znakiem poprzez odjęcie od wartości każdego piksela liczby równej Dodatkowo obraz przed zapisem może zostać przekształcony przez oprogramowanie kamery. Przekształcenie to polega 20

22 na wykonaniu odbicia lustrzanego obrazu względem osi OX lub względem osi OY kartezjańskiego układu współrzędnych. Fizyczna wielkość tabeli zawierającej obraz wyrażona w bitach obliczana jest na podstawie iloczyny słów kluczowych NAXIS1, NAXIS2 oraz BITPIX Fragmenty obrazów Format plików FITS nie stosuje żadnego rodzaju algorytmu kompresji danych. Powoduje to, że jedno wykonane zdjęcie przez kamerę projektu zapisywane jest w pliku, którego wielkość przekracza 8 MB pamięci. Chcąc zobrazować zjawisko astrofizyczne należy przedstawić obszar nieba, w którym miało ono miejsce za pomocą serii zdjęć, która zawiera zdjęcia pokazujące stan nieba przed, w trakcie, oraz po czasie trwania zdarzenia. Taka seria zdjęć może zawierać kilkanaście elementów. Dodatkowo w trakcie jednej nocy może zostać wykrytych kilkanaście zdarzeń. Przesyłanie takiej dużej ilości danych z obserwatorium na serwer znajdujący się w Warszawie może w znacznym stopniu obciążać łącze internetowe znajdujące się w obserwatorium. W celu redukcji wielkości przesyłanych danych, wykryte zjawisko prezentuje się za pomocą plików FITS zawierających jedynie fragmenty pierwotnych obrazów. Pojedynczy plik posiada prawie takie same wartości słów kluczowych jak odpowiadający mu plik przedstawiający zdjęcie uzyskane bezpośrednio z kamery. Różnią się przede wszystkim wartością dwóch słów kluczowych określających wielkość tablicy przechowującej piksele obrazu. Dla porównania obraz pochodzący bezpośrednio z kamery posiada rozdzielczość równą 2062 x 2048, natomiast fragment obrazu posiada rozdzielczość równą 100 x 100. Dodatkowo w plikach zawierających fragmenty obrazu zdefiniowane są cztery słowa niewystępujące w pierwotnych plikach. Są to: EVTX0, EVTY0, ORGSIZEX oraz ORGSIZEY. Dwa pierwsze z nich określają położenie wycinka obrazu względem początku dużego obrazu. Czyli są to współrzędne odpowiednio x i y pierwszego piksela fragmentu obrazu względem pierwszego piksela dużego obrazu posiadającego współrzędne x i y równe (0, 0). Następne dwa dodatkowe słowa kluczowe zawierają wielkości określające szerokość oraz wysokość oryginalnego obrazu, z którego pochodzi wycinek Używane słowa kluczowe Słowa które są używane w plikach projektu można podzielić na następujące kategorie: słowa kluczowe wymagane przez standard, słowa opisujące obserwowany obiekt, słowa opisujące źródło pochodzenia pliku, słowa opisujące kamerę użytą do wykonania zdjęcia, słowa zawierające systemowy identyfikator zdjęcia, słowa opisujące ustawienia kamery, słowa opisujące warunki wykonania zdjęcia, słowa 21

23 opisujące datę wykonania obserwacji, słowa zwierające dane astrometryczne, słowa zawierające dane fotometryczne oraz słowa opisujące położenie kamery. Pierwsza z powyższych kategorii zawiera wyłącznie słowa zdefiniowane przez standard, natomiast wszystkie pozostałe kategorie składają się ze słów należących do grupy słów opcjonalnych według standardu FITS. Dodatkowa grupa słów została zdefiniowana na potrzeby realizacji projektu. Najważniejszymi z nich z punktu widzenia zaimplementowanej aplikacji są: RA słowo zawiera wartość określająca rektascensję wyrażoną w godzinach punktu znajdującego się na środku obrazu. Prezentowana jest ona za pomocą liczby zmiennoprzecinkowej. DEC słowo zawiera wartość określającą deklinację wyrażoną w stopniach punktu znajdującego się na środku obrazu. FLIP słowo kluczowe określające rodzaj wykonanej operacji odbicia lustrzanego obrazu przed zapisaniem go do pliku. Wartość 0 oznacza brak odbicia lustrzanego obrazu, wartość 2 oznacza odbicie lustrzane obrazu względem osi OY, wartość 3 oznacza odbicie lustrzane obrazu względem osi OX. AST ORD słowo kluczowe określające kolejność wykonywania równań stosowanych w procedurze przekształcającej wektor określający przesunięcie wybranego punktu obrazu od jego środka, wyrażony w układzie współrzędnych kartezjańskich, do wektora wyrażonego w układzie współrzędnych niebieskich. Wartość słowa wyrażona jest jako liczba całkowita. PAR X 0, PAR X 1,..., PAR X 20 słowa kluczowe zawierające współczynnik stosowane w procedurze przekształcenia wektora odległości z kartezjańskiego układu współrzędnych do układu współrzędnych niebieskich. PAR Y 0, PAR Y 1,..., PAR Y 20 słowa kluczowe zawierające współczynnik stosowane w procedurze przekształcenia wektora odległości z kartezjańskiego układu współrzędnych do układu współrzędnych niebieskich. Dodatkowymi słowami znajdującymi się wyłącznie w plikach obrazujących fragment oryginalnego zdjęcia są: EVTX0 słowo określa współrzędną x pierwszego piksela fragmentu obrazu względem pierwszego piksela pierwotnego obrazu. Wartość zapisana jest w formacie liczby całkowitej. EVTY0 słowo określa współrzędną y pierwszego piksela fragmentu obrazu względem pierwszego piksela pierwotnego obrazu. Wartość zapisana jest w formacie liczby całkowitej. 22

24 ORGSIZEX słowo określa szerokość pierwotnego obrazu, z którego pochodzi fragment. Zapisana jest w formacie liczby całkowitej. ORGSIZEY słowo określa wysokość pierwotnego obrazu, z którego pochodzi fragment. Zapisana jest w formacie liczby całkowitej Paczki obrazów Pliki zawierające fragmenty obrazów uzyskanych za pomocą kamer projektu opisywane są za pomocą tzw. list. Jedna lista zawiera spis plików uzyskanych z jednej kamery przedstawiający jedno wykryte zjawisko. Jest ona zpisana jako plik tekstowy, w którym zapisane są nazwy plików FITS. Nazwa każdego z elementów listy zapisywana jest w oddzielnej linii, w kolejności zgodnej z przebiegiem zjawiska. Nie jest dokładnie sprecyzowana nazwa pliku tekstowego zawierającego listę, ale zawiera ona zazwyczaj słowo list oraz cyfrę oznaczającą numer listy opisującej zjawisko. Wymagane jest również, aby wszystkie pliki należące do listy znajdowały się razem z nią w jednym folderze. Oprócz list zawierających fragmenty pozyskanych obrazów za pomocą kamer, mogą również być tworzone spisy plików zawierające obrazy uzyskane poprzez uśrednienie paru kolejnych zdjęć obrazujących zdarzenie. Listy przedstawiające zjawiska zapisywane są razem w tzw. paczce, która jest folderem zawierającym powyższe listy i ich elementy oraz pliki przechowujące wyniki analiz fotometrycznych zdjęć. Paczki są przysyłane oraz przechowywane w formie skompresowanych archiwów tar.gz. 23

25 Rozdział 3 Opis zaimplementowanej przeglądarki plików FITS 3.1 Wybrana technologia i wykorzystywane biblioteki Głównym kryterium wyboru technologii zaimplementowanej przeglądarki plików FITS było spełnienie wymagania dotyczącego możliwości jej uruchomienia w środowisku przeglądarki internetowej. Drugim branym pod uwagę wymaganiem była prezentacja obrazów zapisanych w szesnastobitowej skali szarości, w możliwie najlepszej jakości. Dodatkowo, aby obsługa aplikacji stała się wygodna ważna, była również dobra interakcja programu z użytkownikiem. Istniały dwie możliwości spełnienia powyższych wymagań. Pierwsza polegała na prezentacji obrazów w kodzie HTML oraz spełnieniu wymagań funkcjonalnych dotyczących aplikacji przy pomocy języka JavaScript i technologii AJAX. Alternatywnym rozwiązaniem była implementacja przeglądarki w formie apletu Javy. Spośród tych możliwości zostało wybrane drugie rozwiązanie, przede wszystkim dlatego, że w przypadku wykonywania operacji graficznych i metod przetwarzania obrazów po stronie serwera niezbędne było by ciągłe pobieranie nowych zdjęć przedstawiających wykonane operacje. Mogło by to być uciążliwe dla użytkownika ponieważ w przypadku dużych zdjęć musiałby długo czekać aby zobaczyć rezultat. Aplikacja została zaimplementowana w języku Java Platform Standard Edition w wersji szóstej, w formie apletu oraz analogicznego programu. Wykorzystuje ona następujące biblioteki: nom.tam.fits biblioteka napisana w języku Java, umożliwiająca odczyt i zapis plików FITS. Wspomaga ona obsługę podstawowych HDU oraz bloków danych posiadających rozszerzenia zdefiniowane w standardzie. Obraz zapisany w podstawowym bloku zwracany jest jako tablica obiektów klasy 24

26 java.lang.object. Pakiet ten również posiada interfejs umożliwiający pobieranie wartości słów kluczowych nagłówka poprzez podanie ich nazw jako argumentów wywołania funkcji. com.ice.tar biblioteka zaimplementowana w języku Java pozwalająca na tworzenie oraz rozpakowywanie archiwów tar. W połączeniu z pakietem java.util.gzip, wchodzącym w skład standardowej biblioteki Javy, możliwa jest również obsługa skompresowanych archiwów tar.gz. org.apache.commons.httpclient biblioteka napisana w języku Java, dająca większą funkcjonalność podczas komunikacji za pomocą protokołu HTTP niż standardowa biblioteka java.net. Umożliwia między innymi przesyłanie danych za pomocą metody POST. Z implementacją aplikacji w formie apletu związane są również pewne ograniczenia. Domyślnie każda przeglądarka internetowa nakłada następujące ograniczenia uruchamiając pobrany z sieci aplet [6]: aplet nie może ładować bibliotek ani definiować natywnych metod, nie może on czytać ani zapisywać plików na lokalnym komputerze, nie może komunikować się z innym serwer niż ten, z którego został pobrany, nie może tworzyć procesów potomnych na lokalnym komputerze, nie może czytać części zmiennych środowiskowych na lokalnej stacji roboczej, okna wyświetlane przez aplet wyglądają inaczej niż okna wyświetlane przez aplikacje. Z punktu widzenia wymagań dotyczących zaimplementowanej aplikacji istotne są ograniczenia dotyczące możliwości czytania i zapisywania plików na lokalnej maszynie oraz możliwości komunikowania się z innym serwerem niż ten, z którego został pobrany aplet. W pierwszym przypadku nie istnieje możliwość przetwarzania plików na lokalnym komputerze, natomiast w drugim przypadku niemożliwe jest pobieranie pliku z dowolnego adresu URL. Jednym z rozwiązań pozwalającym na przyznanie pełnych praw apletowi jest jego podpisanie za pomocą certyfikatu. W tym przypadku przeglądarka internetowa podczas uruchamiania apletu wyświetli okno dialogowe, przez które użytkownik będzie mógł zdecydować czy zaufać osobie, która stworzyła certyfikat i zezwolić lub nie na wykonywanie wszystkich operacji dla apletu. Zostało to zrealizowane poprzez wygenerowanie certyfikatu przy użyciu narzędzia keytool oraz podpisanie pliku JAR zawierającego kod programu za pomocą aplikacji jarsigner. Oba użyte narzędzia dostarczane są wraz z JDK przez firmę Sun. 25

27 3.2 Struktura aplikacji Poniżej zostaną omówione najważniejsze elementy struktury zaimplementowanej aplikacji. W każdym podpunkcie zostanie przedstawiony sposób realizacji danej części programu oraz zostaną wymienione jej funkcje Reprezentacja obrazu W celu uniezależnienia wyświetlania obrazu od sposobu jego zapisu w podstawowym bloku HDU zostały użyte następujące dwa wzorce projektowe. Pierwszy z nich to Adapter, natomiast drugi to Metoda Fabrykująca. Celem użycia Adaptera było dostosowanie interfejsu klasy java.awt.bufferedimage do wymagań funkcjonalnych stawianych przed zaimplementowaną przeglądarką. Natomiast celem użycia Metody Fabrykującej było ukrycie wyboru konkretnej klasy adaptującej, która powinna być tworzona w zależności od formatu obrazu przechowywanego w pliku FITS. Jedną z funkcjonalności stworzonej aplikacji jest wyświetlanie oryginalnych wartości pikseli przetwarzanego obrazu. Gdy weźmiemy również pod uwagę możliwość wykonywania operacji graficznych na obrazie oraz możliwość wykonywania procedur przetwarzania obrazu to wartości pikseli obrazu mogą ulegać zmianom. Niezbędne jest przez to przechowywanie obiektu reprezentującego oryginalne wartości obrazu oraz obiektu reprezentującego aktualnie przetwarzany obraz. Jest to nieuniknione, ponieważ operacje przetwarzania obrazu takie jak zmiana odwzorowań poziomów jasności są nieodwracalne i nie można uzyskać oryginalnej wartości na podstawie wartości zmodyfikowanej. Z wyżej wymienionego powodu spośród dwóch sposobów realizacji wzorca projektowego Adapter, z których jeden polega na implementacji klasy adaptującej jako klasy dziedziczącej po klasie adaptowanej, a drugi na implementacji klasy zawierającej obiekt klasy adaptowanej, został zastosowany wariant drugi. Typ danych adaptujący obiekty java.awt.bufferedimage został zrealizowana za pomocą abstrakcyjnej klasy fits.image.fitsimageextention, oraz dla obrazów zapisanych w szesnastobitowej skali szarości, których wyświetlanie jest jedną z podstawowych funkcjonalności programu, jako klasy fits.image.fitsimageextention. Rozbicie klasy adaptującej na klasę abstrakcyjną oraz klasę dziedziczącą po klasie abstrakcyjnej miało na celu stworzenie możliwości wyświetlania obrazów zawartych w plikach zapisanych w różnym formacie, gdzie każda z możliwych form zapisu obrazu reprezentowana jest jako osobna klasa pochodna. Dodatkowo klasa abstrakcyjna narzuca interfejs, jaki powinien być implementowany przez klasy dziedziczące oraz zawiera grupę gotowych metod, których realizacja jest wspólna dla wszystkich rodzajów obrazów zawartych w podstawowym bloku plików FITS. Realizacja metod abstrakcyjnych znajdujących się w klasie bazowej jest ściśle uza- 26

28 leżniona od typu danych reprezentujących piksel obrazu. Wszystkie metody przetwarzania obrazów oraz operacje graficzne zostały zgromadzone w powyższej klasie abstrakcyjnej oraz klasie dziedziczącej po niej. Miało to na celu oddzielenie danych oraz możliwości ich przetwarzania od sposobu ich prezentacji oraz grupowania ich w postaci tzw. list. Wzorzec Metoda Fabrykująca zrealizowany jest poprzez zaimplementowanie klasy fits.image.fitsimagefactory, która dostarcza metodę statyczną getfitsimageextention, zwracającą referencję do obiektu typu fits.image.fitsimageextention. Metoda ta ma za zadanie zwrócić odpowiedni obiekt będący instancją jednej z klas adaptacyjnych dla obrazu zawartego w podstawowym HDU pliku FITS, na podstawie pobranego argumentu wywołania typu java.io.file reprezentującego plik w lokalnym systemie plików. Wybór odpowiedniego wyniku funkcji polega na odczytaniu z nagłówka podstawowego bloku danych słowa kluczowego BITPIX oraz na utworzeniu na podstawie jego wartości instancji odpowiedniej klasy pochodnej. Dodatkową funkcją powyższej metody jest weryfikacja poprawności przetwarzanych plików poprzez sprawdzenie wartości słowa kluczowego SIMPLE, potwierdzającego zgodność z standardem. Jedną ze zrealizowanych funkcjonalności jest także możliwość pobierania zaznaczanego fragmentu obrazu. Umożliwione to zostało poprzez stworzenie obiektu zawierającego fragment obrazu, posiadającego ten sam typ co obiekt reprezentujący obraz z którego pochodzi wycinek. Instancja klasy zawierająca fragment przechowywana jest w formie atrybutu obiektu z którego został pobrany fragment. Metoda createfitsimagepart klasy FitsExtentionImage16bitGray tworzy nowy obiekt klasy reprezentujący obraz w szesnastobitowej skali szarości, zawierający wycinek obrazu opisany przez prostokąt, którego współrzędne są zawarte w argumencie wywołania funkcji typu, java.awt.geom.rectangle2d. Utworzony obiekt przechowywany jest jako prywatny atrybut. Instancja klasy zawierająca obiekt przedstawiający jej fragment umożliwia sprawdzenie jego istnienia poprzez wywołanie funkcji havepartimage, zwracającej wartość logiczną oraz umożliwia pobranie obiektu zawierającego fragment obrazu poprzez wywołanie metody getpartimage. Zarówno instancja obiektu przechowująca obraz, jak i instancja obiektu przechowująca jego fragment, posiada atrybuty, które wskazują na te same obiekty, które są niezmienne i są takie same dla obu obrazów. Możliwe jest to dzięki implementacji prywatnego konstruktora pobierającego, referencje do wspólnych obiektów. Dzięki wyżej przedstawionemu schematowi tworzenia fragmentów obrazów możliwe jest rekursywne pobieranie wycinków zdjęć oraz powracanie z wybranego fragmentu do całości z której pochodzi fragment. 27

29 Rysunek 3.1: Diagram klas używanych do reprezentacji obrazów. 28

30 3.2.2 Przetwarzanie list plików W celu zapewnienia przetwarzania list plików używanych do prezentacji zaobserwowanego zjawiska została zaprojektowana klasa fits.viewer.fitsfilemanager. Ma ona za zadanie przechowywać informacje na temat obrazów aktualnie przetwarzanych w programie oraz grupować je we wcześniej wspomniane listy lub przedstawiać je w postaci pojedynczych plików. W przypadku plików zgrupowanych razem istnieje również możliwość przechodzenia po kolejnych elementach należących do grupy. Ponieważ aplikacji umożliwia otwieranie wielu list i wielu plików jednocześnie, aktualnie przetwarzane obrazy nie są przechowywane w pamięci operacyjnej przydzielonej aplikacji, lecz jest przechowywana jedynie informacja o położeniu plików zawierających zdjęcia w systemie plików. W przypadku otwierania paczek lub plików, które są otwierane za pomocą podania adresu URL, obrazy i skompresowane archiwa są pobierane i zapisane w tymczasowym katalogu użytkownika. Powyższe założenia zostały zrealizowane poprzez zaadaptowanie klasy javax.swing.tree.defaulttreemodel prezentującej model drzewa. Wierzchołkami przechowywanymi w drzewie są obiekty klasy FitsFileManager.FitsListNode, która prezentuje pojedynczy plik poprzez zawieranie dwóch atrybutów jakimi są: obiekt reprezentujący pojedynczy plik w systemie plików oraz wartość logiczna określająca czy dany plik jest plikiem zawierającym obraz czy jest plikiem prezentującym listę. Pojedyncze pliki FITS zawierające obrazy są przechowywane w drzewie jako liście znajdujące się na pierwszym poziomie drzewa, natomiast pliki wchodzące w skład jednej listy prezentowane są jako liście znajdujące się na drugim poziomie drzewa, posiadające wspólnego rodzica. Wspólnym poprzednikiem plików należących do jednej listy jest obiekt przedstawiający plik listy. Zadaniem wyżej prezentowanej klasy jest również zawarcie logiki dotyczącej nawigacji po aktualnie przetwarzanych obrazach w aplikacji. W celu zapewnienia tej funkcji klasa ma jeden atrybut typu FitsImageExtention, będący referencją do obiektu przedstawiającego aktualnie wyświetlony obraz. Poprzez udostępnienie dwóch metod, jakimi są setpreviousimage oraz setnextimage, możliwe jest inicjalizowanie obiektów przedstawiających obrazy znajdujące na tej samej liście plików, odpowiednio przed lub za aktualnie przechowywanym obrazem. Do uzyskania nowych obiektów wykorzystywana jest statyczna funkcja getfitsimageextention klasy fits.image.fitsimageextention. Po wywołaniu jednej z wymienionych metod nawigacji wartość referencji wskazującej na aktualnie przetwarzany obraz zostaje uaktualniona tak, aby wskazywać na nowo utworzoną instancję klasy. Aktualizacja interfejsu użytkownika wyświetlającego aktualnie przetwarzany obraz realizowana jest za pomocą wywołania funkcji repaintimage, wchodzącej w skład interfejsu fits.viwer.fitsrepaint. Referencja wskazująca na obiekt implementujący przedstawiony interfejs jest jednym z atrybutów klasy. Dodatkowo zaimplementowane zostały dwie pomocnicze metody, umożliwiające sprawdzenie istnienia plików 29

31 na liście znajdujących się przed i za aktualnie przetwarzanym elementem na liście, są nimi isnextonthelist oraz ispreviousonthelist. Klasa adaptująca obiekt przedstawiający drzewo dostarcza dwie funkcje umożliwiające dodawanie elementów do drzewa. Pierwsza z nich, openfile, dodaje nowy węzeł do drzewa na podstawie pobranego argumentu. Nowy węzeł reprezentuje plik FITS zawierający obraz. Drugą zaimplementowaną funkcją jest openfilelist, pobierając jako argument plik przedstawiający listę. Ma ona za zadanie wczytać nazwy plików należących do listy oraz utworzyć w modelu drzewa węzeł przedstawiający listę oraz węzły reprezentujące pliki należące do listy, będące dziećmi węzła listy. Dodatkowo funkcja sprawdza czy wymienione pliki znajdują się w odpowiednim katalogu w systemie plików, czyli w tym samym katalogu co plik listy. Dodatkowo zawartość klasy javax.swing.tree.defaulttreemodel jest prezentowana za pomocą komponentu graficznego javax.swing.jtree. Komponent ten wchodzi w skład interfejsu użytkownika aplikacji, dzięki czemu został wykorzystany mechanizm zdarzeń umożliwiający dodatkową nawigację po przetwarzanych obrazach (rysunek 3.2). Dzięki implementacji słuchaczy zdarzeń pochodzących z myszki oraz klawiatury możliwe jest wybieranie konkretnego obrazu za pomocą kliknięcia oraz przechodzenie po liście za pomocą strzałek klawiatury. Poprzez dodanie menu kontekstowego umożliwione zostało także zamykanie pojedynczych obrazów lub całych list plików Pobieranie paczek plików oraz plików FITS Mechanizm pobierania paczek oraz plików realizowany jest poprzez klasę fits.viewer.fitsframe.urlwindow, mającą za zadanie wyświetlenie okna dialogowego pobierającego adres URL oraz dane potrzebne do autoryzacji połączenia, jeśli jest to wymagane. Następnie klasa ta tworzy nowy pomocniczy obiekt typu fits.util.fitsurlconnection odpowiedzialny za pobranie zasobu z zadanego adresu oraz zapisanie go w tymczasowym katalogu użytkownika. Pobieranie danych wykonane jest przez użycie obiektu klasy java.lang.url, zwracającego instancję klasy prezentującą połączenie z zadanym zasobem oraz zwracającą strumień pobieranych danych. Po wywołaniu metody Download() utworzonego obiektu klasy FitsURLConnection następuje inicjalizacja i uruchomienie pobierania zasobu w oddzielnym wątku, który zapisuje dane z utworzonego strumienia do nowego pliku w katalogu tymczasowym. W celu powiadomienia klasy URLWindow o zakończeniu procesu pobierania danych lub o jego przerwaniu z powodu błędu albo przerwaniu go przez użytkownika została wykorzystana kolejka zdarzeń biblioteki AWT poprzez dodanie własnego typu słuchacza oraz własnego zdarzenia: odpowiednio interfejsu fits.util.downloadlistener oraz dziedziczącej po zdarzeniu AWT klasy fits.util.fitsdownloadevent. Implementująca powyższy interfejs klasa URL- Window po otrzymaniu wygenerowanego zdarzenia sprawdza status operacji po- 30

32 Rysunek 3.2: Okno interfejsu użytkownika. 31

33 bierania danych. W przypadku prawidłowego wykonania zadania wywołuje metodę openfile() obiektu typu fits.viewer.fitsfilemanager dla pobranych pojedynczych plików FITS. Dla pobranych skompresowanych archiwów tar.gz wykonywana jest dodatkowo operacja dekompresji oraz dearchiwizacji, realizowane przez wywołanie statycznej metody klasy fits.util.targzunpuck. Operacja ta polega na utworzeniu standardowego strumienia danych, zawierającego pobrane archiwum, i przekształceniu go w strumień reprezentujący zdekompresowane dane. Realizowane jest to przez utworzenie obiektu klasy java.io.fileinputstream i zainicjalizowanie na jego podstawie instancji klasy java.util.zip.gzipinputstream. Przy pomocy otrzymanego obiektu zostaje skonstruowany obiekt klasy com.ice.tar.tararchive, który posiada metodę wykonywającą operacje dearchiwizacji pobranego strumienia oraz operacje zapisu przetworzonego strumienia do pliku. Następnie tworzony jest obiekt typu fits.viewer.fitsframe.fitslistfilechooser, mający za zadanie przeszukać rekurencyjnie otrzymany wcześniej, w procesie dekompresji oraz dearchiwizacji katalog, w celu odnalezienia plików zawierających sekwencje zdjęć. Kryterium wyszukiwania jest wystąpienie w nazwie plików ciągu znaków list. Następnie nazwy znalezionych plików wyświetlane są na liście wielokrotnego wyboru w wyświetlonym oknie dialogowym. Po wyborze elementów wywoływana jest dla każdego z nich metoda openfilelist() klasy fits.viewer.fitsfilemanager. Wyświetlane okno posiada również dodatkową opcję, dostępną pod przyciskiem show all files, która wyświetla w oknie wyboru wszystkie pliki znajdujące się w pobranym folderze. Część opisanej powyżej procedury, dotyczącej dearchiwizacji i dekompresji paczek plików oraz wyboru list w nich zawartych, jest identyczna dla paczek znajdujących się na lokalnym komputerze użytkownika. 3.3 Możliwość rozszerzenia aplikacji Jednym z założeń podczas tworzenia aplikacji była możliwość jej rozszerzenia, aby mogła wyświetlać obrazy zawarte w plikach FITS, zapisane w dowolnym formacie. Aktualnie istnieje możliwość prezentacji obrazów, których piksele zapisane są za pomocą szesnastu bitów. W celu rozszerzenia aplikacji należy zaimplementować klasę dziedziczącą po klasie fits.image.fitsimageextention reprezentującą jeden z wybranych pozostałych formatów przechowywania obrazów. Nowa klasa powinna zawierać definicję następujących metod: autocontrast() funkcja umożliwiająca automatyczną poprawę kontrastu. Powinna ona zmienić wartości pikseli obrazu przechowywanego jako atrybut currentimage klasy BufferedImage. Nie jest z góry narzucony algorytm, jaki powinien być użyty do wykonania tej czynności. W przypadku zaimplementowanej klasy wykorzystana jest zmiana odwzorowań poziomów jasności. 32

34 changeimagevalues(int min, int max) funkcja realizująca algorytm zmiany odwzorowań poziomów jasności obrazu. Powinna ona zmieniać wartości obrazu zapisanego jako atrybut currentimage. Wartość pierwszego argumentu oznacza dolny próg odwzorowania, natomiast druga wartość oznacza górny próg. createfitsimagepart (Rectangle2D.Double rectangle) funkcja tworząca obiekt reprezentujący fragment obrazu. Współrzędne nowo tworzonego obrazu są przekazywane jako obiekt reprezentujący prostokąt, znajdujący się wewnątrz zdjęcia z którego pobierany jest fragment. Nowo utworzony obiekt powinien być wskazywany przez atrybut fitsimagepart. gammacorrection(double correctionvalue) funkcja realizująca korekcję gamma aktualnie wyświetlanego obrazu. Współczynnik korekcji przekazywany jest jako argument typu double. getcurrentminmaxvalues() funkcja zwracająca wartości zmian poziomów odwzorowań jasności poprzez obiekt typu java.awt.geom.point2d. getnumberofvalues() funkcja zwracająca liczbę całkowitą typu int, określającą ilość możliwych poziomów jasności obrazu. getoriginalpoint(int x, int y) funkcja zwracająca oryginalne położenie piksela na podstawie położenia jego punktu na wyświetlanym obrazie poprzez obiekt typu java.awt.geom.point2d. Chodzi tu o możliwość uzyskania współrzędnych punktu oryginalnego obrazu na podstawie współrzędnych obrazu wyświetlanego, który może być przekształcony przez wykonie na nim operacji graficznych takich jak: skalowanie, odbicie lustrzane względem osi OX bądź osi OY. Powyższa funkcja niezbędna jest do określenia oryginalnej wartości piksela na podstawie wskazanego piksela na obrazie, którego wartość mogła ulec zmianie. getpixelvalue(int x, int y) funkcja zwracająca wartość piksela oryginalnego obrazu na podstawie jego położenia na obrazie. Zwracaną wartością jest liczba całkowita typu int. pixelsaddvalue(float value) funkcja dodająca do obrazu stałą. Wartość dodawanej stałej przekazywana jest jako argument typu float. rescalepixelsvalue(float value) funkcja mnożąca wartości obrazu przez wartość przekazaną w argumencie jako liczbę typu float. resetimage() funkcja zmieniająca aktualnie wyświetlany obraz, czyli atrybut currentimage, tak aby przedstawiał on stan obraz znajdujący się w stanie 33

35 takim, jak, jest zapisany w pliku. Nie powinien być poddany żadnej operacji graficznej ani zmianie wartości pikseli, czyli powinien być taki sam jak originalimage. resetimagevalues() funkcja zmieniająca wartości pikseli obrazu tak, aby były zgodne z wartościami oryginalnego obrazu. W odróżnieniu od poprzedniej funkcji wyniki wykonanych operacji geometrycznych na aktualnie wyświetlanym obrazie powinny pozostać niezmienione. scale(double scalex, double scaley) funkcja skalująca aktualnie wyświetlany obraz czyli obraz, przedstawiany za pomocą atrybutu currentimage. Metoda pobiera dwa argumenty typu double określające odpowiednio wymiar skalowania w poziomie oraz pionie. symmetryx() funkcja realizująca lustrzane odbicie aktualnie wyświetlanego obrazu względem osi współrzędnych OX. symmetryy() funkcja realizująca lustrzane odbicie obrazu względem osi współrzędnych OY. Oprócz wymienionych funkcji wprowadzono, także grupę metod zwracających wartości określające aktualny stan obrazu. Miało to na celu umożliwienie zachowania wykonanych operacji geometrycznych w trakcie przeglądania jednej listy plików, tak aby użytkownik wykonując operacje na jednym z obrazów należącym do listy nie musiał powtarzać tej czynności podczas wyświetlania następnego elementu listy. W skład tej grupy funkcji wchodzą: issymmetryx() funkcja zwracająca wartość typu boolean określającą czy dany obraz jest odbity względem osi OX. issymmetryy() funkcja zwracająca wartość typu boolean określającą czy dany obraz jest odbity względem osi OY. getcurentscale() funkcja zwracająca wartości określające skalę obrazu w poziomie i w pionie poprzez obiekt typu java.awt.geom.point2d.double. Osoba rozszerzająca aplikację powinna również zaimplementować konstruktor tworzonej klasy w celu odczytu wartości obrazów zapisanych w pliku oraz inicjalizacji obiektów przechowujących te wartości. W trakcie konstrukcji obiektów nowych klas powinien zostać wywołany konstruktor klasy nadrzędnej. Oprócz implementacji wyżej wymienionych funkcji należy również zmodyfikować metodę getfitsimageextention klasy fits.image.fitsimagefactory tak, aby na podstawie wczytanej wartości słowa kluczowego BITPIX o wartości odpowiadającej nowo napisanej klasie, zwracała obiekt nowej klasy. 34

36 Zaprezentowany sposób rozszerzenia aplikacji o możliwość wyświetlania obrazów zapisanych w innym formacie niż szesnastobitowa skala szarości, nie narzuca sposobu wykonywania operacji graficznych na obrazie oraz pozostawia możliwość implementacji dowolnego algorytmu poprawy kontrastu. W pewien sposób również nie określa biblioteki jaka powinna być użyta do odczytu pliku, ale raczej powinna być to biblioteka nom.tam.fits, ponieważ niezbędne jest przekazanie obiektu klasy Header należącej do tej biblioteki, do konstruktora klasy FitsImageExtention. Zasadniczą rzeczą, jaka powinna być zapewniona jest aby klasą reprezentującą wartości obrazu była klasa java.awt.bufferedimage, ponieważ obiekty tej klasy są używane w graficznym interfejsie użytkownika. 3.4 Przekazywanie parametrów apletowi Zaimplementowana aplikacja w formie apletu posiada możliwość czytania wartości parametrów przekazywanych za pomocą znaczników HTML. Podczas inicjalizacji programu w środowisku przeglądarki internetowej zostają pobrane następujące parametry: FILE znacznik posiadający przypisany łańcuch znaków zawierający adres URL pliku FITS. PACKAGE znacznik posiadający przypisany łańcuch znaków zawierający adres URL paczki stosowanej w projekcie π of the Sky. LIST 1,..., LIST 10 znacznik posiadający przypisany łańcuch znaków zawierający relatywną ścieżkę położenia pliku, przedstawiającego listę, względem katalogu który zostaje utworzony w procesie dearchiwizacji paczki przekazanej za pomocą parametru PACKAGE. Wszystkie wymienione wyżej parametry są opcjonalne i mogą występować w różnej konfiguracji, lecz podanie znacznika wskazującego na listę bez wyspecyfikowania paczki zostanie zignorowane. Przykładowe parametry wraz z atrybutami służącymi do jego uruchomienia, umieszczonymi w kodzie HTML, wyglądają w następujący sposób: <applet code =" fits / viewer / FitsViewerAplet. class " archive =" FitsViewerAplet. jar " PACKAGE = " http :// www. fuw. edu.pl /~ mmazur / Frame tar.gz" FILE = " http :// www. fuw. edu.pl /~ mmazur / eventframe504_camera0_eventno0_currframe507. fit " 35

37 LIST_1 ="/ Frame00754 / Cam0 / list0 " width =100 height =40 > </ applet > Po pobraniu wartości parametrów zawartych w kodzie HTML następuje taka sama procedura jak podczas pobierania zasobu spod zadanego adresu URL. Jedyna różnica polega na tym, że gdy określimy parametry wskazujące na listy, to podczas operacji otwierania paczki użytkownik nie zostanie poproszony o wskazanie plików zawierających listy. 3.5 Połączenie z bazą danych projektu Aplikacja umożliwia połączenie się z dwoma roboczymi bazami danych projektu w celu pobrania informacji na temat gwiazd znajdujących się na obrazie. Zapytanie, którego wynik zostaje prezentowany przez aplikacje polega na poszukiwaniu gwiazd znajdujących się w zadanym okręgu. Posiada ono trzy parametry, z których dwa określają współrzędne niebieskie piksela będącego środkiem okręgu, natomiast trzeci określa promień poszukiwań. Nie istnieje możliwość bezpośredniego połączenia się poza siecią lokalną z serwerami bazodanowymi. Dlatego też, w celu pobierania danych, został wykorzystany istniejący już wcześniej serwer aplikacji działający poprzez WWW. Został on stworzony na potrzeby innej aplikacji, ale umożliwia on między innymi przesłanie za pomocą metody POST, protokołu HTTP, treści zapytania oraz danych niezbędnych do połączenia z wybraną bazą danych. W odpowiedzi zwracany jest plik tekstowy zawierający wynik zapytania. 36

38 Rozdział 4 Zastosowane metody i algorytmy W zaimplementowanych metodach poprawy kontrastu, takich jak modyfikacja odwzorowań jasności oraz korekcji gamma została użyta pomocnicza struktura danych, jaką jest tablica pośrednia (ang. Look Up Table LUT). Reprezentowana jest ona jako jednowymiarowa tabela, przechowująca liczby całkowite, o wielkość równej ilości poziomów jasności jakie mogą występować na przetwarzanym obrazie. Jej indeksy odpowiadają luminancji elementów zdjęcia przed wykonaniem przekształcenia, natomiast odpowiadające im elementy zawierają wartości obrazu po wykonaniu przekształcenia. Obliczenie wynikowego obrazu polega na wykonaniu następującego odwzorowania: q(i, j) = LUT [p(i, j)] (4.1) Przy czym q(i, j) jest wartością piksela wynikowego obrazu w punkcie o współrzędnych (i, j) a p(i, j) jest wartością piksela obrazu wejściowego w punkcie (i, j). Wartości tablicy pośredniej zostają wyznaczone w poniższy sposób: LUT [p(i, j)] = f(p(i, j)) (4.2) Gdzie f jest funkcją 4.4 lub funkcją 4.5, p(i, j) wartością elementu zdjęcia o współrzędnych (i, j), a LU T symbolizuję tablicę pośrednią. W opisanych niżej metodach poprawy jakości wyświetlanego zdjęcia stosowany jest również histogram obrazu. Ma on za zadanie przedstawić rozkład prawdopodobieństwa występowania poszczególnych możliwych jasności na zdjęciu. Wyznaczenie jego wartości można przedstawić za pomocą funkcji P (f i ) = n i /N (4.3) gdzie P (f i ) jest wartością histogramu dla jasności f i, n i jest liczbą pikseli w obrazie o jasności f i, natomiast N jest liczbą wszystkich elementów obrazu. 37

39 4.1 Korekcja kontrastu obrazu Poprawa jakości wyświetlanych obrazów w zaimplementowanej aplikacji, wykonywana za pomocą korekcji kontrastu, ma przede wszystkim na celu ułatwienie obserwacji zjawisk przedstawianych na przetwarzanych zdjęciach. Obrazy wczytywane z plików i wyświetlane w niezmodyfikowanej formie mało mówią o zaistniałym zdarzeniu, ponieważ trudno jest zaobserwować jakiekolwiek obiekty lub widoczna jest jedynie ich mniejsza część (rysunek 4.1). Podyktowane jest to tym, iż wykonane zdjęcia są podstawowym źródłem danych służących do analizy zjawisk astrofizycznych i nawet niewielkie różnice w wartościach pikseli mogą zawierać ważne informacje, lecz nie są dostrzegalne przez ludzkie oko. Jeśli spojrzymy na histogram obrazu pobranego bezpośrednio z kamery, to możemy zauważyć, że większość pikseli ma wartości znajdujące się w dolnej części skali możliwych poziomów jasności (rysunek 4.2). Takie rozłożenie wartości obrazu powoduje, że trudno jest odróżnić jakiekolwiek elementy znajdujące się na zdjęciu od jego tła. Dostrzegalne są jedynie obiekty posiadające luminancje z górnej części zakresu jasności. Do powszechnie stosowanych algorytmów poprawy kontrastu możemy zaliczyć między innymi: wyrównanie histogramu, korekcję gamma, zmianę odwzorowań poziomów jasności oraz rozciągnięcie histogramu. Wszystkie spośród wymienionych metod zostały wypróbowane podczas implementacji programu. Algorytmem, którego próby zastosowania zostały zaniechane od razu był algorytm rozciągający zakres histogramu. Wynikło to z faktu, że obrazy pochodzące bezpośrednio z kamery zawierają elementy o jasności z całego możliwego zakresu i wymieniona metoda nie dawała żadnych rezultatów. Pierwszą z testowanych metod był algorytm wyrównania histogramu, którego działanie polega na modyfikacji rozkładu poziomów jasności tak, aby jego dystrybuanta była funkcją liniową. W efekcie w histogramie zmodyfikowanego obrazu występuje rozproszenie poziomów jasności tam, gdzie istnieje zgęszczenie w oryginale oraz kompresowanie poziomów jasności w mniej gęstych obszarach. Przy zastosowaniu powyższego algorytmu można zauważyć wiele obiektów przedtem niedostrzegalnych, lecz zbyt duża część pikseli przybiera wysokie wartości, przez co zdjęcie staję się niewyraźne. Efekt wykonania tej metody na wcześniej prezentowanym obrazie przedstawiony jest na rysunku 4.3, a odpowiadający mu histogram na rysunku 4.4. Następną testowaną metodą była korekcja gamma opisana w podrozdziale 4.2. Tutaj także nie uzyskano satysfakcjonujących wyników, ponieważ stosując mały współczynnik korekcji uzyskuje się mało zauważalne wyniki, natomiast przy zwiększaniu jego wartości uzyskuję się ogólny efekt zwiększenia jasności całego obrazu. Na histogramie przedstawionym na rysunku 4.6,uzyskanym przez zastosowanie współczynnika o wartości równej 3, widać że zgęszczenie wartości obrazu głównie przesunęło się w górną część skali jasności i zostało przy tym mało rozproszone (wynikowy obraz przekształcenia pokazany jest na rysunku 4.5). 38

40 Rysunek 4.1: Obraz pochodzący bezpośrednio z kamery. Rysunek 4.2: Histogram obrazu znajdującego się na rysunku

41 Rysunek 4.3: Obraz znajdujący się na rysunku 4.1, zmodyfikowany poprzez wyrównanie histogramu. Rysunek 4.4: Histogram obrazu znajdującego się na rysunku