Behlur_Olderys

Znalazłem http://articles.adsabs.harvard.edu//full/1995ApJ...450..450S/0000450P011.html W skrócie: Gazy wyrzucane z Io do przestrzeni wokół Jowisza są jonizowane i tworzą świecący torus wokół planety na wysokości orbity księżyca. Mgławica świeci w paśmie SII znanym z palety HST. Czy ktoś próbował już to zobrazować amatorsko? A może jest jakiś śmiałek na forum, który podjąłby się tematu? Wygląda to fantastycznie...

@dobrychemik Jedne z podstawowych operacji robione na stackach możesz zobaczyć tutaj: http://what-when-how.com/introduction-to-video-and-image-processing/point-processing-introduction-to-video-and-image-processing-part-2/ Balans kolorów: (z filmiku https://www.youtube.com/watch?v=YyDFXHx4twQ ) Wyostrzanie/dekonwolucja:http://www.inf.ufrgs.br/~oliveira/pubs_files/FD/FD_page.html Reszta to maskowanie gwiazd itp. rzeczy charakterystyczne i unikalne dla astrofoto, które normalnie nie zrobisz "w dzień", bo nie ma na czym

Myślę (łudzę się...) że jeśli ktoś wydaje tysiące złotych na sprzęt to robi fotki takie, żeby mu się podobały

20 czy 60 to nieduża różnica Proponuję 10x300 vs 3000x1

Bardzo podobnie wyglądało moje pierwsze zdjęcie astro i jeden z pierwszych postów na Astropolis. To było chyba jeszcze w liceum, a zdjęcie robiłem kładąc aparat na jakimś kamyku. Też Wielki Wóz Tak trzymaj, idź po więcej!

Bo tego nie lubię i tyle. Jak mi się coś nie podoba to staram się to komunikować, licząc na sprzężenie zwrotne. Czasami ludzie sami siebie nie słyszą, szczególnie w internecie Cóż, skoro wykresik nic Ci nie mówi, to nie wiem, czy moje nieudolne tłumaczenie coś da. Swoją drogą dziwne, że krytykujesz mój wybór hardware'u skoro nie wiesz, co ja w ogóle robię... Próbowałem to już tłumaczyć kilku osobom ale nie jestem taki mocny w słowie Ogólnie jest to rodzaj interferencji, która zamienia przesunięcie poziome w pionowe, mierzone linijką ccd. W praktyce liczę na zwiększenie rozdzielczości enkodera około 20-30 krotne. Enkoder o rozdzielczości kilkunastu sekund łuku kosztujący poniżej 100zł to fajna sprawa na początek

Gratuluję świetnego zdjęcia! Z chęcią zobaczyłbym kiedyś porównanie detalu np. 10000x5s vs 100x500s, żeby otworzyć oczy niedowiarkom Wiadomo, szum itp. będzie inny, ale detal powinien być wybitnie różny...

Szkoda, że zawsze stosujesz taki trochę przykry ton wypowiedzi. Żeby nie powiedzieć: zniechęcający. Nieważne. 1. Jak już mówiłem, uskoki nie mają znaczenia, dopóki wprowadzony szum ma średnią zero, a tak jest przy tego typu kwantyzacji. Btw drukowałem pdf a nie ps, i nie na fotoploterze tylko naświetlarce CTF. 2. Sensor ma doskonale dobrane do tego zadania parametry: dużo pikseli, żeby uśredniać błędy, szybki odczyt (kilka tysięcy odczytów na sekundę przy dobrym adc) oraz idealny rozmiar pikseli 64um. Tyle, co szerokość 1 ciemnego paska. To nie przypadek. 3. Rzut oka na wykres sygnału z sensora powinien wyjaśnić (przy odrobinie wyobraźni) dlaczego sensor jest umiejscowiony niemal równolegle. To tylko prototyp, PoC. Nie widzę sensu narzekania na jakość. Łatwo jest nakupić drogich elementów i nie potrafić ich złożyć do kupy ani zmusić do działania, albo zastosować błędny algorytm. W drugą stronę, jeśli mój program będzie działał na tym, to zadziała na wszystkim.

