Skocz do zawartości

Sięgając do granic amatorskich obserwacji planet pozasłonecznych


LibMar

Rekomendowane odpowiedzi

(...)

 

Jest jeszcze opcja, aby materiał zbierać prosto na dysk zewnętrzny. Mój laptop ma dwa wejścia USB 3.0 (jeden dla kamery, drugi dla dysku). Wówczas dysk 2 TB pomieści już do 400 minut na 30 FPS, co powinno wystarczyć na całą sesję,

Zbyt optymistycznie ;)

 

Muniwin, do obrobki 100MB materialu potrzebuje ponad 200MB wolnego dysku. Przeca on robi kopie kazdej klatki, potem te kopie mapuje sobie do jakiegos wewnetrznego formatu i dopiero na niej robi wszystkie operacjie. A ma ich troche do zrobienia zanim w ogole zacznie fotometrie, ot chocby sama normalizacja to 3 niezalezne kroki. Sugeruje najwiekszy dysk SSD na jaki Cie stac Ja w zeszlym roku dopadlem 1T SSD za niecaly 1K pln. (Tak SSD, porownaj predkosc reakcji dysku SSD i zwyklego, fotometria to glownie mielenie dyskiem, to jego czasy sa kluczowe).

 

Pozdrawiam.

Odnośnik do komentarza
Udostępnij na innych stronach

To trochę na rynku się pozmieniało, bo już a 600 zł znajdziesz na Alledrogo markowe dyski po 4 TB ;) Dysk 2 TB Toshiby to jakieś 350 zł.

 

Oczywiście tutaj nie mówimy o pełnej fotometrii całym materiałem. Dysk zewnętrzny byłby do zbierania samych klatek. Przerzucamy część (np. 60s materiału) do Muniwina, pobieramy plik CSV po fotometrii, kasujemy projekt i lecimy do kolejnego fragmentu :) Ale ogólnie do takich działań używają m.in. LiMovie. Tam podobno nie ma problemu z rejestracji gwiazd, przy której Muniwin poległ na różnych ustawieniach. I daje radę mieląc tysiące klkatek. Przejrzę go dopiero, jak będę miał klatki, na których mogę cokolwiek mierzyć. Działanie trochę ryzykowne (możesz nie zdążyć z obróbką, a pogodny wieczór z kolejnym tranzytem się zbliża...), ale chyba warto ;)

Odnośnik do komentarza
Udostępnij na innych stronach

Dysk SSD jest jakieś 2.5x szybszy i odpowiada to 60MB/s i 150MB/s. Biorac pod uwagę, że minuta materiału na maksymalnej rozdzielczości zajmuje do 5 GB, to potrzebujemy 83MB/s. Mamy teraz różne opcje:
- Robimy ROI obszaru objętego ampglowem w jak najmniejszym stopniu (bo podczas obróbki i tak będziemy starali się pomijać)
- Nagrywamy w mniejszej ilości FPS (nie sądzę, że będziemy zawsze na 30 FPS nagrywać - słabsze cele to i dłuższe czasy)
- Zapisujemy na dysku D (SSD), a potem przenosimy po kawałkach materiał na dysk zewnętrzny. Miejsce zapisu klatek stanowi tak jakby buffering. Jeśli na dysku mamy np. 200GB wolnego miejsca i zdążymy przesłać 500GB materiału na zewnętrzny do momentu zapełnienia SSD, to łącznie mamy 700GB. Kolejne 200GB można dalej przesyłać po zakończeniu pracy. Jeśli to nie zadziała (przeciążenie komputera, w rzeczywistości będzie przesyłał kilka razy wolniej), to pozostwje opcja nr 1 i 2.

Powiem wprost - na taki dysk SSD mnie nie stać, więc od razu odpada :)

Odnośnik do komentarza
Udostępnij na innych stronach

Minuta materiału to kilka GB? omg ;) 160 MB / s....

Proponuję przedwstępne filtrowanie materiału, może nie potrzeba zawsze całej klatki (wyciąć rogi czy coś? :D)? Odpalenie zaraz po akwizycji prostego programiku "obcinającego" zdjęcie lub dokonującego jakiejś bezstratnej kompresji powinno dać się zrobić w locie. W końcu mówimy o sygnale bardzo słabo zmiennym w czasie. Przyda się oczywiście dużo RAMu i dobry algorytm :)

Odnośnik do komentarza
Udostępnij na innych stronach

bezstratnej kompresji... :) Jeszcze o takiej nie slyszalem. Ale powiedzmy ze jest takowa. Komp juz ma co robic ogarniajac obsluge kamery, kontrolujac mont a przewaznie i guider. Kompresja (jaka by nie byla) da do pieca procesorowi i pamieci. Nauczylem sie, ze najlepiej robic wrecz odwrotnie. Wylaczyc wszystko co niezbedne (wlacznie z internetem) i dac OSowi maximum dla kontroli aplikacji, a w samej aplikacji wylaczyc wszelkie zbedne wodotryski (jak chocby wyswietlanie klatek po sciagniecu o ile mamy pewnosc, ze wszystko jest ok). To oznacza oczywiscie nie tylko powstrzymanie sie przed "podgladaniem" ale rowniez embargo na zabawy np. w przenoszenie plikow czy fotometrie w locie.

 

Jakie optimum ja preferuje? Zgrac co trzeba jak schodzi bez dotykania sie. Jak sesja skonczona mozna (a nawet trzeba) pobawic sie w "masowa" kalibracje (zanim zaczniem cokolwiek ciac). Jak juz mamy wszystko mozna sie bawic w przygotowania do fotometrii (pakietowanie, przycinanki itd.) a potem dopiero fotometria.

 

