Skocz do zawartości

Live binning - rewolucja w amatorskiej rejestracji tranzytów egzoplanet?


LibMar

Rekomendowane odpowiedzi

Hm... wygląda - niestety - na dość optymalny proces, tj. - mało można to usprawnić:) Ew. zmiana lokalizacji Excela na taką, gdzie kropka to przecinek :) Spacje na taby mogą być niepotrzebne jeśli w Excelu będziesz miał odpowiednią funkcję tekstową. Ale to mikrooptymalizacje. Ciekawe, czy Muniwin korzysta z wielowątkowości?

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

Hm... wygląda - niestety - na dość optymalny proces, tj. - mało można to usprawnić :) Ew. zmiana lokalizacji Excela na taką, gdzie kropka to przecinek :) Spacje na taby mogą być niepotrzebne jeśli w Excelu będziesz miał odpowiednią funkcję tekstową. Ale to mikrooptymalizacje. Ciekawe, czy Muniwin korzysta z wielowątkowości?

 

Zobaczę w ustawieniach Muniwina czy już jest możliwość wyboru własnego formatu przy zapisie pomiarów do pliku. A co do wielowątkowości, to bardzo dobry pomysł. Kiedyś używałem z programu umożliwiającego włączenie danego programu dwa razy. Ale nie wiem czy sprawdziłoby się w tym przypadku - na pewno pojawiłoby się pewne zwolnienie. Ciągłe przechodzenie z jednego programu na drugi spowoduje, że pewnie wyjdzie na jedno.

 

Jedyna rzecz możliwa do optymalizacji jest wykorzystanie tych przerw w trakcie konwertowania i etapu fotometrii. Najlepiej będzie, aby szybko zapisać te 9 plików, które łącznie zajmą nie więcej niż 5 minut. Następnie przechodzimy do dalszej części materiału - kiedy dojdziemy do dwóch 10-minutowych przerw, to będzie czas na przygotowanie pomiarów do Excela (wracamy do punktu 5). W ten sposób zaoszczędzimy 20 minut, a całkowita długość trwania analizy skróci się nawet o 30%.

Odnośnik do komentarza
Udostępnij na innych stronach

Nie znam dokładnie Twojego problemu kropkowo przecinkowego, ale kiedyś sam badałem kwestię zamiany przecinka z klawiatury numerycznej na kropkę i były porady, że takie rzeczy spokojnie załatwia się w opcjach Windowsa, nawet jakieś efekty uzyskałem, może i Tobie uda się tą drogą zamienić je tam gdzie potrzebbujesz :)

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

To jest w opcjach lokalizacji. Powinno się dać wybrać separator dziesiętny startując z Panelu Sterowania. Albo wybrać wszędzie US. Natomiast wielowątkowość to pytanie do programu Muniwin. Jeśli nie ma wbudowanego użycia wątków (tyle, ile fabryka dała) to na dowolnym wielordzeniowym kompie - notabene, są jeszcze inne?- będzie wolniejszy i to drastycznie.

Edited: właśnie sprawdziłem, że obsługa wielu core'ów jest na liście "todo" muniwina. To słabo, chyba że aktualizują tą listę rzadziej, niż kod:)

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

Edited: właśnie sprawdziłem, że obsługa wielu core'ów jest na liście "todo" muniwina. To słabo, chyba że aktualizują tą listę rzadziej, niż kod:)

 

Rzadko kiedy aktualizują stronkę, gdyż część zadań została już wykonana w ostatniej wersji (np. minor planet objects).

 

Nie jestem też informatykiem. Ale jeśli mogę odpalić Muniwina dwukrotnie bez dodatkowych programów, to rozumiem, że to również wykonali? :)

Muniwin__2.png

Odnośnik do komentarza
Udostępnij na innych stronach