Mały update: Na szybko sklecony setup testowy i stronka w Pythonie do oglądania wyników. Takie "górki" zamierzam potem potraktować kilkoma algorytmami przetwarzania obrazów i zbadać zachowanie i powtarzalność rezultatów i ich dokładność. Sprzęt to wydrukowana tarcza (ma dosyć biedną jakość, jak porównywałem do fabrycznego enkodera z drukarki, ale w mojej metodzie to nie jest aż tak ważne) oraz TSL1401 - czujnik liniowy 128x1 pikseli 64x63.5um. (Max value to jednostki umowne. Max adc tutaj to 1024)

Widać dwa kolory. A gdzie trzeci? No i gwiazdki jakby zbyt niebieskie... No ale bez RGB to rozumiem takie są... oczywiście oprócz tego to zbieram szczękę z podłogi, big fan

Może myślał w sensie: nikt z tej sali nigdy się tam nie przeniesie, bo widział po twarzach, że sami staruszkowie

1. Niecentryczne mocowanie może dać PE co najwyżej o okresie 1 dnia. Dobry enkoder zauważy jednak, że paski nie są cały czas na tej samej wysokości. Po to jest np. biały pasek na mojej tarczy. Da się to uwzględnić. 2. Ziarnistość paska powinna być gaussowska. Więc uśrednianie pomiarów w czasie i przestrzeni polepszy dokładność. Mam nadzieję, że to Gauss... 3. Czujnik jest krzywo - bez znaczenia, dopóki nie zmienia pozycji z pomiaru na pomiar. Wiem, że to teoria, ale jeśli masz matryce CCD w której masz dziesiątki tysięcy pikseli, o rozmiarach kilku um, to zmierzenie położenia paska szerokiego na 64um i bardzo długiego, nawet naiwnym środkiem ciężkości powinno dać wyniki o dokładności poniżej um. Tak, jak guider wyznacza pozycję gwiazd z dokładnością subpikselową...

OK, ta linia miała być, żeby łapać dobrze pozycję samego dolnego końca. W sumie cały projekt tego koła dosyć mało przemyślany był, skupiłem się na paskach... Pewnie z czasem dojdę do wprawy. Tak wygląda zbliżenie na interferencje z dwóch kół, które naświetliłem (identycznych). Całkiem ładny wzór Taką interferencję też można jakoś wykorzystać. Ja zamierzam mierzyć naświetlenie na pasku CCD w rodzaju TSL1401 i wykorzystać proste rozpoznawanie obrazu na ESP8266, żeby wyciągnąć informację o przesunięciu pomiędzy odczytami bez błędów wynikających z niedokładności samego naświetlania enkodera. Czy pojawią się inne błędy? Zobaczymy

Ta mora to - później zauważyłem - grupowanie w Inkscape. Nie wiem, czemu tak drukuje, ale po konwersji do .ps chyba znika. A na czym to drukowałeś? Ten biały pasek to nie wiem dokładnie gdzie jest, na pewno jest minimalny odstęp pomiędzy największym kołem, a paskami : to to?

Czy problemy o których mówicie nie wynikają po części z faktu, że większość enkoderów jest projektowana raczej dla dużych prędkości kątowych (większych niż spotyka się w astro), przez co najzwyczajniej przyjmuje się, że nie ma czasu na obróbkę cyfrową sygnału? Tutaj mam 60ms na jeden odczyt. Mógłbym nawet robić zdjęcie i wrzucać je do sieci neuronowej, i czasowo by się zmieściło na jakimś RPi. To otwiera zupełnie nowe możliwości. @trouvere Oczywiście mogę pdf dać tutaj. Nie ustawiałem rozdzielczości. Linie czarne są proste a białe rozszerzają się ku górze, celowo - nikt mi nie wydrukuje tych nanometrów... 3600 probka.pdf

O jakim okresie mówimy? Chodzi Ci o to, że linie mogą być raz bliżej, raz dalej bo tak naświetliła drukarka, albo że klisza się wygięła itp? Można to wyeliminować jeśli ma się inny, niezmienny układ odniesienia.... Np jakąś małą matryce ccd