:/ To oznacza, ze albo musimy miec duzo miejsca albo, ze wspieramy naszego PCta juz na etapie zbierania materialu. Ta druga opcja to na przyklad odpalanie jednej klatki co okres X a nie jednej za druga itd itp. Tego typu "pomaganie" trzeba oczywiscie robic z glowa, bo na przyklad wspomniana przed chwila praca w interwalach da nam degradacje wynikow (dla metody TTV to wrecz sabotaz) ... no generalnie trzeba wiedziec "na co sobie mozna pozwolic" i co dokladnie chcemy osiagnac.

 

MrOD, mowiac o RAIDzie miales na mysli jakies gotowe rozwiazanie sprzetowe czy radosna wolna amerykanke bezposrednio pod systemem operacyjnym?

 

Pozdrawiam.

Odnośnik do komentarza
Udostępnij na innych stronach

Zamiana ciągu 1111111111111111111111111111111111111111 na 40x1 jest bezstratną kompresją - właśnie skompresowałem 40 bajtów do 4, poziom kompresji = 90%

Zasadniczo jest mnóstwo algorytmów kompresji bezstratnej, polecam przeszukać internety :)

 

Notabene, choć to trochę inny kaliber: LHC też nie zgrywa wszystkiego jak leci, bo tam są terabajty na sekundę. Specjalne triggery odfiltrowują wydarzenia w locie i efektywnie zapisywany jest tylko ułamek "ciekawych" zdarzeń.

 

Osobiście uważam, że osobny sprzęt, najlepiej dedykowany, powinien zajmować się tylko i wyłącznie akwizycją z kamery plus ewentualnie pre-processing, a osobny, klasy pecet- wszystkim innym.

To, o czym mówisz, Hansie, jako optimum, to dla mnie minimum :)

Są dwie skrajności: robić wszystko w locie (nie da rady, za mało mocy/pamięci) albo robić wszystko po akwizycji (nie ma mowy: za mało dysku).

Optimum to własnie to, o czym mówię: kilka niezbędnych rzeczy dołożyć in-flight żeby zminimalizować zużycie storage'u, a resztą zająć się na spokojnie bez inwestowania w 10TB dyski SSD.

 

Nie chce mi się zresztą wierzyć, żeby guiding czy sterowanie montażem to były jakieś pamięciożerne kolosy, chyba że są kiepsko napisane. Może pora przerzucić się na Linuxa?

Wydaje mi się, że maszynka która ogarnie wszystko (oprócz akwizycji) powinna kosztować jakieś 300-400zł, bo tyle kosztują używane laptopy.

  • Lubię 2
Odnośnik do komentarza
Udostępnij na innych stronach

Minuta materiału to kilka GB? omg ;) 160 MB / s....

Proponuję przedwstępne filtrowanie materiału, może nie potrzeba zawsze całej klatki (wyciąć rogi czy coś? :D)? Odpalenie zaraz po akwizycji prostego programiku "obcinającego" zdjęcie lub dokonującego jakiejś bezstratnej kompresji powinno dać się zrobić w locie. W końcu mówimy o sygnale bardzo słabo zmiennym w czasie. Przyda się oczywiście dużo RAMu i dobry algorytm :)

 

Obcinaniem w zasadzie zajmuje się samo ROI, więc obcięcie mamy na poziomie nagrywania.

 

Przejrzałem dotychczasowe pliki i obawiam się, że może wyjść tego nawet trochę więcej niż 5 GB. Materiał w 12-bit składający się z 500 klatek (po 650ms naświetlania) o rozdzielczości 1280x960 pikseli waży dokładnie 1 200 000 KB (1.17 GB) zapisany w formacie SER. Jeśli mielibyśmy nagrywać w 14-bit na 30 FPS w maksymalnej rozdzielczości (3096x2080 pikseli), plik powinien ważyć:

- 4x więcej, bo 14-bit przechowuje 4x więcej informacji niż 12-bit

- 3.6x więcej, bo w minucie mamy 1800 klatek

- 5.24x więcej, bo mamy tyle samo większe pole powierzchni na jednej klatce

- 4x mniej, bo nagrywamy w formacie mono (Altair GPCAMV2 IMX224 pozwala w 12-bit nagrywać tylko w kolorze, wersja b/w możliwa tylko w 8-bit)

Po wymnożeniu wszystkiego, wychodzi nam wynik 22GB na minutę, co wydaje się bardzo nierealne! :D

 

Jak tylko zmniejszymy rozdzielczość do 1280x960 (tyle powinno wystarczyć), to już mamy 5.24x mniej, czyli około 4.2 GB/min (70MB/s). Wówczas można rozważyć, aby nagrywać w 25 FPS - to wszystko sprawdzimy w praktyce za kilka miesięcy.

 

Komputerowcem nie jestem i zdaje mi się, że RAM to nie wszystko. U mnie 12GB RAMu i 8-rdzeniowy procesor powinny poradzić sobie, choć komputer wymaga dobrego czyszczenia. Na pewno format będzie wkrótce potrzebny.

 