Dwa procesy (czyli 2x odpalenie jednego programu) to nie to samo, co dwa wątki. Tyle wiem na pewno :) Obsługa wielu rdzeni pozwoliłaby na szybsze (ok 4krotnie na 4 rdzeniach)przetwarzanie w ramach 1 procesu, na 1 bloku pamięci. Tymczasem 2 procesy na raz mogą zjeść na raz za dużo RAMu. Już nie mówiąc o 4 czy 6.

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

  • 7 miesięcy temu...

Minęło trochę czasu i nauczyłem się nieco więcej. Ta technika o której mówiłem to w zasadzie jest differential photometry. I działa doskonale, co pokazuję na poniższym przykładzie :) Oczywiście w nieco inny sposób, niż to kiedyś (wyżej) pisałem.

 

Gwiazdka ma około 10.425 magnitudo. Uśredniłem (żółte punkty) po piętnaście pojedynczych ekspozycji 20 sekund każda (niebieskie punkty). Pierwszy, trzeci, piąty i siódmy punkty to normalne pomiary. Dodałem jeszcze średnie pomiędzy nimi, aby pokazać stabilność uzyskiwanych pomiarów. Taką dokładność 5-minutowych ocen uzyskuję dla gwiazd mających 7-8 magnitudo, a nie 10.5! Jest power :)

 

PDS 110 [4] differential photometry.png

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

Mam 10 gwiazd referencyjnych i zamiast wykorzystywać wszystkie jednocześnie, wybieram tylko te najlepsze w danym momencie. Na przykład, mamy siedem dobrych, natomiast trzy zostały "uszkodzone" przez seeing. Te trzy wprowadzą największe niedokładności. Tą metodą pozbyłem się ich i wykorzystałem pozostałe 7. To jest sytuacja dla pierwszej klatki. Dla kolejnej może być inaczej, więc patrzę jaka sytuacja jest teraz. W ten sposób wykluczając, rozrzut zmalał mi z +/- 0.045 mag na +/- 0.015 mag :) I to są same niebieskie punkty. Z kolei, co do żółtych - możemy uśredniać tak jak zawsze lub wybierać tylko te klatki, w których liczba użytych gwiazd referencyjnych będzie największa. Jeśli w danej klatce wykorzystano zaledwie dwie gwiazdy referencyjne z dziesięciu, to coś z nią jest nie tak (prawdopodobnie zmienna zaburzona znacznie przez atmosferę) :)

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

7 minut temu, Behlur_Olderys napisał:

To może mediana zamiast średniej? :)

Ten wykres jest tak wstępny, tutaj będzie sporo modyfikacji i poprawek :) Akurat średnia wypadła znacznie lepiej pod kątem dokładności. Zawsze sprawdzam jak wychodzi przy średniej i medianie, jednak tutaj różnica jest zauważalna (+/- 0.015 a +/- 0.020 mag). Żółte punkty przy medianie są rozrzucone jeszcze bardziej.

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

8 minut temu, Hans napisał:

Nic osobistego, nic przeciw uśrednianiu, ale jakoś bardziej naturalne wydaje mi się robienie wysokiej jakości klatek 1 do 1. Ot oldskul taki ;)

 

Pozdrawiam.

Hans, nie zatrzymuj się w miejscu. Obecnie większość obserwatoriów poszukiwawczych sumuje dane, szczególnie jeśli obiekt jest bardzo jasny.

 

Cytuj

How does Kepler make its measurements?

In ordinary operation, Kepler looks at the same field over and over and over and over many times; the length of the mission is planned to be at least 3.5 years. The camera takes exposures in the following manner:

  • each individual exposure is about 6 seconds long
  • 9 exposures (about one minute total) are collected into a "short cadence group"
  • 270 exposures (about 30 minutes total) are collected into a "long cadence group"

 

Odnośnik do komentarza
Udostępnij na innych stronach

  • 1 rok później...

