Skocz do zawartości

Behlur_Olderys

Moderator
  • Postów

    5 148
  • Dołączył

  • Ostatnia wizyta

  • Wygrane w rankingu

    12

Treść opublikowana przez Behlur_Olderys

  1. Nie pod jedną, ale pod wiele jak najróżniejszych. Chodzi mi o to, by skalibrować algorytm fitowania krzywej (skoro i tak znamy z grubsza parametry gwiazdy i orbity) w taki sposób, żeby dla różnych tranzytów fitował zawsze jak najbliżej prawdy - tj. jak najlepiej wyznaczał czas początku i końca tranzytu. Jeszcze raz - nie dla jednego układu, ale dla wielu, jak największej ilości. Wydaje mi się, że skoro znamy całą teorię (są wzory na kształt krzywej) i mamy sporo danych referencyjnych, to dobrze byłoby tą wiedzę wykorzystać. Jeśli można zwiększyć dokładność pomiarów bez inwestycji w drogi sprzęt, to co kosztuje spróbować? Ciekawy materiał w tym temacie: http://astro.up.pt/investigacao/ficheiros/2012_AA_540_A62_1.pdf W szczególności ustęp: I to jest to, o czym mówię - żeby opracować jak najlepiej działający mechanizm fitowania krzywej teoretycznej do pomiarów, żeby poradzić sobie z tym: Pozdrawiam.
  2. Można sobie wyobrazić, że mając zbiór rejestracji tranzytów o doskonałej rozdzielczości czasowej (np. z jakiegoś super obserwatorium - mam nadzieję, że takie są... ) bierzemy do sprawdzenia "idealną" krzywą, a następnie porównujemy ją z uzyskaną samodzielnie. Przy odpowiedniej ilości materiału być może udałoby się skalibrować algorytm do wyznaczania czasu początku/końca tranzytu tak, aby zgadzał się jak najlepiej z danymi treningowymi. Być może istnieje jakiś rodzaj fitowania albo innej operacji na krzywych, która odtwarzałaby czas tranzytu z lepszą dokładnością. Oczywiście robocze hipotezy można by sprawdzać na innych, "testowych" krzywych o dużej rozdzielczości. Co myślicie?
  3. No, to jest poważny już sprzęt do fotometrii! Gratuluję wyników, widać że dysponujesz bardzo dużą rozdzielczością i mógłbyś wyłapywać znacznie delikatniejsze tranzyty.
  4. Python na windowsie to jakaś zmora.

    Żeby narysować głupi wykres danych z seriala (od Arduino) chcę mieć pyqtgraph. Ale to potrzebuje PyQt (brak binarek na windę) albo PySide (zła wersja Pythona). No to zmieniam wersję - nie ma MSCV10. To może matlplotlib? Za wooooolnoooo. Matplotlib + gtk? Nie ma gtk. Pip install gtk. Nie ma pygobject. Pip install pygobject. Błąd? Nie ma MSVC. Szlag by to trafił, instalacja MSVC 7GB się ściąga, a miało być szybko łatwo i przyjemnie :/ Na linuxie pewnie wszystko zadziałałoby "od strzała" 

    1. Pokaż poprzednie komentarze  4 więcej
    2. MateuszW

      MateuszW

      U mnie działa, jak mawiają :P

    3. wiatr

      wiatr

      gratulacje samozaparcia, dla mnie próba uruchomienia jednej słownie jednej aplikacji (żadne tam uchowaj buku programowanie) przeciągnęła mnie przez pół internetu instalacje i odinstalowanie jakiejś nieprawdopodobnej ilości badziwewia. Kontakt z pytonem sprowadził mnie do poziomu czytania jakiegoś wątku na elektrodzie a nawet jeszcze gorzej - do zapytania kogoś kto chyba sie na tym zna....

      Jak to jest miód i orzechy to znaczy że ja mam alergie bo "wstrząs anafilaktyczny" był blisko - ale odnalazłem drogę do światła, wyszperałem w sieci windową alternatywę i świat znów jest piękny:D

    4. Krzychoo226

      Krzychoo226

      Jeżeli musiałeś odwiedzić elektrodę to nie dziwie się że organizm zaczął się bronić...

  5. Teoretycznie nie ma żadnych powodów, a w praktyce: zdjęcia wessela robione w takich warunkach są bardzo zaszumione (a w każdym razie: niestatysfakcjonujące). Pytanie: czy błąd jest w teorii czy w praktyce, bo przecież chyba wszyscy na tym forum widzieli doskonałe zdjęcia z ASI 1600. Tak czy inaczej ta rozbieżność powinna zaowocować jakimś wysoce nieoczywistym odkryciem, teoretycznym albo praktycznym
  6. Pętla powoli się zaciska...

    (pętla sprzężenia zwrotnego: enkoder->krokowiec) :)

    1. Adam_Jesion

      Adam_Jesion

      jaki enkoder? Rozdzielczość?

    2. Behlur_Olderys

      Behlur_Olderys

      Enkoder z drukarki - optyczny, transmisyjny, analogowy (sin-cos). Tarcza 1800 pasków na obrót, 200lpi (720" / pasek).

      Interpolacja arctan przy użyciu 16bit ADC wstępnie daje pomiar kąta z dokładnością +/- 0.5".

      Niedługo będę sprawdzał, po zapięciu pętli, ile to da realnie na osi RA przy przełożeniu ~1:2800 i sterowaniu mikrokrokami 1/16 na śrubie trapezowej ze skokiem 1mm.

       

       

      Trochę więcej o historii tego projektu:

       

  7. Atik ma full well 12000e- ale QE ok. 80%, a ASI 20000e- przy QE ok. 60%, niższym szumie odczytu, większej matrycy, i cenie 2x mniejszej. Więc o co chodzi? Jakie znaczenie ma tutaj 12bit vs 16bit? Atik nie "zgubi" ani elektronu przy gainie nawet 4ADU/e- (0.25e-/ADU) bo cała jego studnia "lekko" mieści się na 65536 stanach ADC. Tymczasem ASI z 4096 stanami na 12bit musi mieć gain bardzo mały (albo duży, zależy z której strony patrzyć), 0.2ADU/e- (5e-/ADU) żeby nasycić full well na max. białym pikselu. Czyli np. robiąc pomiary fotometryczne Atik da teoretycznie dokładność +/-1e nawet dla obiektu zaświetlającego całą studnię, czyli dokładność 1/12000. A ASI naświetlając całą studnię da maksymalnie dokładność 1/4096, bo tyle dało ADC. Stąd mniemam że Atik nadaje się lepiej do zastosowań naukowych. Dodatkowa konkluzja: stosowanie unity gain dla ASI nie wykorzystuje jej całego potencjału bo zapełnia tylko 1/5 całej studni. Z kolei naświetlenie całego zakresu 20000e- dla ASI nawet na tych nieszczęsnych 12bit pozwoli na jednej klatce złapać więcej fotonów zanim się nasyci. QE 80% kontra 60% na korzyść Atika zmniejsza tą przewagę niejako o 3/4. Więcej fotonów to większy SNR, dla 20000 wyniesie 141 (max). Tymczasem max SNR pojedynczej klatki dla Atika to ok 110, 77% tego, co w ASI, więc niewiele gorzej, ale jednak. Stackowanie pogłębiło by ta różnicę. Z tym że należy pamiętać, że zapełnienie całej studni Atika będzie trwało ponad 2x krócej (szybciej napełni się 12000 z 80% QE niż 20000 z 60%). To daje też przewagę ASI, gdy mamy duże LP i palimy krótsze klatki, niż by można, bo matryca się prześwietla. 5e- szum odczytu dla Atika to sporo w porównaniu do ~1.4e- ASI na Unity gain. (Ale już ok 3.5e- na gainie 5e-/ADU). Przy rejestracji bardzo słabego sygnału, gdzie szum odczytu dominuje SNR, ASI powinno pokazać sporą przewagę. Załóżmy Unity gain, sygnał ok. 0.05fotona/s, ultra ciemne niebo 0.05fotona/s, pomijalny szum termiczny i 100s klatka. Na atiku zarejestruje się 4e- , ale szum będzie sqrt(4+4+5*5) ~ = 5.7, SNR ~= 0.7 Na ASI te 5 fotonów da tylko 3e-, będzie to otoczone szumem sqrt(3+3+1.4*1.4) ~=2.8. SNR ~1, czyli troszkę lepszy. Oczywiście to ekstremalny przypadek, a binning hardware'owy dramatycznie poprawia sytuację Atika, jeśli by go zastosować. (Nie wiem czy jest taka opcja?) Niemniej, stackowanie spotęguje ten efekt, a z drugiej strony przy "normalnych" obiektach i sporym LP ten efekt będzie bez znaczenia. Podsumowując: dla mnie czysto teoretycznie jest remis, choć gdybym robił fotometrię to zdecydowanie Atikiem. Natomiast stackowanie tysięcy bardzo krótkich klatek słabych obiektów, albo jasne obiekty z miasta - to wydaje się coś w sam raz dla ASI. Dla wszystkiego pośrodku wydaje się że różnicy nie zauważymy. Oprócz najważniejszego: ta sama długość klatki i gain -> Atik łapie 25% wiecej fotonów (QE!) Czym Ameryki nie odkryłem, ale sobie trochę policzyłem;) Pozdrawiam!
  8. Jeszcze jedno pytanie - trochę badam rynek. Czy rzeczywiście potrzebna Ci dokładność 0.3 arcsek? Albo inaczej: jak dokładne enkodery rzeczywiście są potrzebne - w sensie dokładności trackingu... Czy gdyby enkodery miały np. dokładność 1" a cena zmalałaby z 3500 do 500, to które byś wybrał?
  9. Polecam coś z poleasingowych laptopów, pewnie w okolicach 500zł się coś znajdzie, warto poszukać. Przecież nie trzeba chyba nie wiadomo ile ramu czy rdzeni do Maxima?
  10. Bardzo ładnie napisana recenzja. Przyjemnie się to czyta, choć trzeba było czekać do późna na ostatni odcinek btw: Naprawdę aż 3500 kosztują te enkodery? Trzeba to zmienić
  11. Z niezgodności pomiędzy teorią a praktyką rodzi się postęp, więc nie ignorowałbym tego Dlatego jeśli chcesz na kamerze o bardzo niskich szumach odczytu i bardzo niskim dark noise ugrać coś zmieniając czas jednej klatki z 3min na 5min przy tym samym *sumarycznym* czasie naświetlania, to chciałbym wiedzieć, jaki wg Ciebie mechanizm będzie odpowiedzialny za poprawę? Zresztą, w sumie możemy wrócić do tematu jak już wypalisz 100x300s
  12. Jeśli wypalisz tyle samo *sumarycznie* czasu to różnicy nie będzie jakiejś drastycznej. Widziałeś wykresy w tamtym wątku, dla jasnego obiektu i pojedynczych klatek powyżej 60s sygnału jest tak dużo, że jego szum przebija wszystkie inne szumy (dark noise, read noise) o rząd wielkości. Za to zmiana f/8 na f/5 przy tej samej ogniskowej (a po zdjęciach widzę, że mieliście z Grzędzielem dosyć podobne f, chyba że pokazujecie cropy) to ponad 2.5x więcej fotonów, więc polepszysz SNR około 1.5x, to dużo, ma to na pewno większy wpływ na jakość zdjęcia niż 3min vs 5min pojedynczej klatki.
  13. Domyślam się jednak, że Łukasz wyrzuca jakiś procent najbrzydszych klatek, a HAMAL po prostu "guiduje" sobie ten seeing. Natomiast jeśli zestackujemy wszystko to efekt powinien być identyczny jak jedna długa klatka...?
  14. Adam, Przecież to właśnie efekt niskiego SNR Gwiazdy są rozmyte czy też nieostre, bo są bliżej poziomu szumu, i ich sygnał się w nim gubi. Na 300s gwiazdy nie są mniejsze, tylko są bardziej 'ostrymi' pikami, wybijają się wyżej ponad szum. Przynajmniej taka jest moja interpretacja.
  15. Korzystając ze wzoru podawanego w wielu miejscach, m.in. tutaj: http://hamamatsu.magnet.fsu.edu/articles/ccdsnr.html SNR = t*S / sqrt (t*S + t*L + t*D + R*R) gdzie S - sygnał w e-/s, L - light pollution w e-/s, D - dark noise w e-/s, R - read noise w e-, t - czas naświetlania jednej klatki w sekundach oraz znanego ogólnie wzoru SNR_N(dla stacku N klatek) = sqrt(N)*SNR_1(jednej klatki) pozwoliłem sobie zasymulować wyniki z kamery CMOS ASI-1600 (manual tutaj: https://astronomy-imaging-camera.com/manuals/ASI1600 Manual.pdf) Wyciągając wartości z wykresów nieco na oko (+/-10%) zrobiłem symulację efektów, poniżej kilka wykresów: (Na osi Y zawsze będzie SNR, na osi X - totalny czas naświetlania): 1. SNR dla bardzo słabego sygnału (0.2e/s, czyli minimalny poziom rejestracji delta ADU = 1 dla 5s klatki) 2. SNR dla średnio słabego sygnału (1e/s czyli tak już coś tam widać) 3. SNR dla sporego (w miarę) sygnału 10e/s 4. SNR w zależności od temperatury matrycy dla 3 przykładowych wartości (0, 10, 20 stopni) dla bardzo słabego sygnału (0.2e-/s). Zbliżenie na ostatnie 1000s dla większej czytelności. Reszta jest opisana w legendach. Od razu pozwolę sobie wysunąć wnioski - przypominam, dla ASI-1600: Obojętnie od możliwych parametrów, zawsze dłuższe klatki dają lepszy SNR przy tym samym czasie sumarycznego naświetlania. (edited zgodnie z sugestią wessel) Im słabszy obiekt, tym bardziej to widać (to wiadomo i bez tego wykresu: przy 5s klatkach dolny limit rejestracji sygnału to 0.2e-/s, a dla 300 limit rejestracji jest 60x mniejszy) Nawet "ciepła" matryca z nieco większym szumem odczytu (dla ASI różnica: gain 300@1.3e- vs gain 139@1.75e-) daje dużo lepsze wyniki dla słabego sygnału, jeśli naświetla się 6x300s zamiast 360x5s. Przy dużym świetle od obiektu (ALBO przy dużym LP, to bez znaczenia) różnice się zacierają, szumy inne niż samego sygnału przestają odgrywać jakiekolwiek znaczenie. Czy ta teoria potwierdza się z praktyką? To już nie mi oceniać Pozdrawiam!
  16. Czy sprawdzałeś z innym, najlepiej sprawdzonym dyskiem? Jeśli operacje o których mówisz będą działać tak samo wolno na dwóch różnych dyskach to możesz wykluczyć dyski z równania
  17. Behlur_Olderys

    ISS

    Bardzo ładne kolory, wygląda jak "żywa", zwłaszcza oglądane bez przybliżenia, bo potem trochę widać artefakty jpg...
  18. (...) - MODERATOR - treści naruszające netykietę usunięte. Upraszam ponownie o utrzymanie formy wypowiedzi spełniajace standard dyskusji w przestrzeni publicznej. Ani tu ani tam nie ma żadnych praktycznych informacji nt jak dokładnie zrobić takie lustro ani, co ważniejsze, czy komukolwiek się to udało z zadowalającą precyzją w amatorskich warunkach. Mam wrażenie, że metalowe lustra (nie mówię o profesjonalnych, takich jak w JWST, tylko potencjalnie w amatorskim zasięgu) są tylko atrakcyjną legendą. BTW: ja tam wolę "jak to kupić" niż "jak to zrobić, jeśli masz w domu frezarkę, tokarkę, agregat spawalniczy, potrafisz to wszystko obsługiwać i masz 2 miesiące wolnego (najlepiej już na emeryturze)" Nawet nie wyobrażam sobie, jakim sprzętem, umiejętnościami i czasem trzeba dysponować, żeby odlać i wypolerować aluminium do dokładności takiej, jak komercyjne lustra.
  19. Pierwszy i drugi kwartał. Jest bardziej precyzyjne niż "zima - wiosna" i bardziej zwięzłe, niż "styczeń - maj" (zwłaszcza, gdy nie każdy w globalnej korporacji ma te same pory roku )
  20. 1. Moją intencją nie jest walka CCD kontra CMOS. 2. Atrapą z uśrednianiem pikseli równie dobrze można nazwać stackowanie sub-ekspozycji. Też robi się software'owo (stacking) albo hardware'owo (dłuższy czas palenia klatki). Jakoś nikt nie mówi "po co bawić się w stackowanie, to atrapa dłuższego naświetlania" .... Wiadomo, lepiej naświetlać dłużej (albo mieć hardware binning). Ale jak nie można w hardwarze, to warto próbować w sofcie. 3. Celem software binningu, tak jak stackowania, jest poprawa SNR wyjściowego obrazu. W tym wypadku - kosztem rozdzielczości przestrzennej. Jeśli okazałoby się, że software binning może choć trochę polepszyć obraz np, właśnie przy rejestracji ciemnych mgławic, to czemu by nie warto próbować? Przecież zdjęcia publikowane na forum i tak są resizowane, to czemu nie wykorzystać tego nadmiaru pikseli do poprawienia sygnału?
  21. Te zdjęcia dla mnie są praktycznie identyczne... dziwne, że moja teoria wydaje się upadać Nie zdziwiłbym się, gdyby efekt był bardzo delikatny, na granicy percepcji. Ale w ogóle nic? Nie chce mi się wierzyć, pogrzebię jeszcze w temacie i zobaczę jeszcze w domu na innym materiale Po akwizycji możesz zrobić dowolny bin, bo to operacja matematyczna na pikselach. Kamera (CCD) zrobi Ci to hardware'owo, a dla CMOS można to zrobić software'owo. Ale zasada jest ta sama: sumujesz wartości kilku pikseli i tworzysz z tej wartości nowy, większy piksel. Skoro stackowanie działa, to czemu nie binning, to jest praktycznie to samo, tylko w innych wymiarach. Jest np. do przeczytania w manualu ASI 1600 https://astronomy-imaging-camera.com/manuals/ASI1600 Manual.pdf Software'owy binning policzy też 4x read noise, ale biorąc pod uwage, że read noise jest około 4x mniejszy w CMOS-ach niż w CCD to powinno wyjść dosyć podobnie.
  22. Możesz rozwinąć? Jakieś uzasadnienie, albo przykład? Chyba że nie zgadzamy się co do mojego cokolwiek nieprecyzyjnego nazewnictwa Rzeczywiście, słowo "skalowanie" jest tu nie na miejscu - chodzi mi o software binning. Skalowanie dało by efekt już na miniaturce, ale to nie jest binning. Najlepiej byłoby wykonać tą operację na surowych klatkach, a potem normalnie zestackować. Do porównania polecałbym takie dwa 'produkty': 1. normalny stack bez binningu zresizeowany 0.25x 2. stack surowych klatek zbinowanych wcześniej 4x4 Oczywiście, dla CMOS dodaje się też szum odczytu (nie to, co hardware binning w CCD) ale koniec końców SNR się zwiększa i o to chodzi. Wydaje mi się, że software bin4x4 zdjęcia (oczywiście zmieniając rozdzielczość z ok. 3000x2000 do 750x500) dałby zauważalne polepszenie widoczności ciemnych struktur, które przecież i tak nie mają jakichś niesamowitych detali.
×
×
  • 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ę.