MateuszW

15 minut temu, Gajowy napisał:

I to jest klucz. Jeśli kamera może wysłac taki sygnał to właściwie jesteśmy w domu. Jak precyzyjny jest moment pojawienia się tego sygnału?

 

Pzdr,

Gajowy

W dokumentacji chyba nie mówią tego wprost, ale wygląda na to, że jest to natychmiastowe - czyli pewnie jakoś sprzętowo sprzężone z matrycą. Piszą tam natomiast, że można sobie zmierzyć opóźnienie między triggerem, a rozpoczęciem naświetlania właśnie porównując czas impulsu triggera, oraz impulsu zwrotnego kamery. Czyli ja bym założył, że sygnał zwrotny jest idealny.

Ale jest jeszcze coś - rozkmiłem te informacje zapisywane w klatkach, o których mówiłem na filmie. To jest bardzo pomysłowe

Otóż, one są faktycznie na klatce, na obrazie  Ale nie jako ładne cyferki, jak z insertera, tylko cyfrowo - jako jasność pikseli. To, co widać w narożniku screena, to akurat zapisany timestamp.

I teraz myślę, że lepiej będzie to wykorzystać. Tzn podłączyć sygnał PPS z GPS do kamery jako input, a na klatce zapisywać timestamp, oraz stan pinów (czyli pps). Timestamp jest jak zrozumiałem generowany przez samą kamerę, oczywiście to tylko względna wartość. Jest on mierzony w momencie zakończenia ekspozycji. Teraz na podstawie analizy tych danych (trzeba by napisać program, który to odczyta), czyli względnego timestampu, stanu pinu pps, oraz czasu rozpoczęcia nagrywania (z windowsa) powinno się dać ustalić precyzyjnie czas każdej ramki. Metoda ta ma przewagę nad poprzednią (czyli zapisywanie czasu na arduino), bo nie trzeba tu właściwie nic sprzętowego robić - starczy podłączyć GPS do kamery, bez żadnego arduino i żadnego programowania! Otrzymujemy w efekcie coś bardzo podobnego do QHY174 GPS

Panowie i panie, mam rozwiązanie!!!

Udało mi się ogarnąć, do jak wykorzystać piny GPIO w Chameleon 3. Analogiczna sytuacja powinna być w innych kamerach PointGreya, które opierają się o te same matryce, co ZWO. Zapraszam na krótki film, mam nadzieję że da się mnie jakoś słuchać  

Moja kamerka jest dość stara, ale wyciąga prawie 100 FPS przy malutkiej rozdzielczości. Szumy odczytu ma raczej wysokie i pewnie nie będzie tak dobrze z zasięgiem gwiazdowym. Ale to CCD, więc można użyć sprzętowy bin2, który powinien znacznie poprawić sprawę. W połączeniu z 8" f/4 może uda się uzyskać jakieś 50 fps na tej gwiździe?

Koniec końców, myślę zrobić takie urządzenie: 

Do arduino podłączę gps poprzez uart oraz sygnał pps. Podłączę pod niego również dwa piny gpio kamery Chameleon. Arduino będzie też wpięte do komputera poprzez port szeregowy (na usb). Za pomocą terminala będę mógł wybrać w arduino godzinę rozpoczęcia nagrywania. Gdy nastanie ta godzina (z dokładnością do sekundy), arduino odebrawszy sygnał pps, wyśle sygnał do triggera kamery, aby ta rozpoczęła film. Podpięty będzie również sygnał zwrotny, którym kamera sygnalizuje moment rozpoczęcia naświetlania. Arduino będzie zapisywać czas kolejnych klatek na podstawie tego sygnału i wysyłać wartości po porcie szeregowym do komputera - w celu ich zapisania, tu już nie mają znaczenia opóźnienia. Teoretycznie sygnał uruchomienia kamery jest precyzyjny, ale jest jakieś opóźnienie (może dokumentacja podaje?), więc odczytując sygnał od kamery, powinienem je poznać. Ten sygnał zwrotny powinien już być pozbawiony opóźnień. No i zapisując czas każdej klatki uodparniam się na wahania prędkości kamery, czy zgubione ramki.

Dla zainteresowanych w załączniku dokumentacja kamery (trzeba założyć konto, żeby pobrać...). Interesuje nas rozdział 6, od strony 29.

CM3-U3-Technical-Reference.pdf

2 godziny temu, Agent Smith napisał:

@MateuszW - czuj się wywołany do tablicy

Ja akurat nie wiem, bo nie robiłem nigdy takich testów  Uważam jednak, że nie ma powodu, aby nowoczesne kamery, z minimalnymi szumami odczytu i wysokim QE mogły jakoś odstawać od kamer analogowych (które tak na prawdę tak samo rejestrują światło, tylko stosują stratny i wprowadzający dodatkowy szum sposób transmisji).