bezstratnej kompresji... :) Jeszcze o takiej nie slyszalem. Ale powiedzmy ze jest takowa. Komp juz ma co robic ogarniajac obsluge kamery, kontrolujac mont a przewaznie i guider. Kompresja (jaka by nie byla) da do pieca procesorowi i pamieci. Nauczylem sie, ze najlepiej robic wrecz odwrotnie. Wylaczyc wszystko co niezbedne (wlacznie z internetem) i dac OSowi maximum dla kontroli aplikacji, a w samej aplikacji wylaczyc wszelkie zbedne wodotryski (jak chocby wyswietlanie klatek po sciagniecu o ile mamy pewnosc, ze wszystko jest ok). To oznacza oczywiscie nie tylko powstrzymanie sie przed "podgladaniem" ale rowniez embargo na zabawy np. w przenoszenie plikow czy fotometrie w locie.

 

Jakie optimum ja preferuje? Zgrac co trzeba jak schodzi bez dotykania sie. Jak sesja skonczona mozna (a nawet trzeba) pobawic sie w "masowa" kalibracje (zanim zaczniem cokolwiek ciac). Jak juz mamy wszystko mozna sie bawic w przygotowania do fotometrii (pakietowanie, przycinanki itd.) a potem dopiero fotometria.

 

:/ To oznacza, ze albo musimy miec duzo miejsca albo, ze wspieramy naszego PCta juz na etapie zbierania materialu. Ta druga opcja to na przyklad odpalanie jednej klatki co okres X a nie jednej za druga itd itp. Tego typu "pomaganie" trzeba oczywiscie robic z glowa, bo na przyklad wspomniana przed chwila praca w interwalach da nam degradacje wynikow (dla metody TTV to wrecz sabotaz) ... no generalnie trzeba wiedziec "na co sobie mozna pozwolic" i co dokladnie chcemy osiagnac.

 

MrOD, mowiac o RAIDzie miales na mysli jakies gotowe rozwiazanie sprzetowe czy radosna wolna amerykanke bezposrednio pod systemem operacyjnym?

 

Pozdrawiam.

 

Wojtek (Burza) podczas prób z zakryciem gwiazdy przez Plutona zasugerował, abym nagrywał w AVI - ważą trochę mniej i nie powodują ingerencji w dane wartości ADU. Wierzę mu na słowo :)

 

Kolejność byłaby takowa:

- Robimy klatki z gwiazdami

- Robimy klatki kalibracyjne (na początek do testów warto wypróbować każdą opcję, czyli wpływ darków, flatów i biasów)

- LiMovie przeprowadza fotometrię dla każdej klatki (1/30s) wraz z uwzględnieniem tych kalibracyjnych. Uzyskujemy plik CSV z 1800 obserwacjami w ciągu 60 sekund (jeśli nagrywamy i wrzucamy w fragmentach 60-sekundowych)

 

Wspominałeś o przygotowaniu materiału przed przeprowadzeniem fotometrii. Moja idea jest taka:

1) Przycinanie - robimy to już na poziomie nagrywania, tylko kwestia ile zajmuje na dysku.

2) Pakietowanie - jeśli mamy pojedyncze pomiary, możemy dowolnie uśredniać z Excela (co tyle sąsiednich klatek, z takim odrzutem itp). Jeśli mamy pojedynczy plik (stack) załóżmy po 10 klatek, to już z góry założyliśmy, że wszystkie wybrane klatki są ok i niech wyjdzie co ma wyjść. 10-klatkowy stack w DSS (bo nie mam innego pomysłu na zapakietowanie) medianą da taki sam wynik, co w Excelu po uśrednieniu 10 pomiarów tą samą metodą. Czyli w tym przypadku fotometria przed pakietowaniem miałaby dać taki sam wynik, jednak w Excelu możesz spokojnie zmienić np. z 10 na 5 sąsiednich pomiarów.

Pakietowanie składałoby się zresztą z dwóch etapów - najpierw w X-sekundowe oceny (np. przedział 30s z klatek po 1/30s),a dopiero potem kolejne uśrednianie 30s ocen. Jeśli miałbyś zrobić na odwrót (najpierw pakietowanie, potem fotometria) dla 29 sąsiednich pomiarów (jak HD 189733 b u mnie i Scotta Degenhardta), musiałbyś zrobić stacki dla klatek o numerach: 1-26100, 900-27000, 1800-27900, 2700-28800 itd. i dopiero na nich przeprowadzać fotometrię. Niestety, nie wydaje mi się to realne - nie słyszałem, aby ktoś próbował stackować powyżej 8 tysięcy klatek naraz :) Jeszcze zapomniałem dodać - gdybyś najpierw pakietował, to nie mógłbyś wyciąć te klatki, które nie należą do grupy "lucky imaging" i powodują zakłamania.

3) Fotometria - jeśli materiał ma 90 tysięcy klatek i podzielilibyśmy na 30-sekundowe fragmenty (900 klatek na 30 FPS), to uzyskamy 100 pomiarów. Czyli tak - wklejamy wszystko do arkusza (tak, 90 tysięcy linijek) i każemy mu wykonać uśrednienie daną metodą (np. zwykłe =(B1:B900)/900, potem =(B901:B1800)/900 i tak dalej*). Można tutaj wykonać dwa odrzuty - najgorsze % klatek pod względem wyznaczonej jasności (np. ocena -0,23920, podczas gdy wszystkie trzymają się między -0.05 a -0.15), albo pod względem błędu (klatki "lucky imaging" mają najmniejszy błąd wyznaczony przez program). Zostają wtedy pojedyncze oceny składające się np z 810 klatek (zamiast 900, po usunięciu 10%) i takie lecą do wykresu. Są one traktowane jak pojedyncze pomiary, które zawsze robiliśmy.

