Jupiter

[Danijel]

Ja sam krenuo snimati Jupiter sa svojim fotićem Canon EOS 450D i programom EOS Camera Movie Record. Snimao sam filmiće po 7 minuta duljine jer sam vidio da tako radi jedan od mojih uzora (koje nikada neću moći dostići) Damian Peach. Naravno, nisam imao pojma da je to predugačko vrijeme snimanja, a kamoli za sve one trikove kod obrade koju mu omogućuju da snima 7 minutne filmiće. Zatim sam se susreo s nemogućnošću Registaxa da obrađuje video zapise veće od 2 GB. Pa mi se to sve kočilo, rušilo, blokiralo... Onda sam to provukao kroz AviStack i on je to prožvakao bez da je štucnuo.

No, drugi puta sam koristio astrokameru Astrolumina ALccd5L-IIc, snimao sam filmiće do 2 minute koji su se mogli provući kroz Registax, otkrio sam Wavelete i rezultat je bio puno bolji. Ima sva sila programa za te stvari i treba ih isprobavati, nekome bolje paše jedan, nekome drugi, a nije rijetkost da se koristi više njih koji rade isto ili slično pa daju osjetno bolje rezultate.

Kada sam ja počinjao s astronomijom bili su fotići s filmom i o ovakvim fotografijama nismo ni sanjali, a ni viđali ih na snimcima s velikih opservatorijama poput one na Mt. Palomaru recimo. Digitalna tehnika i računala su sasvim, ali sasvim promijenili svijet astronomije i astrofotografije koji smo do tada poznavali. Zato mi je dosta teško pohvatati sve te tehnike, naročito što nemam nikoga u svojoj blizini kod koga bih mogao otići da mi u stvarnosti pokaže kako se to radi pa sam osuđen na kopanje po Internetu u nadi da ću naći rješenje za neke banalne stvari, a kamoli napraviti nešto posebno dobro. No, zato me veseli kada vidim da ima ljudi koji to znaju raditi pa čak i volje objasniti kako to rade.

[Ralemasinac]

Profesionalizam da delu. Stvaka čast Sekula. Vlaiv hvala ti za objašnjenja... Znači mnogo nama amaterima Hvala još jednom.

[vlaiv]

Da, napredak tehnike je prosto fascinantan u ovom segmentu u odnosu na samo 10-20 godina pre.

Bas sam pre neki dan radio neke kalkulacije vezano za snimanje jupitera i skontao da smo na vec na granici mogucnosti cak i sa jednostavnim instrumentima.
Evo moje racunice ukratko, mozda nekom bude zanimljiv materijal za razmisljanje vezano za snimanje jupitera, a i sve kritike i sugestije su dobrodosle.

Naime radi se o balansu izmedju F-ratio, kvantne efikasnosti senzora, vremena ekspozicije, teorijske rezolucije teleskopa i naravno seeing-a.

(dosta elemenata racunice su aproksimacije i pretpostavke, i zbog toga valja posmatrati ovu racunicu kao vrlo okvirnu)

Poceo sam od sledece pretpostavke:
- Idealna sampling rezolucija za snimanje planeta je x3 u odnosu na resolving power teleskopa (to je empirijski podatak koji se najcesce srece na internetu, ja sam sa druge
strane sklon da verujem da se bolji rezultati pod odgovarajucim uslovima mogu dobiti i sa vecom rezolucijom, cak mislim i da sa odgovarajucim algoritmima moze da se prevazidje
teorijska rezolucija teleskopa uz pomoc odredjenih aspekata seeing-a i atmosferskih distorzija, u krajnjoj liniji efekti prelamanja svetlosti kroz atmosferu mogu delovati kao
socivo u odredjenim uslovima i povecati sliku koja stize do teleskopa)
- za primer sam uzeo trenutnu poziciju jupitera: cca 40" ugaoni diametar, cca -2.2 magnituda (uzevsi relativno dobru transparenciju neba)
- velicinu piksela na mom senzoru na QHY5L-IIc -3.75 um
- okvirnan fluks fotona koji sam pronasao na internetu - magnituda 0 - 1000000 fotona po 1cm kvadratni/s
- kombinovanu reflektivnu moc mog teleskopa od recimo 70% (centralna obstrukcija, 2 ogledala sa cca 90+% refleksivnosti i slicno)