Szukałem odpowiedniego wątku (a takich było pełno), ale chyba chodziło o ten. W ramach potrzeb na konferencję, przedstawiam wyniki związane z selektywnym wybieraniem na podstawie odrzutu najgorszych pomiarów. Tylko tu inaczej - ja tutaj nie uśredniam pojedyncze oceny, lecz stackuję wybrane klatki. Wniosek ciekawy - wywalenie 20% klatek (nie pomiarów) spowodowało wzrost dokładności z std=0.0028 mag do std=0.0020 mag na przykładzie tranzytu WASP-3 b. Jak tego dokonałem?

 

Przeprowadziłem fotometrię na pojedynczych 3716 klatkach po 4 sekundy. Aby wiedzieć jak bardzo pomiar odskakuje, musiałem znormalizować krzywą poprzez usunięcie tranzytu wykonując poziomą linię. Ważne jest, aby uniknąć zdegradowania momentu wyjścia i wyjścia. Dlatego celowo wybrałem ten tranzyt, gdyż rozpocząłem obserwację dokładnie w momencie wejścia. Skorzystałem ze średniej kroczącej obejmującej krótszy czas pomiarów w momencie kontaktów oraz dłuższy poza nimi (przy bardzo płytkich tranzytach można już stosować o tej samej długości, aby nie wprowadzać za bardzo "modelu"). Wykres był nieco poszarpany (natura średniej kroczącej), dlatego wygładziłem na kształt litery U, aby nie faworyzowało w pewnej chwili odstające pomiary. Każdy pomiar porównałem z wartością dla uzyskaną dla modelu (który jest niezbędny, jeśli jest to głębokie zjawisko), a za pomocą percentylów odznaczyłem te klatki, które były najbardziej odległe. I tu jest ważne - klatki, a nie pomiary. Więc nie uśredniam pojedynczych pomiarów z usunięciem tych 20% najgorszych, lecz stackuję znów do czasu integracji 120s, lecz usuwając po 20%. To, co jest istotne, to ilość klatek wypadających dla danych dwóch minut - raz jest ich np. 21, innym razem 27. Postanowiłem już zestackować po 24 kolejnych FITSów, więc ich nieco się różni (raz 21x4s, innym razem 27x4s), jednak ich średnia i tak wypada dla ~120s. Te pomiary zostały zaprezentowane na krzywej:

 

image.png

 

Po lewej - wynik przed (30x4s), po prawej po zestackowaniu wybranych klatek. To co jest istotne, wróciłem do pojedynczych pomiarów - uzyskane stacki nie nakładają się już w żaden sposób na siebie (nie ma średniej kroczącej). Czyli przeszliśmy do punktu wyjścia - mamy stacki i tylko na nich prowadzimy pomiary. Wejście i wyjście także nie uległo degradacji.

 

To dowodzi, że usuwanie polepsza dokładność pomiarową - działa to podobnie, jak przy astrofotografii metodą lucky imaging. Na zawsze pozbyłem się problemu średniej kroczącej, skoro są czyste stacki. Równie dobrze mogę powiedzieć, że miałem w tamtych klatkach satelity na gwiazdach, więc tak czy siak trzeba było się pozbyć. Minusem tej metody jest czasochłonność. Czy warto podejmować się tego zadania tylko dla zmniejszenia rozrzutu o 40%? Pierwotne wyniki uzyskałem po 2-3 godzinach, natomiast krzywą po prawej - po ponad 8 godzinach. Wiele procesów powtarza się i należało wykonać trzy kopie. Napisałem już do autora Muniwina o prośbę odblokowania dwóch elementów (obecnie "skróty" w programie nie działają), aby to przyspieszyć. Po zautomatyzowaniu (gotowy skrypt w Excelu) powinno być to wykonalne w 3-4 godziny, a więc niewiele dłużej.

 

Jak automat będzie gotowy, przetestuję wyniki po usuwaniu 5%, 10%, 30% czy nawet 50% pomiarów klatek. Nie chcę bazować na uśrednianiu tych pojedynczych, lecz na stackach - stąd wymaga więcej czasu. Wartość optymalna wciąż czeka na odnalezienie, ale raczej nie przekraczałbym tych 20%. Myślę, że będzie zależało od ilości klatek wypadających na 120s (którego ciągle się trzymam). Prawdopodobnie im więcej klatek, tym większą wartość procentową można użyć.

 