A zanim to zaczniemy robić, najpierw trzeba wyznaczyć przy jakim odrzucie oceny będą najdokładniejsze. Jeśli od razu wrzucimy 90000 ocen do liczenia, to przy każdym ruchu Excel zatrzyma się na minutę, aby wszystko jeszcze raz przeliczyć :D Czyli w takim przypadku pierwsze 13500 (15 ocen) do określenia rozrzutu powinno starczyć.

Przy okazji, w ten sam sposób możemy wrzucić w Excel jakąś funkcję, aby brała co którąś klatkę do oceny. Możliwości jest dużo. Na poziomie pakietowania przed fotometrią tego nie zrobisz. A na pewno nie na komputerach w 2016 roku, aby w krótkim czasie przelecieć jeszcze raz dziesiątki (a nawet setki) tysięcy klatek tylko po to, aby z ciekawości zobaczyć jak będzie wyglądał wykres po odrzucie nie 7% klatek, ale 9%. Takie pojedyncze kroki będą kosztowały Cię nie mniej niż kilkadziesiąt minut życia :D

 

* - tak, prawidłowo powinienem uwzględnić to logarytmicznie, to tylko przykład

Odnośnik do komentarza
Udostępnij na innych stronach

:blink:

 

Ja chyba jednak chce zobaczyc jak to robisz w realu. Jakos do mnie opis nie przemawia, W jakich rejonach mozna by cie lapac razem z kompem do fotometrii? Odezwij sie jak bedziesz mial kamere w reku i planowal sesje, moze udalo by mi sie jakos na tele-conf wlogowac.

 

A co do ocji optimum i minimum. Gdzies na forum sa watki z mojej rejestracji sprzed kilku lat zrobionej na dziko. Odlaczylem guider, ostrosc ustawilem manualnie, o ile pamietam robilem jedna klatke na minute (Atik 314L), a niebo bylo takie sobie... Zero darkow, zero flatow, zero biasow, stemple czasowe z kompa korygowane (i to byla cala kalibracja). Oczywiscie podglad klatki po zczytaniu w trakcie sesji itd, generalnie beztroska na calego. i wiecie co? Cakiem fajnie bylo widac egzotranzyt. Owszem nie byl idealny, ale chlopakom z ETD sie nadal ;)

 

Pozdrawiam.

Odnośnik do komentarza
Udostępnij na innych stronach

Kamerkę będę miał najwcześniej późną wiosną, a dopiero od początku lipca (po sesji) znajdzie się czas, aby tym się zająć. Przez całe lato siedzę w Suwałkach. Resztę czasu przesiaduję w Białymstoku i sprzętu ze sobą nie zabieram. Aktualnie przy sobie trzymam tylko lustrzankę czekając na kolejne zakrycie związane z Linus. Jak jest pogoda, to kontaktuję się z kolegami PTMA Białystok i coś planujemy.

 

Myślę, że największe szanse byłyby na jesiennym zlocie 2017. Postaram się być i w tym roku więc też liczę na obecność :D

 

Pamiętaj, że metoda jest niesprawdzona, bo:

- Nie słyszałem, aby ktoś podejmował się fotometrii z nowoczesnej kamery planetarnej (CMOS)

- Nikt z amatorów nie stosuje tej metody (Scott Degenhard to wyjątek, ale sam ma tylko jedną ocenę w ETD - reszta na stronie jego projektu pod kątem JEE)

- Tym bardziej nikt nie myślał o fotometrii z samym "lucky imaging"

- Próby z "lucky imaging" znam tylko z prac/artykułów w Internecie, ja tylko pobierałem najciekawsze elementy i dołączam do powyższego opisu, aby złożyło się w logiczną całość (czyli jak to robili)

- Nie próbowałem jeszcze tego robić samodzielnie, bo nie mam nawet na czym (brak kamery/materiału)

- Nigdy jeszcze nie odpalałem LiMovie i nie mam pewności czy program umożliwia wrzucić jednocześnie klatki kalibracyjne

- Mam tylko astrograf 800mm f/4, który prawdopodobnie zredukuję do 750mm f/5 (uciążliwa kolimacja) - średnicą nie zachwyca w stosunku do tych z projektów (tam korzystali z luster powyżej 50cm średnicy) - stąd głębiej niż 9-10 mag nie zejdziemy, ale wciąż mamy przynajmniej kilkanaście dostępnych egzoplanet

 

Jak wszystko uda się ogarnąć, to może dopiero wtedy coś wyjdzie ciekawego. Trzeba podejść bardziej technicznie, bo jak coś nie uda się, to wszystko robimy od nowa (kilkanaście godzin straconych). Ta typowa metoda jest bardzo prosta - mało miejsca zajmuje, jest sprawdzona i można zrobić to w pół godziny ;)

 

Mi zlecono zadanie, aby to sprawdzić i przetestować - zobaczymy i przeżyjemy. Dopiero porównując wynik z 90000x0.03s i 100x30s uzyskamy odpowiednie wnioski.

  • Lubię 2
Odnośnik do komentarza
Udostępnij na innych stronach

Kolejna rzecz, to uśrednianie pomiarów. W programie Excel przygotowałem prostą formułkę pozwalającą na wizualizację krzywej jasności znając rozrzut. Dla przykładu, Canonem EOS 60D osiągnąłem +/- 0.02 mag podczas ostatniej obserwacji HD 189733 b. Jak taka dokładność przekłada się na inne obiekty egzoplanetarne?

 

Tym razem celem jest HD 97658 b, planeta należąca do grupy superziemi. Spadek jasności wynosi 0.0022 mag, a rozrzut jest niemal dwudziestokrotnie większy niż amplituda...

 