Uzevsi prvu pretpostavku za moju kameru je idealan F18 za maksimum detalja, sto daje velicinu jupitera na snimku od 123 piksela sirine (sa mojim teleskopom od 130mm).
Za racunice je zgodan sledeci sajt, daje online kalkulatore za mnoge stvari (f-ratio, ccd sampling size i slicno): http://www.wilmslowastro.com/software/formulae.htm

Znaci da jupiter na snimku zauzima povrsinu od cca 11919 piksela.
Ako magnituda 0 proizvodi fluks od priblizno 1000000 fotona po 1cm kvadratnom u sekundi i iz formule za magnitudu mozemo da zakljucimo da jupiter sa magnitudom od -2.2
proizvodi cca 7585776 fotona po kvadratnom centimetru u sekundi.
Na teleskop precnika 130mm u tom slucaju pada cca 1009956562 fotona u sekundi. Odnosno efektivno 70% od toga bude fokusirano na senzor
sto ce reci: cca 706969593 fotona u sekundi.
Dalje se ti svi fotoni rasporedjuju (opet aproksimacija da je raspodela ravnomerna - tj uniformna) po pikselima kojih smo rekli da ima cca 11919.
Znaci da u sekundi na piksel padne cca 59314 fotona.
Kvantna efikasnost senzora u ovom slucaju je 50% - znaci bice registrovana polovina fotona odnosno cca 29657 fotona u sekundi po pikselu (u proseku).

Pri 100fps duzina ekspozicije je 10ms odnosno 1/100s sto znaci da u tom vremenskom intervalu imamo cca 296 fotona na senzoru.

Zakljucak racunice: frame rate preko 100fps u mom slucaju nije isplativ zato sto ce doci do smanjenja dinamickog opsega za nijanse cak pri idealnoj konverziji nivoa fotona
u sliku (pod uslovom da je slika 8 bita  odnosno 256 nijansi).

Cak mogu da kazem da ovu racunicu potvrdjuju i eksperimentalni podaci zato sto sam pri ekspoziciji od 20-30ms na histogramu radeci sa 12bit formatom kamere
primetio da se na senzoru nikad ne pojavljuje vise od 400-500 razlicitih vrednosti u frejmu.

Jos jedan interesantan zaljucak je da za "critical sampling" ili momenat kada se za datu optiku moze izvuci maksimum detalja (opet naglasavam da ja mislim da treba ici
u jos veci oversampling od x3) velicina teleskopa ne igra ulogu za duzinu ekspozicije (sto je i za ocekivati bitan je F ratio sto je za moju kameru F18).

Uh, nadam se da vas nisam smorio postom i da je dovoljno blizu temi (snimanje jupitera)

[Sekula]

Ja sam krenuo snimati Jupiter sa svojim fotićem Canon EOS 450D i programom EOS Camera Movie Record. Snimao sam filmiće po 7 minuta duljine jer sam vidio da tako radi jedan od mojih uzora (koje nikada neću moći dostići) Damian Peach. Naravno, nisam imao pojma da je to predugačko vrijeme snimanja, a kamoli za sve one trikove kod obrade koju mu omogućuju da snima 7 minutne filmiće. Zatim sam se susreo s nemogućnošću Registaxa da obrađuje video zapise veće od 2 GB. Pa mi se to sve kočilo, rušilo, blokiralo... Onda sam to provukao kroz AviStack i on je to prožvakao bez da je štucnuo.

No, drugi puta sam koristio astrokameru Astrolumina ALccd5L-IIc, snimao sam filmiće do 2 minute koji su se mogli provući kroz Registax, otkrio sam Wavelete i rezultat je bio puno bolji. Ima sva sila programa za te stvari i treba ih isprobavati, nekome bolje paše jedan, nekome drugi, a nije rijetkost da se koristi više njih koji rade isto ili slično pa daju osjetno bolje rezultate.