No tak, to jest różnica i z tego co piszą, wprowadzona w drugiej wersji przez ZWO. Jak widać TPL ma pierwszą. Myślę, że sobie poradzę bez poziomicy, żal na nią 100 zł  O ile na pewno optyka jest ta sama.

23 minuty temu, Gajowy napisał:

Oczywiście, mogę udostępnić. Program działa jednak w trybie zdjęć poklatkowych - używam go do astrometrii, gdzie FPS nie jest kluczowy (w moim setupie pełnoklatkowy FPS to 10; większość traconego czasu to inercja kamery na żądanie wykonania zdjęcia).

 

Program działa pod Windowsem. Jaką masz wersję systemu?

Dzięki! Mam Win10 64bit

23 minuty temu, Gajowy napisał:

Nie, nie znam PoitGreya. Możesz w  parku słowach opsiać, albo podesłać jakiś link?

Cóż, mam taką kamerkę: https://www.ptgrey.com/chameleon3-usb3-vision-cameras. Już dość stara, z epoki ASI120  Jest tam z tyłu takie złącze, gdzie można podłączyć jakiś sygnał cyfrowy i go później odczytać w sdk. To jest odpowiednik ASI174: https://www.ptgrey.com/grasshopper3-23-mp-mono-usb3-vision-sony-pregius-imx174-camera. Analogicznie, masz tam okrągłe złącze do wykorzystania w sofcie. Niestety, nie wgłębiałem się w tą sprawę bardziej niż to, że da się tych pinów użyć i odczytywać ich stan

9 minut temu, Gajowy napisał:

Dla przemysłowych GPS, a zwłaszcza tak precyzyjny GPS chyba potrzebny nie jest... QHY 174 chyba, nie? Mam nadzieję ją wkrótce obejrzeć...

Na pewno znajdą się zastosowania. Kiedyś się dziwiłem, po co w przemyśle takie czułe matryce planetarne  A co do precyzji - to my tu nie potrzebujemy nic więcej, niż dają zwykłe, popularne odbiorniki. Profesjonalne GPSy np do geodezji to potrafią kosztować dopiero majątek.

Tak, 174. Kurcze, gdyby była wersja niechłodzona, to może bym nawet kupił, sprzedając równocześnie ASI 174 i nie byłoby drogo. Ale za chłodzenie też trzeba dopłacić, a ono mi zbędne.

13 minut temu, Gajowy napisał:

Nie wiem co to jest ampglow, używam ASI 290MM z krótkimi czasami :P. Bufor może przechowywać więcej ramek niż jedną, ale więcej szczegółów na ten temat nie udało mi sie zdobyć, ani nie badałem tego (w zasadzie za pomocą SDK można to było przetestować).

Ampglow to zaświetlenie matrycy wywołane nagrzewaniem się elektroniki podczas odczytu danych. W ASI podpiętych na USB2.0 występuje z powodu wolnego transferu. Na 3.0 nie ma problemu. No a żeby zapobiec problemom na 2.0, to wprowadzili właśnie dodatkowy bufor (wersje "Pro").

24 minuty temu, Gajowy napisał:

BTW2, Osobiście korzystam z własnego programu do rejestracji obrazu z kamery (Tapir), który dodatkowo wykorzystuje najbardziej precyzyjny z możliwych odczyt zegara komputera (dokładność wg dokumentacji wykorzystywanych funkcji <100 ns ) i ma parę fajnych cech niedostępnych w FC i innych softach tego typu.

Hmm, a podeślesz?  Czy to na linux? Zasadniczo mógłbym na potrzeby rejestracji tranzytów zainstalować jakąś super stabilną dystrybucję linuksa czasu rzeczywistego...

24 minuty temu, Gajowy napisał:

P.S. Jednym z pomysłów na test jakości synchronizacji jest wykorzystanie... sztucznych satelitów i rejestracja ich ruchu wraz ze znacznikami czasu, a następnie porówanie z efemerydami.

Dobry pomysł!

24 minuty temu, Gajowy napisał:

Moje badania wskazują, że przy dobrym dostępie do Internetu, za pomocą poprawnie zaimplementowanego protokołu NTP można uzyskać dokładność pomiaru czasu rzędu 0.001 sek.

"Dobrym"... Czyli zapewne po kablu? W polu raczej nie ma co liczyć na coś więcej, niż sieć komórkowa + router z telefonu + wifi. A to równa jest całkowite zaprzeczenie stabilności. Chyba lepszy jednak ten gps jako wstępna synchronizacja.