A nazwa tematu "live binning" teraz bardzo nie pasuje... pasowałoby, gdyby stackowało się tak, jak po lewej stronie, tych klatek o krótkich czasach naświetlania. W zasadzie tutaj pokrywa się tylko to - klatki przy WASP-3 b miały po 4s naświetlania. Obserwację przeprowadziłem za pomocą kamery ASI178MM-c i teleobiektywu Canon FD 300mm f/2.8L. Zaledwie 4 cale średnicy. To nie jest metrowy teleskop. Przewaga CMOS nad CCD w aspekcie krótkich czasów jest wyraźna.

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

A to nie jest podobna metoda, którą testowałem blisko 10 lat temu i generalnie nie została dobrze przyjęta (pre-stackowanie pakietów klatek)? Na priwie zostało to wręcz shejtowane - jako totalnie nieprawidłowe podejście do danych fotometrycznych :P

https://astropolis.pl/topic/26770-hat-p3b-pionierskie-rozdziewiczenie/

Odnośnik do komentarza
Udostępnij na innych stronach

Ten temat mnie też bardzo interesuje. Moim zdaniem odrzucanie klatek powinno być wyjątkiem - każda klatka to jakaś informacja. Odrzucać - nie odrzucać punkty odstające to zresztą temat ostrych sporów wśród fizyków. Myślę też, że zamiast odrzucania badź łączenia lepsze jest "ważenie" każdej ramki tak, by jej wpływ na ostateczny wynik był adekwatny do jej jakości. Trzeba tylko znaleźć kryterium ważenia tej jakości. Odrzucam wyłącznie te pomiary, które znacznie odbiegają od reszty (kryterium może być odległość od średniej wyrażona np. w wielokrotnosci odchylenia standardowego).

Oczywiście ręcznie nie przerobisz 30 tys. fotek z jednego tranzytu, czy obrotu planetoidy. Dlatego, tradycyjne szkoły wymyślały rozmaite urposzczenia, które dziś są często kulą u nogi. Komputery nie miały mocy ani pamięci by obsłużyć macierze o rozmiarach potrzebnych do odwzorowania krzywej jasności za pomocą szeregów Fouriera 100-rzędu dla tysięcy ramek, z których każda ma inną wagę :). Ale już mają. Tylko softu póki co brak...

 

@LibMar, pogadamy w Berlinie :).

 

Pzdr,

Tomek

 

 

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

5 minut temu, Adam_Jesion napisał:

A to nie jest podobna metoda, którą testowałem blisko 10 lat temu i generalnie nie została dobrze przyjęta (pre-stackowanie pakietów klatek)? Na priwie zostało to wręcz shejtowane - jako totalnie nieprawidłowe podejście do danych fotometrycznych :P

https://astropolis.pl/topic/26770-hat-p3b-pionierskie-rozdziewiczenie/

W tym wątku widzę tylko o stackowaniu. W ówczesnych czasach występowała inna metoda, która polegała na wykonywaniu tylko długich czasów ekspozycji (np. po 2 minuty). I to właśnie robi się dalej w obserwatoriach. Unikamy wtedy wprowadzenia dodatkowego szumu. CMOS z tym nie ma problemu.

 

Głupotą nazwałbym wysyłanie takiej obserwacji do ETD:

image.png

 

A duży rozrzut pomiarowy wynika z zastosowanych krótkich czasów ekspozycji. Przez 4s, gwiazda na skutek zaburzeń przez atmosferę nie zdąży się ustabilizować jasnościowo. Tu trzeba pakietować (jakoś nie lubię tego słowa) po 2 minuty. Fajnie też widać różnicę w dokładności przy 0.46. Wymagana była poprawka w ostrości i tak naprawdę skopałem. Kolejny raz widzę, że rozogniskowanie nie zawsze poprawia wynik, a ewentualne zastosowanie większej apertury, zwiększa dodatkowo rozrzut.

 