Kada sam ja počinjao s astronomijom bili su fotići s filmom i o ovakvim fotografijama nismo ni sanjali, a ni viđali ih na snimcima s velikih opservatorijama poput one na Mt. Palomaru recimo. Digitalna tehnika i računala su sasvim, ali sasvim promijenili svijet astronomije i astrofotografije koji smo do tada poznavali. Zato mi je dosta teško pohvatati sve te tehnike, naročito što nemam nikoga u svojoj blizini kod koga bih mogao otići da mi u stvarnosti pokaže kako se to radi pa sam osuđen na kopanje po Internetu u nadi da ću naći rješenje za neke banalne stvari, a kamoli napraviti nešto posebno dobro. No, zato me veseli kada vidim da ima ljudi koji to znaju raditi pa čak i volje objasniti kako to rade.

Od naseg proizvodjaca i supplayer-a iz ASA smo dobili preporuku da radimo obradu sa AstroStakkert softverom upravo zbog poboljsanog algoritma. Dobitna kombinacija je svakako monohromatska kamera po tri kanala posebno sa sto vecim fps. Jako dobro je imati sto vise frejmova za optimalno kratki interval. Iskreno, ja cisto sumnjam da softver moze da nesto bog zna kako ispegla predugacak materijal gde se onda vidi problem sa promenama u atmosferi. On prosto to radi na nivou nekakve matematicke interpolacije snimaka. Daleko je bolje ne dozvoliti fizicki da se to desi i da se onda oprezno navedeno izbegne optimalno tempiranim video sekvencama. Na problem detalja naravno da dodatno utice i seeing koji ako je losiji jedino moze da se koliko toliko anulira sa sto vecim frame rateom.

Profesionalizam da delu. Stvaka čast Sekula. Vlaiv hvala ti za objašnjenja... Znači mnogo nama amaterima Hvala još jednom.

Rale, samo napred pa da uradis mnogo vise nego ja! 

...
Naime radi se o balansu izmedju F-ratio, kvantne efikasnosti senzora, vremena ekspozicije, teorijske rezolucije teleskopa i naravno seeing-a.
...

Dragi prijatelju, naveo si samu srz za ovakvu vrstu snimanja. Elem, ako f ide iznad 10 onda se tu svakako trazi kamera sa vecim frame rate. I taj frame rate treba da bude 100 da bi se pojurio kvalitet. Upravo iz razloga sto je problem sa prikupljenom svetloscu i dejstvom seeinga izrazeniji. Expozicija svakako treba da bude optimalna i da fizicke osobine i dejstva u atmosferi objekta ne budu takve da dodatno uticu na rezoluciju.

[vlaiv]

... Dobitna kombinacija je svakako monohromatska kamera po tri kanala posebno sa sto vecim fps. ...

Pa nisam bas sasvim siguran da kolor kamera ne moze isto tako efikasno da se upotrebi. Cinjenica jeste da bayer matrica efektivno smanjuje rezoluciju senzora za crvenu i plavu na 1/4 i za zelenu
na 1/2 rezolucije i da se debayering-om i interpolacijom smanjuje rezolucija snimka. U poslednje vreme se bas nesto bavim tom problematikom i zakljucio sam da uopste ne mora biti tako. Kao sto je razvijen drizzle algoritam za undersampled (ja se izvinjavam na upotrebi engleskih termina u svojim postovima, al mi je nekako jednostavnije upotrebiti originalne termine) snimke, tako je moguce uraditi sledece: Prilikom snimanja planeta pustiti malu kolicinu drift-a na snimku tako da odredjeni frejmovi odredjen piksel snimaju crvenom, plavom ili zelenom komponentom bayer matrice. Ne debayerovati video prilikom stackinga nego napisati poseban algoritam za stacking koji ce alignment uraditi na debayerovanom videu a sam stacking odraditi na raw videu gde ce posebne komponente kanala (crveni, plavi ili zeleni) uzimati samo sa onih frejmova iz stacka gde se dati piksel poklapa u bayer matrici sa odgovarajucom komponentom.

Primer:

pretpostavka je da imamo GRBG bayer matricu (radi i sa bilo kojim drugim rasporedom). i da imamo sledeca 3 frejma (x predstavlja objekat 0 predstavlja "crno nebo" - radi jednostavnosti razumvevanja):

Matrica:

GRGR
BGBG
GRGR
BGBG

Frejmovi:

0000  0000  0XX0
0XX0  00XX  0XX0
0XX0  00XX  0000
0000  0000  0000

(frejm 1 - original pozicija, frejm 2 drift x: +1 piksel, y: 0 piksela, frejm 2 drift x: 0 piksela, y: -1piksel)

