Działająca przez WWW przeglądarka do plików FITS

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
Spis treści
Wprowadzenie
Cel pracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Motywacja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Wymagania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 Projekt π of the Sky
1.1 Cel projektu . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Główne działania projektu . . . . . . . . . . . . . . . .
1.2.1 Obserwacja błysków gamma . . . . . . . . . . . .
1.2.2 Wykrywanie pozostałych zjawisk astrofizycznych
1.2.3 Największe osiągnięcie projektu . . . . . . . . . .
1.3 Miejsce tej pracy w projekcie π of the Sky . . . . . . . .
2 Standard FITS
2.1 Struktura plików FITS . . . . . . . . . . . .
2.1.1 Nagłówek bloku danych . . . . . . .
2.1.2 Format wartość przechowywanych w
bloku danych . . . . . . . . . . . . .
2.2 Pliki FITS używane w projekcie π of the Sky
2.2.1 Format zapisu obrazu . . . . . . . . .
2.2.2 Fragmenty obrazów . . . . . . . . . .
2.2.3 Używane słowa kluczowe . . . . . . .
2.2.4 Paczki obrazów . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . . . . . . . . .
. . . . . . . . . . . .
tabeli podstawowego
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
3 Opis zaimplementowanej przeglądarki plików FITS
3.1 Wybrana technologia i wykorzystywane biblioteki . .
3.2 Struktura aplikacji . . . . . . . . . . . . . . . . . . .
3.2.1 Reprezentacja obrazu . . . . . . . . . . . . . .
3.2.2 Przetwarzanie list plików . . . . . . . . . . . .
3.2.3 Pobieranie paczek plików oraz plików FITS . .
3.3 Możliwość rozszerzenia aplikacji . . . . . . . . . . . .
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
3
3
4
6
. 6
. 8
. 8
. 12
. 13
. 14
16
. 16
. 17
.
.
.
.
.
.
19
20
20
21
21
23
.
.
.
.
.
.
24
24
26
26
29
30
32
3.4
3.5
Przekazywanie parametrów apletowi . . . . . . . . . . . . . . . . . . 35
Połączenie z bazą danych projektu . . . . . . . . . . . . . . . . . . 36
4 Zastosowane metody i algorytmy
4.1 Korekcja kontrastu obrazu . . . . . . . . . . . . . . .
4.2 Korekcja gamma obrazu . . . . . . . . . . . . . . . .
4.3 Sposób wykonywania operacji graficznych na obrazie
4.4 Algorytm wyznaczania współrzędnych niebieskich . .
Podsumowanie
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
37
38
42
45
47
49
2
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
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
• 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
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
1049 erg1 , natomiast energia emitowana podczas długiego błysku szacowana jest
na około 1051 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 prze1
Jednostka pracy i energii w układzie miar CGS. [13]
6
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
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 1051 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
1.2.1
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
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 1o . BASTE wraz z CGRO znajdował się na orbicie do
roku 2000. 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
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 14-15 mag2 . 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 20o x 20o . 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 paralaksy3 . 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ę trzyeta2
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
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 21o x 21o (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
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 ASAS4 (All Sky Automated Survey). Mimo iż prototyp nie
działa bardzo długo ma już na swoim koncie sukcesy w skali światowej.
1.2.2
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 107 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 0o do 360o 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 0o do 90o dla punktów na półkuli północnej i od od 0o do −90o dla
punktów na półkuli południowej [4].
12
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.
1.2.3
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 syste13
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 10000 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, 5o 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 za14
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
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, nato16
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 2880. 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ą.
2.1.1
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
decymalnych 32-126, 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
• 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 0 = BZERO + BSCALE ∗ y
2.1.2
(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
• 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 2.1.
2.2 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.
2.2.1
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 65536 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 32768. Dodatkowo obraz przed zapisem może
zostać przekształcony przez oprogramowanie kamery. Przekształcenie to polega
20
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.
2.2.2
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.
2.2.3
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
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
• 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.
2.2.4
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
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
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
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.
3.2.1
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 uza26
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
Rysunek 3.1: Diagram klas używanych do reprezentacji obrazów.
28
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
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.
3.2.3
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 URLWindow po otrzymaniu wygenerowanego zdarzenia sprawdza status operacji po30
Rysunek 3.2: Okno interfejsu użytkownika.
31
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
• 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
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
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 / Frame00754 . tar . gz "
FILE =
" http :// www . fuw . edu . pl /~ mmazur /
e ve nt fr a me 50 4_ ca m er a0 _e v en tn o0 _ cu rr fr am e 50 7 . fit "
35
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
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) = LU T [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:
LU T [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 (fi ) = ni /N
(4.3)
gdzie P (fi ) jest wartością histogramu dla jasności fi , ni jest liczbą pikseli w obrazie
o jasności fi , natomiast N jest liczbą wszystkich elementów obrazu.
37
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
Rysunek 4.1: Obraz pochodzący bezpośrednio z kamery.
Rysunek 4.2: Histogram obrazu znajdującego się na rysunku 4.1.
39
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 4.3.
40
Rysunek 4.5: Obraz znajdujący się na rysunku 4.1, zmodyfikowany poprzez korekcję gamma.
Rysunek 4.6: Histogram obrazu znajdującego się na rysunku 4.5.
41
Zastosowaną domyślną metodą korekcji kontrastu jest zmiana odwzorowania
poziomów jasności obrazu. Zaimplementowane przekształcenie zmieniające wartości obrazu polega na zastosowaniu następującej funkcji:



0
gdy a ∗ i + b < 0
f (i) = a ∗ i + b gdy 0 ¬ a ∗ i + b ¬ imax


imax
gdy a ∗ i + b > imax
(4.4)
gdzie i jest przekształcanym poziomem jasności, imax jest maksymalną możliwą
wartością obrazu natomiast a i b są stałymi. Jasnościom znajdującym się poniżej pewnego dolnego progu przypisywana jest wartość zero, natomiast jasności
znajdujące się powyżej pewnego górnego progu przyjmują maksymalną możliwą
luminancję na obrazie. Pozostała część jest przeskalowana na cały dostępny zakres
przy pomocy funkcji liniowej, której współczynniki wyznaczane są na podstawie
wartości progowych. Dolny próg wyznaczany jest na podstawie histogramu aktualnie przetwarzanego obrazu w ten sposób, że jest ona równy poziomowi jasności, dla
którego suma pikseli będących ciemniejszych od niego wynosi 10% liczby wszystkich elementów na obrazie. Podobnie wyznaczana jest górna liczba, z tym że suma
ciemniejszych pikseli wynosi 99,8%. Obie wartości procentowe zostały subiektywnie dobrane na podstawie efektów uzyskanych poprzez przetwarzanie kilku zdjęć.
Zaprezentowana metoda pozwala dynamicznie wyznaczać przekształcenie kontrastu przez co jest skuteczna zarówno dla zdjęć pochodzących bezpośrednio z kamery,
jak i dla obrazów będących ich małymi wycinkami. Rezultat uzyskany dla prezentowanego poprzednio obrazu pokazano na rysunku 4.8, a jego histogram przedstawia
ilustracja 4.9. Można zauważyć, że zgęszczenie znajdujące się w dolnej części skali
oryginalnego obrazu zostało rozproszone na szeroki zakres, oraz że uzyskano stosunkowo wysokie wartości dla skrajnych poziomów w porównaniu do reszty skali.
Wykres przedstawiający wykonane przekształcenie umieszczony został na rysunku
4.7. Zostało również umożliwione ręczne określenie wartości progowych używanych
w wyżej przedstawionej metodzie. W tym celu do głównego panelu aplikacji zostały dodane dwa suwaki, z których jeden odpowiada wartości górnej natomiast
drugi wartości dolnej.
4.2
Korekcja gamma obrazu
Różne urządzenia wizualizacji mogą wprowadzać nieliniowość w odwzorowywaniu
poziomów jasności wyświetlanego obrazu. W celu uzyskania zależności liniowej
pomiędzy wartością numeryczną znajdującą się w pamięci urządzenia a uzyskiwaną jasnością na ekranie urządzenia, stosuje się korekcję gamma zwaną również
42
Rysunek 4.7: Wykres funkcji użytej do uzyskania obrazu 4.8.
Rysunek 4.8: Obraz znajdujący się na rysunku 4.1, zmodyfikowany poprzez zastosowanie domyślnej metody poprawy kontrastu.
43
Rysunek 4.9: Histogram obrazu znajdującego się na rysunku 4.8.
kompensacją logarytmiczną. Operacja ta jest realizowana za pomocą funkcji:
fi
0
fi = fmax ∗ (
fmax
1
) gamma
(4.5)
0
gdzie fi jest wartością piksela przed wykonaniem operacji, fi wartością piksela po wykonaniu operacji, fmax maksymalnym możliwym poziomem luminancji
na obrazie, natomiast gamma jest współczynnikiem korekcji. Przy współczynniku równym jeden uzyskujemy przekształcenie tożsamościowe. Powyższa metoda
często jest używana jako jedna ze wstępnych metod poprawy kontrastu, jednakże
w stosunku do przetwarzanych obrazów okazała się niewystarczająco skuteczna.
Dodatkowo trudno jest dobrać wartość współczynnika korekcji, która jest odpowiednia dla wszystkich obrazów. Operacja ta została dodana do aplikacji jako
metoda, która umożliwia ręczną korekcję kontrastu przez użytkownika.
W zaimplementowanej aplikacji korekcja gamma dla aktualnie wyświetlanego obrazu jest dostępna w menu->Processing->Gamma correction. Operacja jest
wykonywana tylko na aktualnie wyświetlonym obrazie ze współczynnikiem określonym przez użytkownika z zakresu wartości 0.1-5.
44
4.3
Sposób wykonywania operacji graficznych na
obrazie
Wśród wymagań dotyczących aplikacji znalazły się przekształcenia geometryczne,
w których skład wchodzą takie operacje jak skalowanie obrazu oraz odbicia obrazu
względem osi OX i OY kartezjańskiego układu współrzędnych. Wszystkie te operacje można zrealizować poprzez wykonanie jednego przekształcenia polegającego
na zmianie położenia pikseli wejściowego obrazu według wzoru:
0
P =M∗P
h
(4.6)
iT
opisuje położenie elementu na pierwotnym obrazie,
gdzie P = xp yp 1
M jest macierzą odzwierciedlającą wykonywaną operację graficzną natomiast
h
iT
0
P = xk yk 1
jest położeniem elementu na obrazie wyjściowym. Do wykonania skalowania została wykorzystana następująca macierz


Sx 0 0


M =  0 Sy 0 
0 0 1
gdzie Sx jest skalą obrazu w poziomie, a Sy jest skalą w pionie. Lustrzane odbicie
zdjęcia względem osi OX zostało wykonane z użyciem macierzy


1 0 0


M =  0 −1 Ty 
0 0 1
przy czym Ty jest wartością przesunięcia obrazu w pionie i jest ona równa wysokości obrazu. Dodatkowe przesunięcie obrazu spowodowane jest tym, że wynik
wykonania samego przekształcenia symetrii względem osi OX znajduje się w IV
ćwiartce układu współrzędnych, a podczas wyświetlania zawartości obiektu prezentującego obraz brane pod uwagę są jedynie piksele znajdujące się w I ćwiartce
układu współrzędnych. Przy pomocy analogicznej macierzy wykonywana jest operacja odbicia względem osi OY


−1 0 Tx


M= 0 1 0 
0 0 1
podobnie jak poprzednio uzyskany wynik jest dodatkowo przesuwany, z tym że
w kierunku poziomym o wartość Tx równą szerokości obrazu. W tym przypadku
wynik symetrii względem osi OY znajduje się w II ćwiartce układu współrzędnych.
45
W zaimplementowanej aplikacji do wykonania przekształceń geometrycznych
wykorzystywana jest klasa java.awt.AffineTransform. Reprezentuje ona macierz
przekształcenia geometrycznego o wymiarach 3 × 3, w której wartości dwóch
pierwszych wierszy określane są na podstawie argumentów
h
itypu double konstruktora klasy. Ostatni wiersz jest stały i ma postać 0 0 1 . Sama operacja zwracająca wynik przekształcenia wykonywana jest za pomocą metody filter klasy java.awt.image.AffineTransformOp , która pobiera jako argumenty dwa obiekty klasy
java.awt.image.BufferedImage, reprezentujące obraz źródłowy oraz obraz wynikowy. Obiekt klasy, zawierający dokonywane przekształcenie przekazywany jest podczas inicjalizacji instancji klasy wykonującej operację. Zaletą wykorzystania wyżej
wymienionych klas do operacji geometrycznych jest to, że możliwe jest przechowywanie obiektu reprezentującego złożenie dotychczas wykonanych operacji geometrycznych na przetwarzanym obrazie, czyli obiektu za pomocą, którego możliwe
jest uzyskanie obrazu, na którym wykonano kilka przekształceń geometrycznych
poprzez wykonanie jednej operacji będącej ich złożeniem. Posiadając jedną operacje można łatwo wyznaczyć przekształcenie do niej odwrotne co jest ważne ponieważ znając współrzędne piksela na wyświetlanym obrazie można obliczyć jego
położenie na obrazie źródłowym. Jest to używane do wyświetlania wartości pikseli
oryginalnego obrazu niezależnie od sposobu jego prezentacji. Powyższa operacja
realizowana jest poprzez metodę inverseTransform klasy AffineTransform, która
pobiera współrzędne punktu i na ich podstawie zwraca współrzędne po wykonaniu przekształcenia odwrotnego do przekształcenia, które reprezentuje.
Podczas wykonywania przekształceń może zdarzyć się, że powstaną piksele
wynikowego obrazu, dla których nie da się jednoznacznie określić odpowiadającego elementu na obrazie wejściowym. W celu rozwiązania tego problemu klasa
java.awt.image.AffineTransformOp umożliwia użycie trzech strategii interpolacji
wartości elementów obrazu przekształconego, w przypadku gdy nie da się bezpośrednio określić ich luminancji. Pierwsza z nich nazywana jest interpolacją najbliższego sąsiada (ang. nearest neighbor ) i polega ona na skopiowaniu wartości
najbliższego piksela. Jest ona najprostszą i najszybszą metodą. Drugą z nich jest
strategia dwuliniowa (ang. bilinear ), biorąca pod uwagę cztery sąsiednie piksele
podczas interpolacji. Ostania metoda nazywana jest dwusześcienną i bierze ona
pod uwagę wszystkie osiem pikseli znajdujących się w pobliżu obliczanego elementu. Z pośród wymienionych strategii w aplikacji została zastosowana pierwsza
z nich. Wybór jej został dokonany na podstawie subiektywnej oceny rezultatów
uzyskanych po zastosowaniu każdej z nich dla tego samego obrazu do wykonania
jednakowego przekształcenia.
46
4.4
Algorytm wyznaczania współrzędnych niebieskich
Procedura transformacji współrzędnych (x, y) piksela znajdującego się na obrazie
na odpowiadające współrzędne niebieskie składa się z dwóch kroków. Pierwszy
etap polega na obliczeniu odległości danego elementu od środka zdjęcia, wyrażonej w stopniach. Druga część wyznacza rektascensję oraz deklinację piksela na
podstawie wcześniej wyznaczonych odległości oraz współrzędnych obrazu, przez
wykonanie odpowiednich przekształceń trygonometrycznych.
Wyznaczenie różnic rektascensji i deklinacji pomiędzy położeniem danego piksela oraz położeniem środka obrazu wykonywane jest przez zastosowanie następującej transformaty :
∆λ =
X
Pij ∗ (∆x)i ∗ (∆y)i
∆δ =
i,j¬O
X
Qij ∗ (∆x)i ∗ (∆y)i
(4.7)
i,j¬O
gdzie ∆λ jest różnicą rektascensji wyrażoną w radianach,∆δ jest różnicą deklinacji wyrażoną radianach, ∆x jest odległością w poziomie danego piksela od piksela
będącego środkiem obrazu, ∆y jest odległością w pionie od środka, O jest kolejnością wykonania przekształcenia, a Pij i Qij są współczynnikami transformaty.
Wartość O jest zapisana w nagłówku pliku zawierającego obraz, jako wartość odpowiadająca słowu kluczowemu AST ORD, natomiast Pij oraz Qij odpowiadają
polom nagłówka PAR X 0, PAR X 1, . . . , PAR X 20 oraz PAR Y 0, PAR Y 1,
. . . , PAR Y 20. Po wykonaniu powyższej transformaty uzyskane wyniki przeliczane są na stopnie. W drugiej części algorytmu wyznaczane są dokładne wartości
współrzędnych niebieskich. Możliwe jest to dzięki znajomości współrzędnych środka obrazu, zapisanych jako pola RA i DEC. Po wykonaniu odpowiednich przekształceń trygonometrycznych zwracany jest wynik w postaci rektascensji wyrażonej w godzinach oraz deklinacji wyrażonej w stopniach. Zarówno rektascensja
jak i deklinacja są miarami kąta, ale często druga wartość podawana jest mierze
godzinnej (od 0h do 24h).
Podczas wykonywania obliczeń trzeba wziąć pod uwagę, że obraz zapisany
w pliku może być obrócony, dlatego też trzeba najpierw przekształcić współrzędne (x,y) elementu na wyświetlanym obrazie na odpowiadające im położenie na
obrazie nieobróconym. Informacje na temat wykonanego przekształcenia zdjęcia
zawarte są w słowie kluczowym FLIP. Należy również policzyć odległość piksela
od środka obrazu. W przypadku zdjęcia pochodzącego bezpośrednio z teleskopu
projektu jest to oczywiste, ponieważ odejmujemy współrzędne danego piksela od
środka obrazu, obliczonego poprzez podzielenie jego wysokości oraz jego szerokości
na pół. Natomiast gdy mamy do czynienia z obrazem będącym wycinkiem, należy wyznaczyć odległość danego elementu fragmentu od środka obrazu z którego
47
pochodzi. Możliwe jest to dzięki danym mówiącym o szerokości i wysokości obrazu z którego pochodzi wycinek, zawartym w polach nagłówka ORGSIZEX oraz
ORGSIZEY. Do współrzędnych piksela wycinka należy dodać także wartości słów
kluczowych EVTX0 oraz EVTY0, tak aby przekształcić je na odpowiadające im
położenie na dużym obrazie.
Przedstawiona metoda obliczania współrzędnych niebieskich używana w eksperymencie π of the Sky została zaczerpnięta z projektu „ASAS”.
48
Podsumowanie
W pracy został przedstawiony sposób realizacji wymagań stawianych w eksperymencie π of the Sky przed przeglądarką plików FITS. Przedstawiona została również charakterystyka samego eksperyment wraz z opisem plików obrazujących wykonane obserwacje przez teleskop projektu oraz opisem formy ich przechowywania.
Dodatkowa prezentacja standardu FITS umożliwiła pełne zrozumienie wymagań
stawianych przed aplikacją.
Dzięki zastosowanej technologii możliwe było zintegrowanie aplikacji z istniejącym interfejsem WWW projektu. Dzięki czytaniu przez aplet parametrów znajdujących się w kodzie HTML, możliwe jest umieszczenie aplikacji domyślnie prezentującej zdjęcia zjawiska na dynamicznie generowanej stronie przeznaczonej do prezentacji zaobserwowanych zjawisk. Dzięki zaimplementowanej przeglądarce osoba,
chcąca obejrzeć zaobserwowane zjawisko, nie jest zmuszona do pobrania paczki
zawierającej listę opisującą zjawisko z witryny projektu oraz nie jest zmuszona
do wykonywania operacji związanych z dekompresją oraz dearchiwizacją pliku zawierającego paczkę. Nie jest również wymagana instalacja specjalnego oprogramowania umożliwiającego wyświetlenie obrazów zawartych w plikach FITS. Jedynym
warunkiem uruchomienia aplikacji jest posiadanie zainstalowanego środowiska uruchomieniowego Javy oraz wtyczki Java Plug-in.
Zaimplementowana aplikacja dostosowana jest do plików FITS używanych przez
projekt, dzięki czemu możliwe jest obliczenie współrzędnych niebieskich pikseli,
czego inne ogólnie dostępne przeglądarki, w przypadku przetwarzania plików pochodzących z teleskopu projektu, nie udostępniają. Dzięki określaniu położenia
elementów znajdujących się na obrazie zostało umożliwione pobieranie informacji
na temat gwiazd znajdujących się na wybranym fragmencie obrazu poprzez zdanie
zapytania do jednej z dwóch roboczych baz danych projektu.
Zostały w pełni zrealizowane wymagania dotyczące możliwości wykonywania
operacji graficznych na obrazie oraz jego przetwarzania w celu poprawy kontrastu
przy zachowanej możliwości odczytu wartości pikseli oryginalnego obrazu. Mimo
że wartości obrazu mogą być zmieniane przez wykonywanie różnych modyfikacji wyświetlanego obrazu, wskazywana wartość wybranego piksela jest wartością
opowiadającego mu piksela oryginalnego obrazu. Podczas wyświetlania każdego
49
zdjęcia wykonywana jest automatyczna metoda korekcji kontrastu, dająca dobre
rezultaty dla obrazów pochodzących bezpośrednio z teleskopu jak i dla obrazów będących ich wycinkami. Wynika to z faktu, że współczynniki zaimplementowanego
algorytmu poprawy jakości obrazu zostają wyznaczone na podstawie histogramu
aktualnie przetwarzanego obrazu. Istnieje również możliwość ręcznej poprawy kontrastu obrazu w przypadku gdy domyślna metoda okaże się niewystarczająca.
Aplikacja posiada okno nawigacji pozwalające na analizowanie i oglądanie zdjęć
wchodzących w skład wielu list i wielu paczek. Odpowiednie pogrupowanie elementów prezentujących przetwarzane obrazy pozwala na sprawną nawigację po
plikach. Dzięki możliwości wyboru list znajdujących się w paczkach, użytkownik
może otworzyć dowolny zbiór list wchodzących w skład paczki.
50
Bibliografia
[1] Marcin Sokołowski: Investigation of astrophysical phenomena in short time
scales with ”Pi of the Sky”. Phd thesis, Instytut Problemów Jądrowych
im. Andrzeja Sołtana, 2007.
http://grb.fuw.edu.pl/pi/user/msok/doc/phd/thesis.pdf.gz.
[2] Strona domowa pojektu π of the Sky. http://grb.fuw.edu.pl/pi/.
[3] Strona domowa pojektu ASAS. http://www.astrouw.edu.pl/asas/.
[4] Iwona Wytrzyszczak: Podstawy astronomii Układy współrzędnych niebieskich. http://www.nauticalissues.com/astronomy.html.
[5] Standard FITS.
http://fits.gsfc.nasa.gov/standard30/htmlfiles/fits standard30index.html.
[6] Java tutorial.
http://java.sun.com/docs/books/tutorial/deployment/applet/
security practical.html.
[7] Opis satelity Swift.
http://www.nasa.gov/mission pages/swift/spacecraft/index.html.
[8] Strona domowa sieci GCN. http://gcn.gsfc.nasa.gov/.
[9] Strona internetowa CGRO. http://heasarc.gsfc.nasa.gov/docs/cgro/.
[10] Strona internetowa Wikipedii. http://en.wikipedia.org/wiki/BeppoSAX.
[11] Strona internetowa Wikipedii. http://pl.wikipedia.org/wiki/Paralaksa.
[12] Strona internetowa Wikipedii. http://en.wikipedia.org/wiki/Angular size.
[13] Strona internetowa Wikipedii. http://pl.wikipedia.org/wiki/Erg (jednostka).
[14] Strona internetowa Wikipedii. http://pl.wikipedia.org/wiki/Magnitudo.
51