Krzysztof z Bagien

Dobra, to tak na szybko; gdybym napisał tu jakieś bzdury, to proszę mnie poprawić. Żeby dobrze wytłumaczyć o co chodzi w tych pomiarach i wykresach, musimy zacząć od początku, czyli od tego, jak w ogóle działa matryca światłoczuła. Każdy piksel to taki malutki detektor promieniowania elektromagnetycznego (światła) oparty półprzewodniki. W (bardzo) dużym skrócie - jak na taki piksel pada światło, to zaczyna płynąć w nim prąd. Generalnie każdy pojedynczy foton może nam wygenerować jeden elektron (dlatego też niektóre wartości podaje się właśnie w elektronach oznaczanych jako e lub e-), ale nie każdy to zrobi - prawdopodobieństwo, że takie zjawisko zajdzie to tzw. sprawność kwantowa (QE - quantum efficiency). Np. jeśli sensor ma sprawność kwantową na poziomie 90% to oznacza, że statystycznie 90% padających na każdy piksel fotonów wygeneruje po elektronie (na tych wykresach nie ma informacji o sprawności kwantowej i wykorzystując opisane tu mechanizmy nie możemy jej zmierzyć, więc musimy wierzyć w to, co podaje producent). Im sprawność kwantowa wyższa - tym lepiej. Oczywiście im dłużej naświetlamy każdy piksel, tym więcej fotonów na niego padnie i więcej elektronów nam się wygeneruje. Ten wygenerowany prąd jest następnie wzmacniany (myślę, że można w skrócie powiedzieć, że za stopień tego wzmocnienia odpowiada parametr "gain", który możemy sobie ustawiać podczas rejestracji obrazu; przy najniższym ustawieniu mamy jakieś tam wzmocnienie bazowe, a im wyżej to ustawimy, tym zmocnienie będzie większe) i "zliczany" przez przetwornik analogowo-cyfrowy (analog-digital converter, ADC - czyli układ, który ten nasz analogowy prąd z elektronów przetwarza do postaci cyfrowej). Im wyższe napięcie, tym więcej zliczeń zarejestruje ADC (zależność powinna być generalnie liniowa), te zliczenie określane są jako ADU (analog-digital unit, czyli dosłownie jednostki analogowo-cyfrowe). Maksymalna wartość zliczeń ADC określana jest w bitach, ale oznacza efektywnie po prostu to ile różnych poziomów jasności dany sensor jest w stanie od siebie odróżnić i zapisać w postaci cyfrowej; np. IMX462 ma ADU dwunastobitowy, czyli rozróżnia 2^12, czyli 4096 poziomów jasności. Jak łatwo zauważyć - im więcej bitów ma ADC danego sensora, tym dokładniej jesteśmy w stanie odwzorować rzeczywistość; ale nie trzeba się tym aż tak bardzo przejmować, o czym później. Ponieważ każde urządzenie ma jakąś tam skończoną dokładność, to sam proces odczytu napięcia z piksela i późniejsza zamiana na postać cyfrową muszą być obarczone błędem - ten błąd to szum odczytu - i jest to wartość charakterystyczna dla danego sensora, generalnie im jest mniejszy, tym lepiej. Statystycznie jest to wartość, jaka zostanie dodana do tego, co zarejestrował dany piksel (jest to wartość losowa, czasem jest więcej, czasem mniej). Nowoczesne matryce CMOS mylą się w bardzo niewielkim stopniu (szczególnie w porównaniu np. do starszych urządzeń CCD). Co istotne, szum odczytu nie jest stały, ale zmniejsza się wraz ze zwiększaniem gainu; dodatkowo nowsze matryce zmieniają sposób odczytu przy wyszszych wartościach gainu tak, żeby jeszcze bardziej zmniejszyć szum odczytu - np. na wykresie z ASI462MC czerwone iksy oznaczają właśnie szum odczytu i widać skokowy spadek powyżej gainu 80. Im wyższy gain, tym łatwiej zarejestrować jakieś dane tam, gdzie nie ma za dużo światła, ale odbywa się to niestety kosztem tego, że tam gdzie jest jasno dość szybko dobijemy do maksimum ADU i przestaniemy rejestrować cokolwiek użytecznego (prześwietlimy obraz), więc zmniejsza się nam efektywna rozpiętość tonalna nagrywanego obrazu. Po wykonaniu pomiarów dostajemy tabelkę z danymi - i mamy w niej: - Gain Value - jest to wartość gainu, którą ustawiamy w programie podczas rejestracji (różni producenci stosują różne skale, czasem zaczyna się to od 0, czasem o 100 itd.); pozioma oś na wykresie - e/ADU - ile elektronów (na piksel) potrzeba, żeby zwiększyć zliczenie ADC o jeden (dla danego piksela); im ta wartość jest większa, tym mamy większą rozpiętość tonalną (różnica między maksymalnym i minimalnym poziomem jasności rejestrowanego obrazu jest największa), ale kosztem rozróżniania niewielkich różnic w jasności - a jak jest mała, to odwrotnie (mała rozpiętość tonalna, ale za to lepiej odróżniamy niewielkie różnice); zielone plusiki na wykresie. - Read Noise (e) - szum odczytu, wyrażony w elektronach (o tyle elektronów statystycznie myli się nam matryca podczas odczytu każdego piksela przy danym gainie); jeżeli rejestrowany sygnał będzie dużo mniejszy od tej wartości (za mało światła i/lub za krótki czas naświetlania, więc fotony generują za mało elektronów), to po prostu zginie w tym szumie i nie będziemy w stanie go poprawnie zinterpretować; czerwone iksy na wykresie. - Full Well (e) - pojemność "studni" każdego pojedynczego piksela w elektronach, czyli tyle elektronów każdy piksel może wygenerować, zanim będzie całkowicie nasycony, co na wyjściu da nam całkowicie biały piksel w obrazie; jeśli dobijemy do tego maksimum i będziemy naświetlać piksel dalej, to nie zarejestrujemy już żadnych danych (mamy piksel całkowicie biały i bardziej biały nie będzie - czyli go prześwietlimy). - Relative gain - wzmocnienie względne, czyli powiedzmy mnożnik wzmocnienia; tyle razy bardziej od wzmocnienia bazowego sygnał jest wzmacniany przy danym ustawieniu gainu. - Rel. gain (db) - to, co powyżej, tylko wyrażone w decybelach. - Dynamic Range (Stops) - rozpiętość tonalna rejestrowanego obrazu w jednostkach ekspozycji (EV), anglojęzyczni nazywają je "stops"; inaczej mówiąc, jest to stosunek maksymalnej jasności, która może być prawidłowo zmierzona, do minimalnej, determinowanej przez szum odczytu (nie możemy zmierzyć jasności równej 0, bo nawet jak nie będzie żadnego światła, to i tak będziemy mieć szum); maksymalna wartość w EV będzie równa ilości bitów ADC. Na wykresach na białym tle (tych od producenta) mamy generalnie to samo. Na poziomej osi jest gain jaki możemy sobie ustawić, a poszczególne okienka to: - FW(e-) - Full well, czyli pojemność studni. - GAIN(e-/ADU) - to samo co e/ADU - DR(stops) - dynamic range, czyli rozpiętość tonalna (w EV). - Read noise(e-rms) - szum odczytu. Jakie można wnioski wyciągnąć z tego typu wykresów? Możemy np. zobaczyć, jakie będą optymalne ustawienia dla danego scenariusza, przy czym po tych pomiarach mamy dane zarówno dla nagrywania w ośmiu bitach (mniejsze pliki!) jak i dwunastu (większe pliki - bez względu na to, czy ADC ma 12, 14 czy 16 bitów i tak pliki są szesnastobitowe), bo producent podaje tylko dane dla maksymalnej głębi bitowej - ale to jest trochę takie dzielenie włosa na czworo, bo jak się parametry dobierze na oko, szczególnie przy nagrywaniu jasnych obiektów jak planety czy Księżyc, to nic strasznego się tak naprawdę nie stanie, jeśli nie trafimy w te optymalne ustawienia. Przy planetach i Księżycu generalnie nie ma sensu rejestracja w formacie szesnastobitowym, spokojnie można przejść na 8 bitów i niczego się nie traci (a pliki wychodzą sporo mniejsze i jesteśmy w stanie wyciągnąć więcej klatek na sekundę). Można też spokojnie dać duży gain, bo co prawda rozpiętość tonalna pojedynczej klatki będzie taka sobie (choć np. z pomiarów wyszło, że dla obu kamer w 8 bitach możemy gain ustawić i na 300 i dalej pojedyncza klatka ma maksymalną możliwą głębię tonalną), ale jak zestackujemy ich odpowiednio dużo, to wzrośnie ona znacząco (i dlatego właśnie niekoniecznie trzeba się martwić tym, że kamera ma tylko 12 bitów). Jeśli chcemy mieć jak największą rozpiętość tonalną, to powinniśmy nagrywać z jak najniższym gainem i dobrać odpowiednio długi czas naświetlania (albo ustawić High Conversion Gain, czyli taką wartość, w której elektronika przełączy się w ten drugi tryb z mniejszym szumem odczytu - jeśli nasza kamera ma taką funkcję) - ale to bardziej dotyczy obiektów głębokiego nieba, więc niekoniecznie celów dla kamer planetarnych (choć można i w tym celu ich używać i osiągnąć całkiem sensowne efekty - dzięki niskiemu szumowi odczytu). Bardzo fajnym narzędziem jest też właśnie ten sprytny histogram ("smart histogram") w SharpCapie, bo tam możemy w prosty sposób zobaczyć, czy dane ustawienia są w miarę sensowne - czy może zwiększyć czas naświetlania, albo czy przejść na format szesnastobitowy. Jest też opcja (ale, jak pisałem wcześniej, tylko w wersji płatnej), żeby program sam dobrał właściwe ustawienia - i wyniki pewnie niektórych by mocno zaskoczyły, bo przy tak niskich szumach odczytu jakie oferują nowoczesne kamery, wcale nie potrzeba naświetlać klatek po 15 minut, żeby zarejestrować różne tam mgławice czy inne galaktyki. I to jest czysta matematyka, którą wymyślili ludzie dużo mądrzejsi ode mnie (a piszę to dlatego, że na stówę zaraz ktoś przyjdzie i powie, że to nieprawda i że se coś wymyślam - a to wcale nie ja wymyślam i to akurat nie są te ewentualne bzdury, które należałoby poprawić :P)