Stavkovanjem ova tri frejma za objekat se dobija sledeca informacija

(GBR), (BGG),
(RGG), (GRB)

Znaci iz samo 3 frejma smo dobili sledecu situaciju 2 od 4 piksela imaju punu rezoluciju (tj sve 3 komponente u RGB kanalima) dok 2 piksela imaju punu B i G odnosno R i G rezoluciju
pikseli sa punom rezolucijom nemaju povecanje SNR-a dok pikseli sa delimicnim rezolucijama imaju povecanje SNR-a po zelenoj komponenti.

Kada se uzme dovoljno frejmova (ne samo 3, ovo je bilo samo za objasnjenje) radi se konverzija poboljsanja SNR-a u poboljsanje rezolucije (ili gubitka rezolucije) zbog bayer matrice.

Ako sad uzmemo sledecu cinjenicu - za monohromatski senzor za recimo 3 minuta snimanja - po komponenti zapravo otpada 1 minut. Znaci da je 1/3 broja snimaka od ukupnog
snimka odlazi na komponente ne na povecanje SNR-a, a gornjim postupkom za dovoljan broj frejmova dolazimo do slicnog zakljucka za broj frejmova >> 3. Pitanje je
sta je dobitna kombinacija. Filter wheel + 3 filtera + mono kamera ili Color kamera i pametan algoritam za stackovanje.

[Sekula]

@vlaiv

Color debayer matrica provereno smanjuje rezoluciju snimka kao i nivo detalja u vidu primljene svetlosti. Ja ne kazem da je colour kamera promasaj, ali svakako je bolji rezultat sa monohromatskom kamerom koja dobije vise detalja sa irgb filterima. A to svakako da vazi za bilo kakvo planetarno snimanje. Za deep sky vec i da ne pominjemo.

[vlaiv]

Da, to je konvencionalno misljenje. Upravo sam objasnio kako se to moze izbeci i za planetarno snimanje pod odredjenim uslovima (veliki broj frejmova, odgovarajuci algoritam)
performanse kolor kamere dovesti na isti nivo kao i mono kamere + filteri.

Mono + filter = color + bayer-filter kada se posmatra na nivou jednog piksela. Umesto da se filter menja na 1 minut, driftom u snimku se menja filter od frejma do frejma na istom
pikselu koji je i u mono i kolor kameri (ispod bayer filtera). Jedino sto se moze dovesti u pitanje jeste propusna moc i opseg filtera u slucaju globalnog ili per piksel filtera (bayer matrice).
Ali nigde nisam video da bayer matrica bas mora da bude rgb - to smo nasledili iz consumer elektronike. Umesto bayer grbg ili nekog slicnog formata moze se uzet lrgb bayer matrica
ili cak na vecoj kolicini piksela i druge kombinacije filtera par narrow band + standardni lrgb.

[Sekula]

Da, to je konvencionalno misljenje. Upravo sam objasnio kako se to moze izbeci i za planetarno snimanje pod odredjenim uslovima (veliki broj frejmova, odgovarajuci algoritam)
performanse kolor kamere dovesti na isti nivo kao i mono kamere + filteri.

Mono + filter = color + bayer-filter kada se posmatra na nivou jednog piksela. Umesto da se filter menja na 1 minut, driftom u snimku se menja filter od frejma do frejma na istom
pikselu koji je i u mono i kolor kameri (ispod bayer filtera). Jedino sto se moze dovesti u pitanje jeste propusna moc i opseg filtera u slucaju globalnog ili per piksel filtera (bayer matrice).
Ali nigde nisam video da bayer matrica bas mora da bude rgb - to smo nasledili iz consumer elektronike. Umesto bayer grbg ili nekog slicnog formata moze se uzet lrgb bayer matrica
ili cak na vecoj kolicini piksela i druge kombinacije filtera par narrow band + standardni lrgb.

Mi jos uvek imamo problem sa hvatanjem svetla u bilo kojoj colour varijanti kamera u odnosu na monohromatske. I dalje je u astronomiji rad sa IRGB filterima i monohromatskom kamerom najbolja varijanta u pogledu uhvacenog svetla, kolor obrade problema sa  seeingom kao i sa vecim f-ovima.