Standardy się zmieniają. Podejście do obróbki w CMOSach jest inne niż w CCD, choć nie miałem z nimi nigdy do czynienia. Po prostu tutoriale i przewidywania dokładności nie sprawdzają się. W przeszłości nigdy nie stosowano krótkich czasów, bo masz długi czas zapisu. Tak długi, że tracisz tyle cennego materiału, że długimi czasami wyjdzie Ci dokładniej. Dlatego robienie 120s zamiast 5x20s może być bardziej precyzyjne, jeśli po każdej klatce potrzebujesz 4s na zapis. Tutaj inaczej - albo wybieram 1x120s przy jakimś sporym defocusie (a po co?), albo 30x4s z możliwością selekcji. Nie podejmę się tego, mając 6x20s. Z kolei 30x4s, 60x2s czy 120x1s - jak najbardziej. A zestackowanie w każdym przypadku przyczyni się do uzyskania podobnej dokładności pomiarowej, pod warunkiem, że jest podobnie mocno doświetlona (tutaj operowałbym różnym gainem). Udowodniłem to sobie na podstawie HD 209458 b. Ale... dlaczego? Po prostu niski poziom szumów CMOS. Szum odczytu przy takich stackach nadal jest na bardzo niskim poziomie. Minus krótszych czasów - gorzej dla słabych gwiazd. Ale nie interesują mnie teraz słabe gwiazdy, ważne, że WASP-3 b jest dobrze naświetlona (do 50% histogramu).

 

Fajnym przykładem jest HD 6121 - zmienna typu Delta Scuti o amplitudzie 0.006 mag. Stacki i uśrednianie nie pokazały nic wyraźnego. Po usunięciu ok. 20% - niespodzianka! Widać falowanie zgodne z efemerydami (tam gdzie max/min, ono występuje). Szkoda, że nie mam na tyle dobrego materiału, aby to zrobić ponownie nowym sposobem. Po drodze muszę przejść do AIJ, a ten nie radzi sobie dobrze z rozjechanymi gwiazdami na skutek kolimacji. Dopiero później dowiedziałem się jak odpowiednio ustawić swój obiektyw, aby zostały punktowe. 

 

Stąd każda osoba pracująca z CCD przez wiele lat, zawsze będzie kierowała się metodą długich czasów, bo wydaje się niezmienne. Na AAVSO ludzie do dzisiaj kłócą się co jest lepsze. Zwykle jest tak, że osoba z CCD zostaje przy CCD, a ludzie z CMOSem zostają przy CMOSie. Dokładnie jak na forum co kilka tygodni. W rzeczywistości mają rację z CCD oraz CMOS. Kluczem jest tutaj zastosowanie, co nas interesuje. CCD jest "dla leniwych" ( :) ), natomiast z CMOSem trzeba posiedzieć trochę dłużej. W przypadku tranzytów, tanim sprzętem (do 10 tysięcy) masz większe pole do popisu CMOSem. Drogi CCD z wielką matrycą i większym teleskopem (np. CDK) sprawdzi się lepiej, bo ma nadal duże pole widzenia przy dużej średnicy. Przy takim samym budżecie, z niskimi kwotami lepiej sprawuje się CMOS, z większymi (100+ tysięcy) - CCD. Zupełnie tak samo jest w astrofotografii :) I co ważne - tranzytów. Bo jak interesuje nas szukanie gwiazd zmiennych, to lepiej rozważyć CCD.

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

Godzinę temu, LibMar napisał:

W tym wątku widzę tylko o stackowaniu. W ówczesnych czasach występowała inna metoda, która polegała na wykonywaniu tylko długich czasów ekspozycji (np. po 2 minuty). I to właśnie robi się dalej w obserwatoriach. Unikamy wtedy wprowadzenia dodatkowego szumu. CMOS z tym nie ma problemu.

 

Głupotą nazwałbym wysyłanie takiej obserwacji do ETD:

image.png

 