Żaden problem - tylko załatw czyste niebo

Nie wiem, bo za dużo jej nie używałem - kupiłem ją parę dni temu z myślą o kamerze all-sky (bo poprzednią kamerę popsułem ). Ale generalnie wszystko w niej działa, nagrywa co ma nagrywać, nie wywala się - więc chyba jest git.

Nie wiem, czy czuję się kompetentny, żeby to tłumaczyć. Wydaj mi się, że mniej-więcej wiem o co cho, ale nie chciałbym napisać jakichś głupot. W wolnej chwili spróbuję coś na ten temat napisać, ale w sumie żeby sensownie korzystać z kamery astro, to nie trzeba tego wszystkiego rozumieć; ten wątek to w większości takie tam dywagacje dla nerdów bez większego znaczenia strategicznego

Specjalnie dla Ciebie - drugi pomiar ASI462MC, podpiętej do innego komputera (jeśli używamy kamery z kilkoma komputerami, to właściwie to można sobie plik z zapisanymi wynikami po prostu skopiować na innego kompa, nie trzeba za za każdym razem od nowa się w to bawić - ale for science ) 8 bitów: 12 bitów: Jakieś tam niewielkie różnice faktycznie są.

Cała procedura zajmuje dosłownie kilka minut, więc temat jest na spokojnie do ogarnięcia podczas picia herbatki