Jak masz enkoder na głównej osi, to mechanizm przełożenia może mieć luzy, niedoskonałości, PE i wszystko inne. Może mieć plastikowe tryby zmieniające obwód o 2mm/stopień Celsjusza. To wszystko jest bez znaczenia, jeśli masz enkoder na osi i mówisz montażowi: kręć mi silnikiem tak długo, aż enkoder powie dość W przeciwnym wypadku precyzyjne wykonanie montażu z dokładnością poniżej kilkudziesięciu " jest bardzo trudne w warunkach amatorskich. Ja nie mam w domu tokarki ani drukarki 3D Jeśli we wspomnianych, na maksa amatorskich warunkach, da się stworzyć enkoder z rozdzielczością kilku arcsek, i montaż, który potrafi z niego korzystać, to otwiera się pewien niedostępny sektor rynku dla zwykłych zjadaczy chleba.... oczywiście, jak to w moich rozmyślaniach - wszystko jest teoretyczne

Wiadomo - montaż astro

Wydaje mi się, że to będzie trójkąt z gaussowsko zaokrąglonymi rogami. Nie wiem, jak bardzo, ale wydaje się, że te rogi sporo psują. Trudno to tak dobrze zamodelować. Inna sprawa to jedna linia to za mało. Najlepiej umieścić (nakleić) maskę kilkudziesięciu linii na jednej diodzie tak, żeby łapała się interferencja. Przez to uśredniamy błędy wielu pasków na jeden odczyt i nasz trójkąt jest bardziej powtarzalny... Ale wciąż zaokrąglony. Teraz, można by wziąć drugi (trzeci, czwarty, itd...) czujnik przesunięty w fazie, żeby zawsze gdzieś łapał się ten ładny, prosty bok trójkąta, a nie brzydki, zaokrąglony wierzchołek. To pierwszy z moich pomysłów, rzeczywiście Ale najpierw muszę wypróbować inną metodę Wiadomo, że dołoży się sporo processingu przy okazji. Mój zamierzony workflow to szybki ADC (rzędu 1 Msps) + ewentualny oversampling podłączony po SPI do ESP8266 (albo ESP32). Na ESP już można sobie przy 80MHz zegarze jakąś bardziej zaawansowaną matematyką podziałać. Jeden pełen odczyt musi trwać max. 60ms (bo niebo obraca się 15"/s). A najlepiej w granicach 10ms żeby mieć zapas czasu na inne rzeczy... Abstrahując od tego, do testów potrzebuję usztywnienia i jakiejś obudowy, żeby można było kręcić i sprawdzać odczyty.

Zastanawiałeś się, jaką funkcją położenia jest tak mierzona jasność? Ani to Gauss, ani trójkąt, ani sinus Mam jeszcze ciekawszy pomysł, ale najpierw sprawdzę, czy działa

Czyli niby można ale nie można Próbowałem już z czujnikami sin/cos ale to z wielu względów słaby trop. Szukam innej drogi. Kiedyś warto spróbować w celach dydaktycznych

Mały update: Za 15zł udało mi się wydrukować (naświetlić na kliszy) wstępny prototyp: 3600 linii na kole o średnicy jakichś 15cm. To duże koło W Krakowie na polibudzie okazuje się, że można klisza jest dość cienka więc trzeba ją opakować w jakieś sztywne kółko, żeby się nie gięło. Teraz już zostaje mi rozkmina : jak z 3600 zrobić 1296000? Niby wystarczy pomnożyć razy 360... Interesuje mnie rozdzielczość rzędu pojedynczych sekund łuku. Jest kilka możliwości, najłatwiej byłoby robić zdjęcie mikroskopem co chwila

Czemu nie ASI120?

Rozdzielczość 200lpi. Kreski mają 0.032mm i są poustawiane co 0.1 stopnia. Nie wiem, jak to się ma do dpi... Ktoś ma godny polecenia jakiś zakład, który coś takiego robi?

Hej, Mam taki wzór do enkodera kołowego - najprostszy, czyli kilka tysięcy linii na obwodzie koła W zbliżeniu to wygląda tak: Oczywiście mam to narysowane w formie wektorowej, za pomocą darmowego Inkscape. Teraz moje pytanie: co trzeba zrobić, żeby wydrukować to na takiej przezroczystej folii? Ktoś kiedyś drukował takie rzeczy? Jakieś wskazówki? Szczególiki?