Dobitna kombinacija je svakako ovo prvo. Pre svega hardwer pa onda tek software. Sto se debuyer maske tice jasno je vrlo objasnjeno i vizuelno sta se desava i nivo detalja koji se zapisuje na chipu. Prilazem svoje predavanje na drugu temu ali sa istom pricom, a ona vazi i za Jupiter. Obratiti paznju na slajdove od 6 do 9. Ako uspes da konstruises drugaciji colour model u odnosu na monohromatski chip i dobacis na njegov nivo, to bi bilo sjajno.

[johnny984]

Uh Sekula, fenomenalna fotka kao i animacija, kapa dole.

Takođe jako zanimljiva diskusija i puuuno korisnih informacija, treba nam više toga ovde.

Evo i mog skromnog doprinosa, preve 2: EOS + barlow x 2 + Dob 200/1200, druge 2: compact + GL 6mm + barlow x 2 + Dob 200/1200

Prve 2: tranzit Evrope 8-Apr-15
Druge 2: snimane noćas 9-Apr-15

PIPP + RegiStax + PS, oko 500 sličica u finalnim stackovima

[vlaiv]

Da, o tome i pricam bas upravo. (pogledao sam navedeni slideshow)

Hajde mozda nisam bio jasan, pa da probam da pojasnim.

Znaci konkretno ne pricam o generalnom CCD imaging-u (slikanju). Takodje ne pricam o pojedinacnim fotografijama duge ekspozicije. Pricam o planetarnom snimanju lucky shot metodom (video snimanje, selekcija najboljih frejmova i stacking).

Postoji bitna razlika izmedju stackinga za planetarno snimanje ovom metodom i stackinga za fotografije duge ekspozicije. Klasican stacking duge ekspozicije sluzi primarno za poboljsanje SNR-a odnosno smanjenje suma na konacnom snimku (ne povecanje signala kako se moze u prvi momenat uciniti, jer se ljudima ucini da je 6x 10 minuta isto sto i 60minuta ekspozicije, ali matematika kaze da nije tako).

Stacking kod planetarnog snimanja ima dvojaku ulogu. 1. povecanje SNR-a. 2. Precizno odredjivanje geometrije detalja (pa i same planete) koja se na pojedinacnim snimcima kratke ekspozicije deformise zbog atmosferskih uticaja. Buduci da tokom duzeg perioda pozicija detalja ili neke tacke na objektu osciluje (cini mi se normalnom raspodelom) oko centra gde se inace nalazi, stackingom mozemo odrediti gde je zapravo geometrijsko mesto tog detalja. To se u planetarnom stackingu zove kreiranje referentnog rejma (onog koji najpribliznije izgleda kao snimani objekat i koji odredjuje geometrijsku transformaciju bilo kog drugog frejma prilikom slaganja na stack).

Da se vratimo na algoritam i pojasnjenje. Znaci uslovi o kojima pricam su
1. Snimanje velikog broja kratkih ekspozicija (planetarno snimanje)
2. Monohromatski senzor + RGB/LRGB filteri (ne narrowband filteri kao h-alfa, oIII ili astro filteri)
3. Planetarna metoda stackinga.

Ono oko cega treba da se slozimo prvo (mozda tu nastaje problem). Je sledece:
1. Mono senzor i Color senzor - su identicni sto se tice samog senzora tj pojedinacnih piksela (ako se zanemare filteri preko toga). Imaju istu kvantnu efikasnost (naravno za isti cmos / ccd, razlika je samo u color i mono varijanti). Znaci ovde pricamo o pikselu na mono i pikselku na color kameri koji se nalazi ispod bayer matrice.
2. Bayer matrica je opticki wideband filter kao sto su i redovni filteri - filteri i karakterise ih spektralni odziv.
3. Za odgovarajucu bayer matricu postoje odgovarajuci filteri koji su ekvivalentni - ekvivalencija u ovom slucaju se odnosi na i iskljucivo na spektralni odziv. (znaci postoji crveni filter istog spektralnog odziva kao i crvena komponenta bayer matrice isto za plavi i isto za zeleni).

Razlika medjutim postoji u sledecem: Mono kamera moze da se koristi sa bilo kojim filterom koji se "prisrafi" ispred senzora. Kod color kamere za svaki piksel je "prisrafljen" jedan fiksni filter koji se ne moze menjati. Takodje treba reci da svaki piksel ima svoj filter i da neki pikseli imaju isti filter a neki razlicit - kod color senzora. Kod monohromatskog svi pikseli imaju isti filter - onaj koji je zasrafljen na nos kamere.