Tak mi w głowie właśnie zaświtało, że skoro mamy dzięki Oskarowi całkiem sporo informacji na temat różnych filtrów, to może warto by było także porównać kamery. Jest to zadanie o tyle prostsze, że SharpCap ma wbudowane narzędzie do analizy sensora kamery, które pozwala uzyskać jego charakterystykę (co później się przydaje np. do automatycznego określenia optymalnych ustawień czasu naświetlania i gainu - ale to inna nieco bajka). Można więc to sobie zrobić samemu w domu i nie potrzeba do tego żadnych specjalistycznych narzędzi - wystarczy kamera i komputer. Do tego typu rozmyślań skłoniło mnie to, że charakterystyki kamer ZWO i Player One są najwyraźniej różne (co wyszło nam w innym wątku) a także to, że ostatnio zmierzyłem sobie w ten sposób kamerę SV305 od Svbony, która posiada kolorowy sensor IMX290 - więc niby taki sam, jak w ASI290MC, ale jej zmierzona w SharpCapie charakterystyka nie pokrywa się z tym, co na swojej stronie prezentuje ZWO. Mam też ASI462MC - i tutaj pomiary dość dobrze się zgadzają z tym, co jest na stronie producenta, więc zakładam, że ZWO nie publikuje jakichś tam wykresów z dupy, tylko że faktycznie ich wersja kamery jakoś się różni do tej od Svbony (oni niestety nie mają na stronie takich danych) czy też innych marek. @Behlur_Olderys - Ty zdaje się masz 462 w wersji od QHY, więc gdybyś mógł wykonać taką analizę i pokazać wyniki, to porównalibyśmy sobie to z tym, co wyszło u mnie. Jak ktoś ma jakąś kamerę z matrycą IMX290 w wersji kolorowej, to też bym poprosił. Inne modele kamer/matryc też jak najbardziej można porównać, bo czemu nie - tylko po prostu te dwie mam pod ręką. Poczytać o narzędziu można sobie tutaj: https://www.sharpcap.co.uk/sharpcap/features/sensor-analysis Cała procedura jest dość prosta - trzeba mieć po prostu jednolite, stałe oświetlenie (najlepiej więc robić to przy sztucznym świetle nad którym mamy kontrolę) i możliwość zakrycia kamery, kiedy będzie taka potrzeba (program poprosi o to w pewnym momencie). Włączamy pomiar, program mówi nam, czy jest mu za jasno czy za ciemno, jak mu wszystko pasuje, to już sobie całą robotę zrobi. U mnie było za jasno tak na dzień dobry, więc zwyczajnie przykrywałem kamery zwykłą kartką z drukarki; do pomiarów kamery miałem bez żadnych obiektywów. Kolor światła nie ma znaczenia, liczy się tylko jego natężenie. Aha, pomiary można wykonywać tylko dla kamer, które SharpCap może w pełni kontrolować (więc np. webcamy odpadają) i tylko w trybie RAW (osobno dla 8 i 12/14/16 bitów). Moje wyniki: ASI462MC w trybie ośmiobitowym: i dwunastobitowym: I wykres od ZWO (generalnie pokrywający się z tym, co SharpCap zmierzył w 12 bitach): Svbony SV305 8 bitów: i 12 bitów: Dla porównania wykres od ASI290MC - naniosłem na niego to, co wyszło z pomiaru SV305, żeby było widać, jakie są różnice: Edit: a, bo jeszcze zapomniałem napisać! SharpCap może nam wyświetlić histogram rejestrowanego obrazu; jak już sobie wykonamy oba pomiary (8 i 12/14/16 bitów) dla danej kamery, to są one zapisane i na ich podstawie program informuje nas m.in. o tym, czy w danych warunkach jest sens nagrywania w formacie ośmio- czy szesnastobitowym i jak bardzo przy danych ustawieniach szum odczytu wpływa na to, co próbujemy zarejestrować. SharpCap może też automatycznie określić optymalny czas naświetlania i gain w danych warunkach - ale to już jest funkcja dostępna tylko w wersji płatnej (bo sama analiza sensora i histogram są też w wersji darmowej). Nad histogramem mamy dwa paski - górny informuje o wpływie szumu odczytu (czerwony - dominuje, pomarańczowy - jest istotny, zielony - jest pomijalny); dolny mówi o tym, czy dany zakres jasności rejestrować w 8 czy więcej bitach (ciemnozielony - obecny tryb jest optymalny, jasnozielony - można przełączyć na 8 bitów bez straty informacji).