BTW, czy poza SDK ZWO bawiłeś się może PointGreyem? Co myślisz o wykorzystaniu jej pinów gpio do przekazania sygnału pps? Tych pinów używa się np do wyzwalania migawki na jakiejś linii produkcyjnej gdy czujnik wykryje przedmiot. Raczej jest to szybkie medium i wejdzie "między" ramki ze zdjęciami.

8 minut temu, Gajowy napisał:

Może wystarczy umieścić ją przy wlocie tuby? Światło powinno być na tyle wyraźne, że ramka z diodą będzie wyraźnie rozświetlona. Gorzej, jeśli ten diodowy błysk będzie trwał zbyt długo i zepsuje zbyt dużą liczbę ramek.

No ja właśnie o czymś takim myślałem pierwotnie. Ale zrobić to tak, żeby zarejestrować kilka błysków przed zjawiskiem i wyłączyć diodę na czas jego trwania.

9 minut temu, Gajowy napisał:

Proces przebiega lekko inaczej gdy kamera działa w trybie video.

No właśnie, a nas interesuje raczej tryb wideo? Choć w sumie nie wiem, czy wybór zapisu jako zdjęcia wpływa na tryb pracy kamery?

Wydaje mi się, że taka metoda, jaką opisałeś, wnosiłaby zbyt duże straty czasu, tj te wszystkie oczekiwania zamiast wykonywania maksymalnej ilości klatek jaką się da.

Spróbuję jeszcze dla zabawy poanalizować ramki USB w WireShark  Niedawno sobie uświadomiłem, że jest taka możliwość. Ze wstępnych oględzin wygląda na to, że ramki od komputera do kamery wysyłane są bardzo rzadko i raczej nie decydują o otwarciu migawki. Ale na razie nawet nie mam pewności, że patrzyłem na właściwe urządzenie

13 minut temu, Gajowy napisał:

Profesjonalne kamery mają możliwość odczytywania GPSa i dodawania znacznika czasu na poziomie oprogramowania wewnętrznego kamery.

Jest taka jedna QHY. Nie znajdzie się jakaś przemysłowa może trochę taniej?

14 minut temu, Gajowy napisał:

Dociekałem swego czasu, które ramki są tracone w kamerach ASI - dopóki nie opróżnisz buforu, kolejna ramka nie jest kopiowana do bufora kamery:

Hmm, a jak to się ma do kwestii tego magicznego bufora w nowych wersjach asi, który zapobiega ampglow? Skoro w każdej kamerze jest bufor na jedną klatkę, to jakim prawem ten amp glow się pojawia? Zakładałem, że dane są przesyłane bezpośrednio z matrycy do kompa, co by tłumaczyło ampglow na wolniejszym połączeniu. Jeśli jest bufor to nie widzę jak to jest możliwe.

Odgrzebuję stary wątek, bo chciałbym kupić korektor z okazji zakrycia Saturna przez Księżyc.

Mam pytanie, czy ZWO: https://www.teleskopy.pl/ZWO-ADC-1,25--korektor-aberracji-atmosferycznej-(nowa-wersja-z-poziomiczką)-teleskopy-4410.html oraz TPL: https://teleskopy.pl/product_info.php?cPath=32_279_327&amp;products_id=5060&amp;lunety=ADC 1 25 korektor aberracji atmosferycznej TPL to są klony?

Wyglądają identycznie. A z doświadczenia z innym sprzętem mogę powiedzieć, że TPL prawie zawsze oznacza rebrand jakiegoś zwykłego produktu. Np ich koło filtrowe, czy OAG. No ale to są mechaniczne rzeczy, a korektor to jednak optyka. Przy obu pisze to samo w kwestii szkła i dokładności, więc raczej są identyczne. Ale może ktoś coś więcej powie?

Może ktoś używa TPL i podzieli się opinią?

I jeszcze jedno przy okazji. Czy korektor lepiej dać przed czy za barlowem? Mam powermate, więc zmiana krotności nie stanowi problemu.

2 minuty temu, ekolog napisał:

Badacze nie uzyskali absolutnego pierwszeństwa na największych antenach odbiorczych na świecie

A która misja potrzebuje obecnie bardziej tych anten, niż NH? Voyagery chyba niewiele wysyłają  A na Marsa zakładam, że są mniejsze wymagania wielkości?

8 godzin temu, Gajowy napisał:

Nie zajmuję się elektroniką, ale zadaję sobie pytanie - jaki jest czas inercji samej diody? Tj. ile czasu mija od otrzymania sygnału do zaświecenia? Czy są to czasy pomijalne (tj. mniejsze niż powiedzmy 0.001 sek?).