A sada za objasnjenje samog algoritma i zasto je rezultat isti pod gore navedenim uslovima.

Neka se objekat sastoji iz 2 detalja. Detalj A i detalj b.
A i b su takvi da na slici proizvode sliku velicine 1x1 piksel i svaki od detalja proizvodi spram svetlosti koju reflektuje odredjene vrednosti za R, G i B deo spektra

Neka imamo 3 piksela na senzoru (znaci pokusavam uprostiti maksimalno), i dve kamere. Jedna je mono i druga je color. Imaju isti - identican senzor - znaci da su pikseli isti / iste velicine / iste
kvantne efikasnosti. Jedina razlika je sto mono nema bayer filter na sebi, a color na prvom pikselu ima crveni filter "prisrafljen", na drugom zeleni a na trecem plavi.

Prvo snimamo mono kamerom 1000 frejmova sa crvenim filterom.
Kod mono kamere nije bitno na koji piksel pada svetlo detalja A a na koji svetlo detalja B.
Rezultat: 1000 semplova (piksel vrednosti) sa crvenim filterom detalja A i 1000 vrednosti sa crvenim filterom detalja B
Zatim ponavljamo snimanje sa 1000 frejmova sa zelenim i plavim filterom.

Ukupan rezultat: 1000 semplova A u RGB (Svaki po 1000 semplova) i 1000 semplova B u RGB (takodje svaka komponenta po 1000 sampleova).

Sada snimamo sa color kamerom, ali snimanje vrsimo drugacije. Snimamo total 3000 frejmova. U svakom iducem frejmu pomerimo detalje A i B
tako da padaju na drugi piksel u odnosu na prethodni frejm.
Rezultat: za detalj A ce 1/3 frejmova biti uhvacena "crvenim" pikselom, 1/3 "plavim" i 1/3 "zelenim". Isto vazi i za detalj B.
- odnosno 1000 semplova A u RGB (svaki po 1/3 od 3000) i 1000 semplova B u RGB (takodje 1/3 za zeleni od 3000, 1/3 za plavi).

Rezultati snimanja pod uslovom da filteri i bayer matrica imaju isti spektralni odziv i da su pikseli identicni (isti cmos ili ccd) i da se uzima veliki broj snimaka i da se prilikom
snimanja sa color senzorom vodi racuna da detalji A i B ne budu uvek snimani istim pikselom nego 1/3 vremena jednim, 1/3 vremena drugim i 1/3 vremena trecim pikselom
su identicni - ista kolicina semplova za oba detalja u RGB spektru.

To je ono sto je moje tvrdjenje. Pri odgovarajucim uslovima efikasnost rezolucije mono + filteri, color + rgb bayer i gore navedeno je identicna.
(ovi uslovi nisu uopste teorijski nego sasvim realni u praksi, jer se planete i inace sad tako snimaju - jedini problem jeste sto se radi debayering pre stackinga
dok sa mojim predlogom uopste nema debayeringa, nego samo odgovarajuca vrsta stackinga).

[Sekula]

@vlaiv

Pazljivo sma proucio tvoje razmatranje. Ali ja i dalje smatram da prosto colour kamera ima razlicito pobudjenje pixela u odnosu na to koje mikrosocivo R,G ili B stoji ispred njega zbog debuyer matrice. Elem, samim tim se to oseti na nivou zabelezavanja svetlosnog zapisa koji se dobija od Jupitera npr. Manji gubitak u zapisu se dobija ako se filter postavlja ispred celog chipa. Kombinovanjem po kanalima se dolazi do istog.
Sto se tice predloga, mozda ne bi bilo lose da se obratis autorima softvera za stacking posto su svi ovi projekti nastali u astronomskoj zajednici:

http://www.astronomie.be/registax/
http://www.astrostack.com/
http://www.autostakkert.com/

Iz razloga tog sto ce programeri ovog softvera lako moci da upare tvoje predloge sa algoritmima u cijoj izradi su ucestvovali i da ti odgovore da li ovaj predlog moze da drzi vodu za dalju promenu strategije snimanja kao i novih metodologija u izradi softvera za obradu.