Ok, najpierw nieco o rozrzucie pomiarowym - jak Excel to generuje. Wykonałem ją na podstawie czterech kolumn:

1) Rzeczywista krzywa jasności

2) Wartość pojedynczego pomiaru do krzywej jasności

3) Współczynnik rozrzutu pomiarów

4) Współczynnik rozrzutu pomiarów (fix)

 

Nieco więcej:

1) Czyli trochę na oko podaję jaką jasność ma gwiazda w danej chwili (1 wiersz odpowiada 30 sekundom). Spadek jasności to wspomniane 0.0022 magnitudo.

2) Funkcja wygląda następująco:

=$A1+(LOS()*(K$2/3*$D1))

$A1 to wartość rzeczywista, a reszta ma zapewnić nam realną niedokładność pomiarową. LOS() losuje nam liczbę między 0 a 1 (wartości po przecinku, np. 0,439834). K$2 to określona niedokładność pomiarowa - w komórce K2 wpisujemy, jaki mamy rozrzut pomiarowy. Do tego testu wpisałem 0.04, co ma odpowiadać +/- 0.02 mag. Tę wartość dzielimy przez trzy, aby następnie znów wymnożyć... przez 1, 2 lub 3.

3) Dlaczego wymnożyć? I czemu nie możemy zostawić samo K$2? Ponieważ oceny muszą być najbardziej skupione w pobliżu właściwej krzywej jasności. Bez tego wszystkie pomiary będą miały charakterystyczny (regularny) charakter. Stąd, w kolumnie trzeciej Excel losuje cyfrę między -3 a 3. Jest 7 możliwości.

 

Jeśli:

3) Wynik wyjdzie +0.04

2) =/= 0.02667

1) =/= 0.01333

0) zero (patrz punkt czwarty)

-1) Wynik wyjdzie -0.01333

-2) =/= 0.02667

-3) =/= -0.04

 

Tylko w 2/7 przypadkach rozrzut może osiągnąć powyżej +/- 0.01333 mag, a w 4/7 osiągać może powyżej +/- 0.006667 mag. To powoduje, że w większości pomiary będą skupione ku krzywej realnej. Dlaczego dałem wartość 3? Ona jest najbliżej wartości rzeczywistej. Gdy dałem 4, wyraźne już było skupienie do właściwej wartości (nierealne - takiego w Muniwinie nigdy nie miałem). Gdy dałem 2, wyglądało już jak zbyt rozrzedzone.

 

4) Jeśli wynik wynosi 0, to mnożenie da zero, więc cokolwiek nam LOS() wylosuje, i tak doda zero do właściwej wartości. W takim przypadku dałem rozrzut +/- 0.00333, gdyż Excel losuje liczbę między -0.5 a 0.5. Szansa wynosi tylko 1/7, że akurat wylosuje zero.

 

Istotne: po jakiejkolwiek zmianie w komórkach, funkcja LOS generuje nową krzywą - wszystkie są tylko orientacyjne i będą się różnić pojedynczymi ocenami.

 

Kiedy już wyjaśniłem jak to działa, przejdźmy do konkretu. Jaki sens ma uśrednianie sąsiednich pomiarów? Przygotowałem w tym celu kilka krzywych jasności:

 

Krzywa_Start.png

 

Niebieskie punkty to pojedyncze pomiary. Na czerwono - linia rzeczywista. Na zielono - uśrednione pomiary. Warto zauważyć, że to jest egzoplaneta, która znajdować się może najwyżej na granicy możliwości sprzętu - nie ma szans, żeby jeszcze określić dokładnie moment początku i końca. A gdyby tak uśrednić nie 29, ale 49 (lub nawet 99 pomiarów)? Porównać takie ze środka tranzytu i momentu, gdy przejścia planety na tle tarczy gwiazdy jeszcze nie było? Mam nadzieję, że poniższe wykresy pozwolą odpowiedzieć na to pytanie:

 

5 pomiarów:

 

5 pomiarów.png

 

11 pomiarów:

 

11 pomiarów.png

 

19 pomiarów:

 

19 pomiarów.png

 

29 pomiarów:

 

29 pomiarów.png

 

39 pomiarów:

 

39 pomiarów.png

 

49 pomiarów:

 

49 pomiarów.png

 

69 pomiarów:

 

69 pomiarów.png

 

99 pomiarów:

 

99 pomiarów.png

 

Konkluzja: Wiadomo, że im więcej mierzymy, tym gorzej dla krzywej - przecież 99 pomiarów odpowiada aż 50 minutom materiału! Dlatego uważam, że przy publikacji krzywych jasności z tranzytów, warto będzie pokazywać animację. Taka, która będzie pokazywała coraz to inną krzywą jasności - najpierw 3, potem 5, 7, 9 itd. Tym samym można powiedzieć, że detekcja superziemi lustrzanką... no jeszcze nie stanowiłaby potwierdzenia obserwacji. Przy takim rozrzucie ocen, przyznałbym tylko status "prawdopodobny".

 

Warto jeszcze wspomnieć, że w przypadku HD 189733 b żaden pomiar (z wyjątkiem końca, ale mówiłem - nadchodzące chmury) nie przekraczał rozrzutu +/- 0.0025 mag po uśrednieniu. Tutaj Excel potrafił już wylecieć poza +/- 0.0050 mag.

Odnośnik do komentarza
Udostępnij na innych stronach

Rozumiem, że te niebieskie kropeczki to symulacja.