To jest dobre pytanie. Nie mogę znaleźć jednoznacznego i pewnego źródła dla tej informacji. Znalazłem jedynie, że transoptory (czyli elementy separujące sygnał elektryczny za pomocą diody i detektora) mają opóźnienia rzędu od kilku ns do kilku us, czyli jak dla nas super krótki. Jednak nie bardzo umiem to znaleźć dla zwykłych diod. Nie mam też pomysłu, jak zmierzyć ten czas (wymaga to detektora, który również będzie miał jakieś swoje opóźnienie).

9 godzin temu, Gajowy napisał:

Rozważ jeszcze sam proces synchronizacji. Moim zdaniem, poza wstępną synchronizacją przed obserwacją nie ma sensu synchronizować zegara komputera. Znacznie korzystniej jest po prostu rejestrować poprawkę co kilka minut a później interpolować ją na moment obserwacji i dodać do wyników. Unikasz manipulowaniem zegarem, skoków czasu, niepewności zachowania się samego OS, paru operacji wejścia-wyjścia itd.

No ale jedyną możliwością na rejestrowanie poprawki jest dioda, czy coś przeoczyłem? Niby to dobra metoda, ale niewygodna przy późniejszej analizie. No i co, jeśli czas różni się więcej, niż o 0,5 s?

Jeśli chodzi o skoki czasu podczas synchronizacji zegara, to te metody nie bazują na wprowadzaniu ciągłych poprawek do wartości zegara, ale subtelnie modyfikują jego częstotliwość, co właśnie zapobiega skokom. Do tego programy, o których czytam uśredniają sobie wiele pomiarów sygnału PPS, więc dokładność z czasem się poprawia. Czytam różne rzeczy, ale generalnie wydaje się, że osiągnięcie dokładności poniżej 1 ms nie jest problemem, a być może da się zejść do dziesiątków us.

9 godzin temu, Gajowy napisał:

Wracając do synchronizacji: pamiętaj, o opóźnieniu kamery, o którym pisałem. To też trzeba zmierzyć na iluś tam próbach, w różnych warunkach, by określić średnią i odchylenie standardowe.

No tylko właśnie nie wiem jak to zmierzyć  Nie wiem, jak rozgraniczyć opóźnienie kamery od błędów mojego procesu synchronizacji. No i jeszcze pojawia się ważniejsze pytanie - na jakiej zasadzie np FireCapture nadaje znacznik czasowy klatce. Czy decyduje o tym moment wysłania żądania otwarcia migawki, moment odebrania klatki przez program, czy może inny? A może kamera robi zdjęcia bez niczyjego rozkazu, tj sama odpala migawkę z określoną częstotliwością? Wówczas program mógłby chyba tylko bazować na czasie odczytu klatki.

Zastanawia mnie również, co się dzieje, gdy kamera gubi ramki lub występują wahania fps. Czy klatki są naświetlane wciąż w równych odstępach, a szwankuje jedynie przesył (czyli czegoś brakuje, ale interwał pozostaje), czy może odczyt matrycy też ulega wahaniom?

9 godzin temu, Gajowy napisał:

Napisałem na to program, który odczytuje liczby na monitorze. Problemem jest jednak częstotliwość odświeżania monitora, która nie pozwala zejść ponizej 0.01 sek. Mam jednak i na to pomysł. BTW, podobno jakieś narzędzie do tego jest w Maximie. Wiesz coś może więcej?

Częstotliwość odświeżania? A opóźnienie monitora?  A opóźnienie karty graficznej i procesora, który zleca jej zadanie? Tu również jest wiele niewiadomych. A opóźnienie monitora potrafi wynosić do kilkudziesięciu ms (nie mówiąc o czasie zaświecania i gaśnięcia piksela).

Jeśli chodzi o maxima, to istotnie coś jest, ale nie do końca wiem i rozumiem, co  Ale nie sądzę, żeby to było super dokładne, raczej było pomyślane dla wolnych ccd. Ale zerknę w wolnym czasie.

1 godzinę temu, Gajowy napisał:

Jak będziesz testował, dobrze byłoby przy okazji opracować testy mierzące opóźnienia (średnie i ich stabilność), np. operacji wejścia-wyjścia portów szeregowych albo też czasu jaki upłynie od otrzymania sygnału GPS do momentu zaświecenia się diody (jeśli te czasy są w ogóle mierzalne).

 

Pzdr,

Gajowy