Na mojoj listi FB prijatelja se nalaze recimo i Damian Peach kao i Pavel Presnyakov. Ovaj drugi je jedan od koautora Registaxa. Svi oni su i astronomi. Predlazem da i njih kontaktiras u smislu prethodno navedenog.

@Johnny
Samo napred prijatelju, super!

[vlaiv]

Upravo sam pisao Emilu Kraaikampu (autoru autostakkert-a) sa predlogom za ukljucenje ovog algoritma u autostakkert2

Videcemo da li ce biti zainteresovan. Ja sam u svakom slucaju zainteresovan za pravljenje svog programa za stacking videa, pa
ako algoritam i ne dospe u autostakkert moguce je da cu ja implementirati jednu varijantu tog algoritma (zajedno sa jos
nekim dodacima kao sto su color space transformacije spram spektralnog odziva filter-a i slicne stvari o kojima sam razmisljao).

U svakom slucaju korisne informacije. Da ne zatrpavamo ovaj thread vise sa off-topicom, razvoj dogadjaja oko algoritma cu
postovati u poseban thread u okviru astrofotografije.

[Sekula]

Upravo sam pisao Emilu Kraaikampu (autoru autostakkert-a) sa predlogom za ukljucenje ovog algoritma u autostakkert2

Videcemo da li ce biti zainteresovan. Ja sam u svakom slucaju zainteresovan za pravljenje svog programa za stacking videa, pa
ako algoritam i ne dospe u autostakkert moguce je da cu ja implementirati jednu varijantu tog algoritma (zajedno sa jos
nekim dodacima kao sto su color space transformacije spram spektralnog odziva filter-a i slicne stvari o kojima sam razmisljao).

U svakom slucaju korisne informacije. Da ne zatrpavamo ovaj thread vise sa off-topicom, razvoj dogadjaja oko algoritma cu
postovati u poseban thread u okviru astrofotografije.

Mislim da je to jako dobro sto si se javio i podrzavam da se javis i ostalima. Ni jedan od ovih softvera nije komercijalan i maltene su na nekom open source nivou. Dobro je da cujes i misljenje ljudi koji su ovu tematiku prethodno ozbiljno morali da prezvakaju da bi se uopste referentno primili u astronomskoj zajednici.

Inace, prilazem upravo snimak koji je uradio P. Keller glavni inzenjer iz ASA koji je jedan od suvlasnika teleskopa u Chileu koji su sagradili i postavili i ciji su vlasnici sa nekoliko astronoma amatera zajedno (i Emilu Kraaikamp je jedan od suvlasnika i korisnika koliko znam, njegova Venera je fenomenalna sa tog teleskopa). Razlog tome je upravo nacin na koji je snimano, a sto navodim kao deo iz licne prepiske:

"...autostakkert. Was a lot of work because every image was made from a 20s
Video in IRGB.
Here is another one with Ganimed.
Also moon is really cool.
We have the webcam in fixed position appr. 65mm out of optical axis so
the main camera is always working and not blocked. And we have some
(little) aberration where, so we reach not the full capacity of the
telescope.
But still I think its very good."

https://www.youtube.com/watch?v=QXXLA94mTSY

[Luger]

Moj mali doprinos na ovoj temi. Snimak je napravljen u pauzama izmedju snimanja za primarne astronomske projekte i programe. Seeing nije bio dobar (preko 2", najpre zbog uticaja jakog vetra), pa je izvuceno koliko je moguce.



Podaci o snimanju:

objekat: Jupiter
datum: 3. april 2015.
vreme: 21:15 UT
lokacija: AS Vidojevica, Srbija
kamera: DFK21AU04
format: 640x480, Y800, raw color
broj frejmova: 5947
exp: 3 minuta
obrada: AutoStakkert, Registax, PhotoShop
instrument: Cassegrain 600/6000 mm
nacin: primarni fokus, bez barlova

Sekula, cestitke, odlican posao!
I sva diskusija oko softvera za stekiranje mi je privukla paznju, ima sta da se nauci.

[johnny984]

Još 3 pokušaja.

EOS 600d + dob 200/1200 + barlow x 2

Prva i druga sa dodatnim zumom x3 a teća x5

Glavni problem između ostalog je aberacija lošeg ahromatskog barlowa 

Obrada: PIPP + Registax + PS