A duży rozrzut pomiarowy wynika z zastosowanych krótkich czasów ekspozycji. Przez 4s, gwiazda na skutek zaburzeń przez atmosferę nie zdąży się ustabilizować jasnościowo. Tu trzeba pakietować (jakoś nie lubię tego słowa) po 2 minuty. Fajnie też widać różnicę w dokładności przy 0.46. Wymagana była poprawka w ostrości i tak naprawdę skopałem. Kolejny raz widzę, że rozogniskowanie nie zawsze poprawia wynik, a ewentualne zastosowanie większej apertury, zwiększa dodatkowo rozrzut.

 

Standardy się zmieniają. Podejście do obróbki w CMOSach jest inne niż w CCD, choć nie miałem z nimi nigdy do czynienia. Po prostu tutoriale i przewidywania dokładności nie sprawdzają się. W przeszłości nigdy nie stosowano krótkich czasów, bo masz długi czas zapisu. Tak długi, że tracisz tyle cennego materiału, że długimi czasami wyjdzie Ci dokładniej. Dlatego robienie 120s zamiast 5x20s może być bardziej precyzyjne, jeśli po każdej klatce potrzebujesz 4s na zapis. Tutaj inaczej - albo wybieram 1x120s przy jakimś sporym defocusie (a po co?), albo 30x4s z możliwością selekcji. Nie podejmę się tego, mając 6x20s. Z kolei 30x4s, 60x2s czy 120x1s - jak najbardziej. A zestackowanie w każdym przypadku przyczyni się do uzyskania podobnej dokładności pomiarowej, pod warunkiem, że jest podobnie mocno doświetlona (tutaj operowałbym różnym gainem). Udowodniłem to sobie na podstawie HD 209458 b. Ale... dlaczego? Po prostu niski poziom szumów CMOS. Szum odczytu przy takich stackach nadal jest na bardzo niskim poziomie. Minus krótszych czasów - gorzej dla słabych gwiazd. Ale nie interesują mnie teraz słabe gwiazdy, ważne, że WASP-3 b jest dobrze naświetlona (do 50% histogramu).

 

Fajnym przykładem jest HD 6121 - zmienna typu Delta Scuti o amplitudzie 0.006 mag. Stacki i uśrednianie nie pokazały nic wyraźnego. Po usunięciu ok. 20% - niespodzianka! Widać falowanie zgodne z efemerydami (tam gdzie max/min, ono występuje). Szkoda, że nie mam na tyle dobrego materiału, aby to zrobić ponownie nowym sposobem. Po drodze muszę przejść do AIJ, a ten nie radzi sobie dobrze z rozjechanymi gwiazdami na skutek kolimacji. Dopiero później dowiedziałem się jak odpowiednio ustawić swój obiektyw, aby zostały punktowe. 

 

Stąd każda osoba pracująca z CCD przez wiele lat, zawsze będzie kierowała się metodą długich czasów, bo wydaje się niezmienne. Na AAVSO ludzie do dzisiaj kłócą się co jest lepsze. Zwykle jest tak, że osoba z CCD zostaje przy CCD, a ludzie z CMOSem zostają przy CMOSie. Dokładnie jak na forum co kilka tygodni. W rzeczywistości mają rację z CCD oraz CMOS. Kluczem jest tutaj zastosowanie, co nas interesuje. CCD jest "dla leniwych" ( :) ), natomiast z CMOSem trzeba posiedzieć trochę dłużej. W przypadku tranzytów, tanim sprzętem (do 10 tysięcy) masz większe pole do popisu CMOSem. Drogi CCD z wielką matrycą i większym teleskopem (np. CDK) sprawdzi się lepiej, bo ma nadal duże pole widzenia przy dużej średnicy. Przy takim samym budżecie, z niskimi kwotami lepiej sprawuje się CMOS, z większymi (100+ tysięcy) - CCD. Zupełnie tak samo jest w astrofotografii :) I co ważne - tranzytów. Bo jak interesuje nas szukanie gwiazd zmiennych, to lepiej rozważyć CCD.