Ale co znaczy "im więcej mierzymy, tym gorzej dla krzywej". Zielona, gruba linia na ostatnim obrazku (pod opisem 99) bardzo mi się podoba - jako "sygnał" tranzytu tak na intuicję.

Pozdrawiam

Odnośnik do komentarza
Udostępnij na innych stronach

Rozumiem, że te niebieskie kropeczki to symulacja.

Ale co znaczy "im więcej mierzymy, tym gorzej dla krzywej". Zielona, gruba linia na ostatnim obrazku (pod opisem 99) bardzo mi się podoba - jako "sygnał" tranzytu tak na intuicję.

Pozdrawiam

 

Momenty początku i końca tranzytu są bardzo dynamiczne, więc jak uśrednimy 99 pomiarów przy super dokładności (+/- 0.0005 mag na pojedynczych klatkach), uzyskamy coś jak niżej. Takie uśrednianie trzeba robić z głową. Więc jak z +/- 0.02 mag zjedziemy na +/- 0.001 mag, to nie ma co od razu wiązać to z naukowymi obserwacjami. W takich przypadkach mówimy tylko "jest" albo "nie ma" :)

 

0.005mag.png

Odnośnik do komentarza
Udostępnij na innych stronach

Libmar,

 

Zaglądne w to jak dolece (musze sie rano zerwac, a potem cały dzien zmarnowany na transfer do PL). Ale na juz moge powiedziec jedno. Majac takiej jakosci materiał jak na wykresach ktore wstawiles, pewnie bym nawet nie probowal tego obrabiac. Zobacz jakiej jakosci material zbieralem Atikiem:

 

http://astropolis.pl/topic/26629-tres-3b-full-transit/

 

Pozdrawiam.

Odnośnik do komentarza
Udostępnij na innych stronach

Czy ja wiem... +/- 0.02 mag miałem w materiale mającym po 30 sekund. Nie wiem jakie użyłeś czasy ekspozycji do TrES-3b, ale patrząc po ilości ocen w trakcie tranzytu, musiały być to 3 minuty (około 26 ocen i 77 minut... dzieląc pasuje na 3). Tak więc, mógłbym sobie uśrednić/zsumować po 6 klatek z Canona. Wyszłoby coś w stylu wykresu z 5 sąsiednimi pomiarami jak wyżej (oczywiście robimy 1-6, 7-12, 13-18 itd). W takim przypadku rozrzut wynosiłby już około +/- 0.01 mag. Niemal dorównuję Twojej dokładności (0.007-0.009).

Odnośnik do komentarza
Udostępnij na innych stronach

Jeśli mielibyśmy nagrywać w 14-bit na 30 FPS w maksymalnej rozdzielczości (3096x2080 pikseli), plik powinien ważyć:

- 4x więcej, bo 14-bit przechowuje 4x więcej informacji niż 12-bit

 

Zapędziłeś się :)

 

Zmienna 14-bitowa może reprezentować liczbę 4 razy większą niż zmienna 12-bitowa. Ale informacji przechowuje (i miejsca w pamięci zajmuje) 14/12 ≈ o 17% więcej. W praktyce wiele programów zapisuje pewnie 12- i 14-bitowe wartości na 16 bitach z wygody.

 

Też uważam, że najwygodniej byłoby wycinać z kadru np. kwadraciki wokół kilku(dziesięciu?) wybranych gwiazd w polu i tylko je zapisywać. Rzecz jest do zrobienia, mamy w końcu otwarte narzędzia do przechwytywania wideo (np. oaCapture, GuLinux Planetary Imager), można by się dopisać. Albo stworzyć plugin dla FireCapture (acz nie wiem, na ile pluginy mogą sobie pozwolić).

  • Lubię 3
Odnośnik do komentarza
Udostępnij na innych stronach

O, dobrze wiedzieć. W takim przypadku nie powinno być już problemów z zapisem nawet przy pełnej rozdzielczości, więc nie ma strachu z dyskiem HDD.

 

Popatrzę jeszcze te programy. Będzie tylko w tym mały problem, gdyż w aktualnej chwili nie mam możliwości skorzystania z guidingu. Gwiazdy będą zjeżdżały się i wymagały poprawki kadru co jakiś czas (30 minut) z różnych powodów? Przez ten czas gwiazdki mogą wylecieć poza kadr. Na zlocie zauważyłem coś niedobrego z moim EQ5, a dokładnie zjeżdżanie w osi rektascensji (deklinacja jest ok). Zachował się, jakby potrzebował nie 23h 56m na jeden pełny obrót, ale np. 23h 54m. Czyli z delikatnym przyspieszeniem. 120s z 200mm to dla niego średni wynik, więc na chwilę obecną (2017) może jeszcze nie sprawdzić się. Ciągłe poprawianie to też przerwy w zbieraniu materiału :)

 

EDIT: Jeszcze taka analiza z poprzednią krzywą jasności. Dając rozrzut +/- 0.01 mag (mój wcześniejszy to +/- 0.02 mag), Excel przygotował mi 50 krzywych jasności dla tej egzoplanety (spadek 0.0022 mag). Po uśrednieniu do 29 pomiarów (takie już OK, aby do czegoś się przydało), wynik jest następujący:

- Tranzyt wyraźnie się złapał: 15/50 (30%)

- Prawdopodobnie złapał się tranzyt: 20/50 (40%)

- Nie widać, aby złapał się tranzyt: 15/50 (30%)