Może pomiar robią dla matrycy mono, a potem mnożą to przez charakterystykę filtrów Bayera?

OK, ale wynika z tego - co?

Skąd wziąłeś ten wykres? Bo teraz na stronie ZWO jest taki:

Nie ma tragedii, ale miało dupę urywać

OK, nie mówię, że nie - ale poza jeszcze 464, który nie jest aż tak bardzo większy, to nie ma chyba matryc z urywającą dupę czułością w podczerwieni. No i jeszcze jedna rzecz- taki MPCC był projektowany dla światła widzialnego, w podczerwieni może się okazać, że wprowadza np. sporą aberrację chromatyczną (a może nie - nie wiem). Wprowadza też aberrację sferyczną na pewno - i też nie wiadomo, czy w podczerwieni będzie ona większa, czy mniejsza, czy jaka. Pewnie można by to rozrysować w OSLO i zobaczyć co wyjdzie; chyba nawet gdzieś mam model MPCC skądś tam wzięty, tylko nie wiem jak dokładny on jest, bo Baader dokładnej specyfikacji nie podaje, więc na pewno jest to jakieś przybliżenie.

Otóż to, więc można to zrobić jako ciąg poleceń GOTO i będzie skokowo, ale nie można za pomocą moveaxis, żeby było płynnie. Więc, żeby była jasność - chodzi mi o to, żeby było płynnie