Jeśli chodzi o diodę, to myślałem żeby ją po prostu podłączyć do wyjścia PPS bezpośrednio  Ale nie wiem, jaka jest szerokość tego impulsu i pewnie będzie za krótki, żeby kamera zobaczyła błysk. Jeśli tak, to na arduino zrobię elementarny program, który w przerwaniu od gpio odpali diodę - to będzie kilka instrukcji asemblera, a więc teoretycznie poniżej 1 us (zakładając zegar kilkanaście MHz).

Jeśli natomiast chodzi o testy synchronizacji bezpośrednio w windowsie, poprzez port szeregowy, to planuję zrobić test polegający na nagraniu kamerą sygnału diody sterowanej tym samym GPSem, który będzie synchronizował komputer. Tutaj mogę już dać ultra duży FPS w ASI, żeby złapać diodę bez pośrednictwa arduino - powinna być idealnym znacznikiem. W ten sposób jednoznacznie dowiem się, jakie jest opóźnienie lub jitter między GPSem, a czasem Windowsa.

Problem w tym, że jeszcze nie kupiłem nawet odbiornika, nie mam czasu na testy, a zakrycie tuż tuż...

21 minut temu, Adam_Jesion napisał:

Totalny laik raczej sobie nie poradzi (choćby z terminologią), ale na pewno jest łatwiej, niż przez typowego maxima  

Znajdzie się taki, gdzie wystarczy wprowadzić nazwę obiektu. Także laik da radę  

Jeszcze spróbuj autostakkert. To chyba najbardziej odporny na błędy i problemy program.

2 godziny temu, szuu napisał:

może tak a może nie. dynamika oka jako receptora nie jest wcale tak wielka. jego olbrzymi często cytowany zakres ("od światła gwiazd do słonecznego dnia") nie jest możliwy do zarejestrowania równocześnie.

Tak szeroki zakres nie, ale mimo wszystko oko produkuje na żywo takiego jakby HDRa. Postrzeganie jasności jest bardziej logarytmiczne, niż liniowe. Dlatego potrafimy widzieć równocześnie to, co jest w cieniu i jasne źródło światła. Aparat albo przepali, albo nie doświetli. Albo będzie musiał składać HDR 

Ktoś wie, jaki mamy ten realny zakres w danej chwili?

10 godzin temu, trouvere napisał:

Człowiek nie jest w stanie wyobrażać sobie czegoś, czego sam nie doświadczył (nie widział, słyszał, wąchał, dotykał czy odczuwał jako temperatura - pięć zmysłów człowieka) i tu przychodzą z pomocą stereotypy.

Zależy o czym piszesz. Masz rację, że większość z nas, astrofotografów, bazuje przy obróbce na jakimś wyobrażeniu obiektu na podstawie jego zdjęć w internecie (ale nie byle jakich, tylko tych od mistrzów!), oraz własnego doświadczenia z obróbki w ogóle (podobnych obiektów itp). A więc może się tu wkraść jakiś trend, że np M27 będziemy przedstawiać jako bardziej niebieską, czy zieloną.

Ale nie zmienia to faktu, że wciąż możemy uwolnić się od stereotypów i bazować na całkowicie obiektywnych metodach obróbki obrazu, które dadzą nam w efekcie zdjęcie wolne od naszej interpretacji.

10 godzin temu, szuu napisał:

musi tylko wywołać te same pobudzenia receptorów co oryginalny fotografowany obiekt.

No, czyli opisałeś mniej więcej to, co ja wcześniej, mam rację?

10 godzin temu, szuu napisał:

tym jest regulacja balansu bieli: zniekształcaniem kolorów zarejestrowanego obrazu tak żeby wyglądał tak jak hipotetycznie zgadujemy że by wyglądał w innym oświetleniu

Tak, to jest istota sprawy. Robiąc zdjęcie oświetlonej sodówkami ulicy chcemy, żeby miała jakiś w miarę normalny kolor, a nie wściekle czerwony. Tak samo focąc coś przy świetle świetlówki chcemy żeby "biała" kartka była biała, a nie niebieska.

Ale właśnie, teraz pojawia się kolejna sprawa - jak działa balans bieli w oku? No bo oko też go reguluje, dzięki czemu w szerokim zakresie koloru oświetlenia otrzymujemy "naturalne" (odpowiadające oświetleniu Słońca) barwy obserwowanych przedmiotów. Ale skoro go reguluje, to może już nie trzeba dokonywać regulacji w aparacie? Starczyłoby zrobić zdjęcie w rzeczywistej kolorystyce (czyli wściekle czerwone sodówki) i pokazać to zdjęcie oku całkowicie odcinając się od otoczenia (ciemny pokój, gdzie widać tylko monitor). Czy wówczas oko samo nie zrobi sobie korekty i w efekcie ujrzy przedmiot tak, jakby go widziało na żywo?