Daje to szanse 70%, że będzie choć częściowy sukces. Dla rozrzutu +/- 0.02 mag już tak pięknie nie będzie :) W ten sposób można wyznaczyć jakąś matematyczną granicę, od której można zaliczyć do poszczególnych grup.

Odnośnik do komentarza
Udostępnij na innych stronach

http://www.100fps.com/file_sizes_of_lossless_compression.htm

Porównanie bezstratnych kompresji wideo.

HuffyUV jest na tyle szybki, że na 416MHz single core procesorze Celeron ma throughput ok. 38MB/s. (za angielską wiki).

http://www.animemusicvideos.org/guides/avtechbeta/video4.htm

Dodatkowy plus dla klona HuffyUV z obsługą multicore procesorów.

Pewnie wymagałoby to tak czy siak osobnej maszyny do akwizycji i osobnej do sterowania montażem... Ale na pewno zmniejszyłoby zmartwienia związane z miejscem na dysku.

Może będę miał jeszcze dziś czas to sprawdzę co się stanie, jak zawinę część moich zdjęć tym algorytmem - jak długo trwa kompresja i ile waży wynikowy plik.

Pozdrawiam!

  • Lubię 1
Odnośnik do komentarza
Udostępnij na innych stronach

Zrobiłem kolejny wykres, który może się przydać. Określa on prawdopodobieństwo zarejestrowania tranzytu egzoplanety danym zestawem. Wszystko zrobiłem na podstawie tego generatora/wizualizatora. Zliczałem ilość krzywych na których coś widać,

 

Na niebiesko - tranzyt bardzo dobrze się zarejestrował, wyraźny charakterystyczny kształt. Na takim materiale można próbować określać z dość dobrą (lub lepszą) precyzją momenty tranzytu itp.

Na zielono - tranzyt zarejestrował się, wynik pozytywny. Ciężko jednak z tego materiału wyciągnąć odpowiednie dane, choć da się wyznaczyć początek i koniec tranzytu.

Na żółto - nie można jednoznacznie stwierdzić, czy "dołek" na krzywej wynika z wystąpienia tranzytu, albo stanowi artefakt.

Na czerwono - tranzyt nie zarejestrował się, brak oznak widocznego spadku.

 

Jak to określić - potrzebne są cztery dane:

A) Długość trwania tranzytu (w minutach)

B) Czas ekspozycji (w minutach)

C) Spadek jasności (mag)

D) Rozrzut pomiarowy (mag)

 

I wyznaczamy wynik z następującego wzoru:

 

X = (A/B) * (C/D)

 

Dla przykładu z HD 97658 b. Tranzyt trwa 200 minut (A), natomiast czas ekspozycji użyłbym 30s (B) (gwiazda jest 0.1 mag słabsza od HD 189733, więc potrzebuję tylko niewiele dłuższy). Spadek jasności wynosi 0.0022 mag ©, a rozrzut pomiarowy około +/- 0.02 mag (D). Będzie on podobny jak z HD 189733 b, ponieważ praktycznie różni się jedynie czasem ekspozycji - tym samym może być nawet ciut mniejszy. Po podstawieniu do wzoru, uzyskałem wynik 44. Na poniższym wykresie na osi Y znajdujemy "44" i na podstawie kolorów określić można prawdopodobieństwo:

1) 50%, że nie uda się

2) 25%, że coś majaczy, ale nie do końca wiadomo

3) 25%, że uda się

 

No i widać, że mamy tylko 25% szans pozytywnej obserwacji. Na początku może wydawać się bez sensu (przecież przy danym rozrzucie i takiej ilości ocen, każdy tranzyt powinien tak samo wyglądać). Ale jednak za każdym razem mamy nieco inne warunki (np. seeing). A "stackując krzywe jasności" z kiepsko wyznaczonych tranzytów (na żółto) może później przedstawić coś sensownego.

 

Prawdopodobieństwo.png

  • Lubię 2
Odnośnik do komentarza
Udostępnij na innych stronach

A możesz to zobrazować nam jedną lub kilkoma zaledwie liczbami?

Jeśli tranzyt trafił tu na zielone to jakie jest prawdopodobieństwo, że naprawdę trafił. Coś mi się przypomina, że bywa uważane za cenne 95%.

Jakie będzie (przy powyżej opisanym "zielonym" trafieniu) średnie odsunięcie wyznaczonego momentu środka tranzytu od rzeczywistego gdzie za 100% uznamy czas trwania .

Rozumiem, że wartość 50% to by była katastrofa (zetknięcie uzane za środek).

 

Te Twoje symulacje generowane losowo gdyby wykonać je bardzo licznie np bilion razy mogą moim zdaniem dać po zliczeniu całkiem niezłe oszacowania.

Oczywiście weryfikatorzy bedą się pytać o założenia optyczno-geometryczne. Czy tak samo to wyglada gdy planeta ledwo muska gwiazdę (krótki tranzyt tuż przy krawędzi).

 

Czy marzysz skrycie o tym, że jak przeświczysz jakiś zestaw na znanych tranzytach to zaczaisz się na jakąś gwiazdę i spróbujesz dokonać odkrycia?

I jak wtedy coś wyda ci się tranzytem to ... poczekasz bez rozgłosu kilka dni/tygodni/miesięcy/lat na ponowny?

 

Jak to jest - czy krótki czas tranzytu jest wtedy gdy planeta blisko krąży od gwiazdy (ma krótki rok) a dłuższy gdy daleko?

 

Tak zgaduję z wyprowadzonej kiedyś przeze mnie "reguły ekologa" ;)