Jesteś pewny? Bo np. w AZ-EQ5 powyżej 1000"/s oś musi się zatrzymać, żeby zmienić prędkość - i jest to ograniczenie firmware'owe, z tego co wiem we wszystkich montażach SW (coś tam mieli zmienić w tym roku w nowych wersjach firmware'u, ale akurat do AZ-EQ5 nie ma nowszej wersji; do HEQ-5 jest, ale tylko do nowszych egzemplarzy, niekompatybilna ze starymi), więc płynne śledzenie szybszych satelitów nie jest możliwe.

Ale z 462? Przecież ten sensor nie jest aż tak duży, żeby potrzebował korektora komy.

A co z takimi powłokami jest Ci potrzebne do rejestrowania podczerwieni? MPCC?

Jesteście w stanie sprawdzić, czy montaż ogarnie śledzenie satelitów itp.? Czyli - czy da radę z kompa dowolnie zmieniać prędkość obrotu obu osi niezależnie od siebie? Bo, zdaje się, ten montaż od Rainbow Astro niby miał umieć, a potem się okazało, że nie da się ustawić różnych prędkości dla obu osi; ale mieli to poprawić.

Łe...

Mówimy konkretnie o filtrach (bardzo) wąskopasmowych, które były zwyczajnie lipne. Znaczy, pewnie dobre też się trafiały, ale sporo było takich z kompletnie nietrafionym pasmem. Jak masz LRGB, to zupełnie inna bajka i na ich podstawie żadnych wniosków na temat wąskopasmowych nie wyciągniesz. A doświadczenie niestety pokazało, że marka nie gwarantuje jakości. A jeśli już mówimy o własnych doświadczeniach z tą firmą: na dwa nowe, kupione w sklepie filtry Baadera, dwa miały jakieś wady - i w obu przypadkach były to wady samego szkła; kontrola jakości, jeśli by jakaś była, powinna to wyłapać.

Dużo gorsze już być nie mogły, więc kierunek zmian jest jeden

I faktycznie jest inny wykres, niż @bas.sicwrzucił? W sensie, że to naprawdę jest z pomiarów danego egzemplarza, a nie jak Chińczycy mają w zwyczaju np. w przypadku filtrów - jeden wykres do wszystkiego?

Na szczęście mamy jeszcze coś takiego jak rękojmia.

Czy to ptak? Czy to samolot?

To ten - obecnie oficjalna wersja jest taka, że widzimy się w czwartek, 14.07 o 18.