A balans bieli w astrofoto ma pewien ograniczony sens - kolor tła, który wynika z LP i Księżyca zmienia kolorystykę obiektów, na co trzeba brać poprawkę, chcąc ukazać obiekt takim, jaki byłby widziany z orbity

9 minut temu, trouvere napisał:

Żeby nie było, to wyobrażenie

Tak oczywiście - wyobrażenie, czyli to co nam produkuje mózg, jest inne, a rzeczywistość taka sama. I pomimo różnego wyobrażenia, możemy określić jednoznacznie, co będzie tym obiektywnie poprawnym zdjęciem.

Hmm, chyba wiem, o co biega!

Załóżmy, że zgodnie z poprzednim postem, zrobiliśmy idealnie skalibrowane zdjęcie - czyli takie, które wysyła z monitora do oka fotony w takich samych proporcjach między kolorami, jak rzeczywisty obiekt na niebie.

Teraz patrzy na ten obiekt, oraz na zdjęcie Ziemianin. Załóżmy, że zdjęcie przedstawia gwiazdę zimniejszą, niż Słońce, a więc nasze oko odbierze ją jako pomarańczowa - w rzeczywistości i na zdjęciu.

Teraz bierzemy kosmitę, który jakimś cudem (dla uproszczenia) ma taką samą budowę oka i takie same wykresy czułości czopków, co człowiek. Kosmita ten zamieszkuje w okolicy gorętszej, czyli bardziej niebieskiej dla nas gwiazdy. Dla niego nasz niebieski kolor jest białym. Teraz kosmita patrzy na tą samą gwiazdę, którą spociliśmy i na jej zdjęcie. Wg niego gwiazda rzeczywista i na zdjęciu będzie wyglądać tak samo, jednakże inaczej, niż widział ją człowiek - kosmita zobaczy zamiast pomarańczowej, mocno czerwony kolor.

Czyli podsumowując, w obu przypadkach obserwator zobaczył taki sam kolor na niebie i na zdjęciu, jednakże dla dwóch obserwatorów był to inny kolor. Można jednak powiedzieć, że zdjęcie było wykonane całkowicie obiektywnie poprawnie - bo każdy z nich zobaczył na zdjęciu to samo, co w rzeczywistości. To "rzeczywistość" jest inna dla różnych obserwatorów!

Ale zaraz, chwila. Chyba popełniliśmy w którymś miejscu poważny błąd logiczny.

Balans bieli naszego oka to osobna rzecz, nieistotna dla problemu. Tymi samymi oczami patrzymy na galaktykę, co na zdjęcie - czyli światło jest transformowane do naszego mózgu w ten sam sposób.

W nocy nie mamy źródła światła, który oświetla obiekt, to sam obiekt jest źródłem światła. Czyli pozostaje kwestia samego obiektu.

Czyli absolutnie i obiektywnie prawidłowy balans bieli zdjęcia będzie wtedy, kiedy patrząc na ten obiekt na żywo zobaczymy takie same kolory, jak patrząc na monitor (w ciemnym pokoju) wyświetlający zdjęcie. Czyli wówczas, gdy nasz monitor będzie wysyłał do oka taki sam zestaw fotonów, jak obiekt na niebie (pomijając różnicę jasności i kwestię wykresu czułości na kolory). A to jest coś niezależnego od Słońca i Ziemi.

Jutro pomyślę, gdzie jest ten błąd

12 minut temu, Adam_Jesion napisał:

Mam chęć się podroczyć, bo cała ta dyskusja o kalibracji na gwiazdy G2V (czyli w skrócie słoneczne) i prawdziwości koloru ilustruje pewien paradoks. Dla nas na zdjęciu "prawdziwy" kolor wynika tylko i wyłącznie z balansu bieli, który narzuciło nam Słońce.

Masz świętą rację i fajnie że przypominasz o tej "globalności" problemu  My, ludzie, uznaliśmy za prawdziwą biel kolor, którym świeci nasze Słońce. Jeśli miałbym zaproponować wyznacznik uniwersalnego balansu bieli dla całego wszechświata, to mam pomysł. Weźmy za taki absolutnie biały kolor źródło światła, które emituje w każdej długości fali takie samo natężenie  Ale teraz potrzebuję porady od fizyków, bo mam problem ze zdefiniowaniem co to znaczy "takie samo natężenie"  @Behlur_Olderys? No bo energia fotonów jest zależna od długości fali. A wydaje mi się, że ani przyjęcie jednakowej energii, ani jednakowej ilości fotonów nie będzie tutaj dobrym wyznacznikiem...

18 minut temu, Adam_Jesion napisał:

Wystarczy porównać kolor wydruku w domu, przy typowym oświetleniu, a następnie wyjść na zewnątrz w słoneczny dzień. Który jest więc prawdziwy? Ten w domu, czy ten na zewnątrz?

Prawdziwy jest ten, który pokazujemy przy oświetleniu, jakie było zamierzone przy drukowaniu  I tu pojawia się dobre pytanie, jak to się określa przy wydruku? Da się nadać profil kolorów zależny od temperatury światła? Czy może przyjmuje się milcząco, że jest to barwa Słońca. Ja się na drukowaniu dużo nie znam. Wiem tylko, że na kolor, jaki dociera do oka wpływa zarówno kolor przedmiotu, jak i źródła światła, skąd przy monitorze jest prościej  (no dobra, część światła otoczenia odbija się od niego i wprowadza pewną różnicę).

Godzinę temu, trouvere napisał:

Generalnie nie podoba mi się tworzenie fałszywego (niezgodnego z rzeczywistością) obrazu kosmosu (w sensie "fotografii").

Jak rozumiem masz całkowicie ortodoksyjne podejście do astrofotografii  A już myślałem, że to ja jestem dość ortodoksyjny

To dlaczego się nie czepiasz np tego, że klasyczny fotograf, gdy wykonuje jakiekolwiek zdjęcie, nie ma ze sobą tablicy kalibracyjnej Kodaka? Nie możemy popadać w skrajność. Wystarczy że automatyka dobierze balans bieli, a jak się pomyli, to można ręcznie skorygować. Ale bez przesady, żeby się bić o drobne różnice.

Kalibrowanie koloru przed fotkami dziennymi pozostawmy NASA i ich sondzie inSight  

Godzinę temu, trouvere napisał:

Tak masz rację, w takim przypadku otrzymasz "najprawdziwszy" kolor ale tylko i wyłącznie tej jednej gwiazdy G2V, niczego więcej.

Nie prawda. Generalnie, aby prawidłowo zbalansować kolor zdjęcia potrzeba dobrać 6 współczynników, po 2 dla każdej barwy - poziom tła i skalowanie (nazwy być może są inne). Poziom tła to taki jakby offset dla kolorów, a skalowanie to taki gain - mnożnik. Żeby to ustawić potrzebujemy zasadniczo dwóch punktów pomiarowych. Jednym punktem jest gwiazda G2V, natomiast drugim tło zdjęcia. Tło ma być czarne i takie dajemy offsety, a gwiazda biała i takie dajemy mnożniki. Oczywiście sprawa się komplikuje, jeśli w tle coś jest - jakaś mgławica czy pył. Wtedy nie powinna być ona czarna. Ale i na to są metody, jak choćby program eXcalibrator, który dokonuje pomiaru na podstawie wielu gwiazd ze zdjęcia i ich wskaźników barw z katalogu.

Teoretycznie robiąc raz kalibrację (obliczając te 6 współczynników) moglibyśmy ich używać już zawsze. Ale niestety, LP, Księżyc itp wprowadzają nam zmianę koloru i chcąc to skorygować musimy obliczać współczynniki na nowo.

Tak więc da się ustalić prawdziwy kolor dla całego zdjęcia w sposób całkowicie obiektywny.

Godzinę temu, trouvere napisał:

Rozumie się, że potencjalny autor "wie" lepiej jakie są te "prawdziwe" kolory

Potencjalny autor zazwyczaj nie bawi się w "matematyczną" kalibrację, bo nie potrzebuje otrzymać naukowo poprawnego zdjęcia. Zostawia sobie ten mały margines na interpretacje. Gdzie ten margines się kończy to już temat na oddzielną dyskusję... A część tego nie robi, bo im się nie chce, część nie potrafi, a część nawet o tym nie wie

Godzinę temu, trouvere napisał:

Na domiar złego potencjalni adepci (powiedzmy młodzi adepci) astronomii, zwiedzeni tymi podkolorowanymi "fotografiami" przeżywają głębokie rozczarowanie tym co widzą w swoim (czasem z wielkim trudem nabytym) teleskopie bo nikt im nie uświadomił, że te wszystkie "estetyczne" astro-fotogramy są w istocie wytworem fantazji czy wyobrażeń ich autora