Każda planeta w kosmosie cztery razy dalej od gwiazdy (niż inna) pędzi po orbicie dwa razy wolniej i ma osiem razy dłuższy rok.

http://astropolis.pl/topic/36543-zagadki-pytania-i-pomysy-na-temat-kosmosu/page-2?do=findComment&comment=473432

 

ale może się mylę?

 

Pozdrawiam

 

 

Edytowane przez ekolog
Odnośnik do komentarza
Udostępnij na innych stronach

A możesz to zobrazować nam jedną lub kilkoma zaledwie liczbami?

Jeśli tranzyt trafił tu na zielone to jakie jest prawdopodobieństwo, że naprawdę trafił. Coś mi się przypomina, że bywa uważane za cenne 95%.

Jakie będzie (przy powyżej opisanym "zielonym" trafieniu) średnie odsunięcie wyznaczonego momentu środka tranzytu od rzeczywistego gdzie za 100% uznamy czas trwania .

Rozumiem, że wartość 50% to by była katastrofa (zetknięcie uzane za środek).

 

Tak naprawdę, to jest subiektywna ocena. Jeśli początek i koniec mniej więcej pokrywają się z wartościami rzeczywistymi, to można uznać za sukces. Niekiedy niestety jest to maskowane przez pagórki (zobacz niżej trzecią krzywą), co uniemożliwia potwierdzenie uchwycenia tranzytu.

 

Poniżej podam przykłady tranzytów - ocena 1 (niebieski), 2 (zielony), 3 (żółty) i 4 (czerwony). Spadek jasności ten sam, czyli 0.0022 mag.

 

Ocena_1.png

 

Ocena_2.png

 

Ocena_3.png

 

Ocena_4.png

 

Te Twoje symulacje generowane losowo gdyby wykonać je bardzo licznie np bilion razy mogą moim zdaniem dać po zliczeniu całkiem niezłe oszacowania.

Oczywiście weryfikatorzy bedą się pytać o założenia optyczno-geometryczne. Czy tak samo to wyglada gdy planeta ledwo muska gwiazdę (krótki tranzyt tuż przy krawędzi).

 

Pomiar przy danej dokładności został wykonany 50 razy, więc potem na wykresie jakoś to się uśredniało. I niestety, powyższy diagram nie można powiązać do rejestracji w niektórych przypadkach:

- Brzegowy tranzyt, lub niedaleko brzegu (np. TrES-3 b - w takim przypadku zamiast 80 minut tranzytu, należałoby ustawić na jakieś 65 min)

- Masywna planeta, gdyż dość długo wchodzi i wychodzi. Długość trwania zjawiska należałoby skrócić przynajmniej o kilka procent.

Stąd diagram najlepiej pasuje do mniejszych planet, np. superziemie czy gorące Neptuny.

 

Czy marzysz skrycie o tym, że jak przeświczysz jakiś zestaw na znanych tranzytach to zaczaisz się na jakąś gwiazdę i spróbujesz dokonać odkrycia?

I jak wtedy coś wyda ci się tranzytem to ... poczekasz bez rozgłosu kilka dni/tygodni/miesięcy/lat na ponowny?

 

Uważam, że w tym momencie możliwa jest jeszcze amatorska detekcja tranzytu egzoplanety, jednak większość dostępnych już poodkrywano. W takim przypadku musiałbym od razu wskoczyć na NEQ6 i 8", przygotować plan obserwacyjny

 

Z kolei widzę (i Hans również), że duże pole do popisu ma metoda TTV. A szczególnie na planetach o dużym okresie obiegu (> 10 dni), gdyż są stosunkowo rzadko obserwowane. To z kolei powoduje, że wykresy O-C są całkiem niedokładne. Raczej ciężko tutaj coś odkryć samodzielnie, ale w grupach (z różnych zakątków świata) szanse wzrastają

 

Jak to jest - czy krótki czas tranzytu jest wtedy gdy planeta blisko krąży od gwiazdy (ma krótki rok) a dłuższy gdy daleko?

 

Zobacz sobie tę stronkę, posuwaj paseczkami i zobaczysz od czego zależy czas tranzytu :)

http://astro.unl.edu/naap/esp/animations/transitSimulator.html

 

Duże znaczenie mają:

- odległość od gwiazdy

- inklinacja orbity

- promień gwiazdy

- ekscentryczność i argument perycentrum*

 

Małe znaczenie mają:

- promień planety

 

* - tylko w przypadku niektórych planet, gdyż u większości mimośród jest blisko 0.

  • Lubię 1
Odnośnik do komentarza
Udostępnij na innych stronach

Dołącz do dyskusji

Możesz dodać zawartość już teraz a zarejestrować się później. Jeśli posiadasz już konto, zaloguj się aby dodać zawartość za jego pomocą.

Gość
Dodaj odpowiedź do tematu...

×   Wklejono zawartość z formatowaniem.   Usuń formatowanie

  Dozwolonych jest tylko 75 emoji.

×   Odnośnik został automatycznie osadzony.   Przywróć wyświetlanie jako odnośnik

×   Przywrócono poprzednią zawartość.   Wyczyść edytor

×   Nie możesz bezpośrednio wkleić grafiki. Dodaj lub załącz grafiki z adresu URL.

×
×
  • Dodaj nową pozycję...

Powiadomienie o plikach cookie

Umieściliśmy na Twoim urządzeniu pliki cookie, aby pomóc Ci usprawnić przeglądanie strony. Możesz dostosować ustawienia plików cookie, w przeciwnym wypadku zakładamy, że wyrażasz na to zgodę.