A czy muniwin ma "wejście" od strony command line (cmd)? Można napisać skrypt który go wywołuje z parametrami, czy robisz to jakoś "ręcznie" ?

Odnośnik do komentarza
Udostępnij na innych stronach

5 minut temu, Behlur_Olderys napisał:

A czy muniwin ma "wejście" od strony command line (cmd)? Można napisać skrypt który go wywołuje z parametrami, czy robisz to jakoś "ręcznie" ?

W zasadzie to już jest niemal automat - po wrzuceniu klatek, zaznaczasz wszystkie etapy, które chcesz zrobić. Konwersja, klatki kalibracyjne, szukanie gwiazd, dopasowanie. I po jednym przycisku czekam 2-3 godziny. Zapisuję je w postaci 1-klatkowych stacków, bo one są przesunięte. Tak, że gwiazdy znajdują się zawsze w tej samej pozycji X oraz Y. Po analizie w AIJ (selekcji), wracam do Muniwina i stackuję teraz do 120s (po 30 na jeden stack). Nie mogę od razu przejść do AIJ, bo ten ma problemy z dopasowywaniem gwiazd, więc na takich trzeba pracować.

 

Wszystkie skalibrowane stacki po 1 klatce chciałbym teraz zestackować, a one są już odpowiednio przesunięte. Po co miałbym na nowo wyszukiwać gwiazdy i na nowo dopasowywać, skoro mam dopasowane - chciałbym od razu kliknąć stack, ale nie da się. Nie mogę skopiować pierwszego projektu, bo w Muniwinie nadal pozostają wszystkie klatki (tylko potem pojawiają się errory "File not found"). I to jest właśnie ten proces, który trwa 2 godziny...

 

@Behlur_Olderys, podałbyś mi w jaki sposób mogę szybko usunąć wybrane pliki z folderu, mając listę ich nazw? W Excelu mogę wygenerować listę klatek do selekcji. Wyglądałaby coś w tym stylu:

 

delete C:/(…)/frame_0048.fts

delete C:/(…)/frame_0053.fts

delete C:/(…)/frame_0077.fts

delete C:/(…)/frame_0092.fts

delete C:/(…)/frame_0115.fts

 

To było coś, że zapisywało się linijki pliku .txt, ale w innym formacie (.cfg? .bat?). Po otwarciu tego pliku miało automatycznie zrobić to, co jest w kodzie wyżej - usunąć wybrane pliki. Kiedyś coś takiego miałem, ale nie mogę znaleźć - było w jakimś tutorialu o IRIS. Ręczne usuwanie kilkuset klatek spośród kilku tysięcy zajęło mi 30 minut. To znacznie szybciej niż googlowanie w poszukiwaniu tego sposobu (bez skutku), przez co straciłem dobre 15 minut.

Odnośnik do komentarza
Udostępnij na innych stronach

3 minuty temu, Gajowy napisał:

Challange accepted ;-). Masz dane źródłowe (ramki/fitsy/aviki) dla tego wykresu?

 

Pzdr,

Gajowy

No właśnie, to jest 30 GB materiału :) (3716 klatek). Stacki okazały się być dokładniejsze niż średnie, co jest przewagą - można je łatwo wysłać. W tym przypadku to zaledwie 124 pliki (30x mniej).

Odnośnik do komentarza
Udostępnij na innych stronach

1 minutę temu, LibMar napisał:

No właśnie, to jest 30 GB materiału :) (3716 klatek). Stacki okazały się być dokładniejsze niż średnie, co jest przewagą - można je łatwo wysłać. W tym przypadku to zaledwie 124 pliki (30x mniej).

3700 ramek to nie jest dużo :). Myślę, że ważona regresja wielomianowa na całości danych dałaby Ci lepsze rezultaty niż stack, a przynajmniej warto to sprawdzić. Nie wiem, czego oczekuje ETD, ale moze wystarczy im podesłać dane wynikowe, a nie surowe?

 

Pzdr,

Gajowy

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ę.