Mój drogi, chyba nie rozumiesz różnicy w działaniu i możliwości naszego oka i matrycy światłoczułej  Otóż, nasze oczy nie potrafią robić wielominutowego naświetlania w celu rejestracji bardzo słabych obiektów, a do tego jedynymi działającymi przy słąbym świetle receptorami są pręciki, które widzą czarno - biało. Jakby tego było mało, to na środku oka nie mamy pręcików i w tym miejscu jesteśmy w nocy ślepi, oraz rozdzielczość obrazu powstającego z pręcików jest dość niska Dodajmy do tego maksymalny użyteczny rozmiar źrenicy wyjściowej równy średnicy źrenicy oka, co limituje nam możliwą jasność powierzchniową obrazu w teleskopie i mamy przepis na katastrofę   Tak więc obserwator wyposażony nawet w wielki teleskop nie jest w stanie zobaczyć tego, co zarejestruje fotograf. A to co fotograf zarejestrował to nie jest żaden wytwór jego fantazji. Gdyby ten obiekt był 1000x jaśniejszy, to wizualowiec mógłby bez trudu podziwiać pięknie nasycone kolorami obiekty pełne detali.

A to że ktoś po naoglądaniu się zdjęć w necie chce to samo zobaczyć w okularze nazywa się syndromem Hubblea, który jest szeroko znany na forach i bynajmniej nie jest winą astrofotografów.  Jest winą tego, że ten ktoś nie wie właśnie, jak działa oko i jak różni się od możliwości matrycy.

19 minut temu, Tayson napisał:

Co się stanie jak użyje filtrow do >f3 z obiektywem 200mm f2.8 lub nawet f2.0?

Z obiektywem prawdopodobnie nic. Chodzi tu o kąt stożka światła, jaki generuje optyka. W teleskopie jest to prosta zależność - masz stożek o podstawie wielkości lustra/soczewki i wysokości równej ogniskowej. I im większy kąt przy wierzchołku (przy kamerze), tym bardziej przesuwa się wykres transmisji względem normalnego. Czyli linia wodoru może "nie trafić" w pik transmisji filtra.

Ale obiektywy to dużo bardziej skomplikowane twory  I niekoniecznie (a raczej rzadko) kąt stożka światła na matrycy jest taki, jaki wynika ze światłosiły. W jasnych szkłach ten kąt jest wciąż mały. To dlatego, żeby np nie robić winietowania od komory matrycy. Dzięki temu jasny obiektyw powinien pracować ok z filtrami. A już taka RASA czy Hyperstar nie i tu potrzeba specjalnych filtrów.

Aparat na LV nie robi zdjęcia o takim samym czasie jak oryginalne zdjęcie, stąd różnica. A nie robi tego, bo chce pokazywać Ci zawsze płynny obraz, te 30 czy ileś tam minimalnie fps. Niestety, nie nikt nie myśli o astrofotografach...

7 minut temu, Behlur_Olderys napisał:

Biorąc pod uwagę sztuczność w ogóle całego procesu astrofotografii

To nie takie proste. Zgoda, proces obróbki astrofotografii jest "sztuczny". Jednakże to nie tak, że w tym momencie całkowicie tworzymy naszą "wymyśloną sztukę" dążąc do jakiegoś efektu, który wybieramy na podstawie tego, które zdjęcie nam się podobało w internecie i takie mamy wyobrażenie dla danego obiektu. Obiekty astro to nie są jakieś kwantowe twory, którym wygląd nadaje dopiero ich obrobienie. One mają swój prawdziwy wygląd. Możesz się o nim przekonać najprościej robiąc jednoklatkowca lustrzanką  Dane z kamery, czy zdjęcie po stackowaniu są dalekie od "rzeczywistego wyglądu obiektu", ale do tej rzeczywistości możemy dążyć. Np składając kolor z filtrów RGB możemy zrobić kalibrację kolorów na podstawie gwiazdy G2V - wtedy otrzymujemy najprawdziwszy kolor zdjęcia.

Cytat

Ale materiał ściągnięty z matrycy - to czysta fizyka, tego się nie oszuka.

Tak, to czysta fizyka, ale ten materiał to są jedynie dane, jeszcze nie zdjęcie. Musimy jakoś zmapować to, co widzi kamera na to, co widzi oko. I po części tym zajmuje się obróbka. Chodzi na przykład o relacje czasu naświetlania, gainu, głębokości studni, QE. Zdjęcie z kamery CCD wyświetlone "wprost" jest prawie czarne. Nasze monitory nie potrafią wyświetlić tylu odcieni szarości, oraz pokazać tak gigantycznych kontrastów, jakie widzi nasze oko i jakie występują na niebie. Musimy to zmapować. Jakoś wepchnąć te 16 czy więcej bitów po stackowaniu do marnych 8, które potrafimy pokazać oku. A jeśli mamy kamerę kolorową, to dochodzi jeszcze kwestia wzajemnej relacji QE poszczególnych kolorów i tego, jak ich wykres ma się do oka. Stąd kolorowa kamera nie wypluwa sama z siebie prawdziwych kolorów, trzeba jej "pomóc".