Techniky Astrofotografie, zpracování snímků

[Konihlav]

v MaxImu je podle me zasadni (a celkove) delat master dark metodou median nevim proc tam maji average jako default nastaveni, to je podle me pitomost... DSS nejspis ignoruje extremy.

[honza.ho]

v MaxImu je podle me zasadni (a celkove) delat master dark metodou median nevim proc tam maji average jako default nastaveni, to je podle me pitomost... DSS nejspis ignoruje extremy.Kdysi jsem tuším zkoušel nebo někde vyčetl, že average zanáší nejméně šumu. Asi u RG.

[Konihlav]

no jo, average dava nejlepsi pomer S/N, ale za predpokladu, ze jednotlive snimky jsou maximalne kvalitne zkalibrovany! Takze delat average na dark s kosmiky, hotpixely a jinym bordelem je blbost

[honza.ho]

no jo, average dava nejlepsi pomer S/N, ale za predpokladu, ze jednotlive snimky jsou maximalne kvalitne zkalibrovany! Takze delat average na dark s kosmiky, hotpixely a jinym bordelem je blbost :-)Mno tak kde je potom ale rozdíl v algoritmu. DSS s tím nemá problém

[Konihlav]

DSS urcite ignoruje extremni hodnoty, tudiz to neni 100% cisty AVG ale neco mezi AVG a MED

edit: no a pokud ne, tak Ti tam ty cerny tecky nevznikaji proto, ze mas zapnuty "upravy vzhledu", kde to black a white pixely odstrani...

[MP]

Panove, uz jsme na to narazili u MRAWu, tak jeste jednou a polopaticteji : To, ze je nekde napsano "average", jeste neznamena, ze jde o ARITMETICKY prumer, o jakem se uci na zakladni skole. Existuji desitky matematickych postupu na vypocet prumerne hodnoty a pri zpracovani dat, zatizenych statistickymi chybami, urcite nikdo soudny aritmeticky prumer nepouzije. Delam takove veci dvacet let (s merenymi daty z jadernych reaktoru) a s aritmetickym prumerem jsem se skutecne jeste nesetkal. Takze jde o to, jakou metodu si autor zvolil, jak si ji upravil a doladil na realnych datech - je v tom vzdycky trocha magie, i u tech jadernych reaktoru. Nekdy se presny postup doctete, nekdy ho autor taji. V pripade MRAWu je metoda jednoducha a ucinna a mate k dispozici zdrojovy kod.

[MMys]

V MaxIm DL musíš použít ještě funkci "remove bad pixels", udělat si v tom nástroji pro svoji kameru mapu saturovaných hotpixelů (nejlépe pro nejdelší expzoici, kterou používáš), a po odečtení DF pak pomocí téhle mapy interpolovat ty hotpixely z okolních bodů.

Jinak odečtením saturovaného pixelu vždy vznikne nula - černá tečka.

[MP]

Jinak, kdyz uz jsem se trochu dotkl teorie, dovolte mi uvest priklad "ze zivota", tedy ze zpracovani pomerne maleho souboru dat, zatizeneho relativne velkymi statistickymi chybami (vezmu trochu extremni hodnoty, aby to bylo videt - je to priklad).

Mejme darkframy ve 12bitovem formatu, ktere prumerujeme do 16bitoveho formatu. Dejme tomu, ze bezna odchylka pixelu se zmenou teploty behem foceni je kolem 2 ADU, tedy v 16bitovem formatu hodnota 32. A dejme tomu, ze zhruba stejne velky je nahodny rozptyl hodnot pro kazdy pixel - tedy ze nahodna odchylka muze vykompenzovat (nebo zdvojnasobit) tu systematickou odchylku. A ted si predstavme, ze v 5 darkframech dostaneme pro jeden pixel hodnoty treba :
128, 128, 128, 160, 160
Vidime, ze median je 128 a aritmeticky prumer (zaokrouhleno) 141.

A ted pocitejme s tim, ze light snimek bude zatizeny presne stejnymi chybami. Kdyz od nich odecteme median, tak ve snimcich s hodnotou temneho proudu 128 dostaneme nulu, ale vetsina snimku bude mit temny proud nekde mezi 128 a 160, takze nam tam neco zbyde. Kdyz pouzijeme aritmeticky prumer, tak u snimku s temnym proudem 128 dostaneme odchylku -13, ve snimcich s temnym proudem 160 odchylku +19 a po slozeni snimku se ty kladne a zaporne odchylky vykompenzuji. Takze jednoznacne dostaneme lepsi vysledek pri pouziti aritmetickeho prumeru.

Na druhou stranu muzeme mit, vinou tech statistickych odchylek, treba hodnoty
128 128 144 192 192
kde bude median 144 a aritmeticky prumer 157. Tam da presnejsi vysledky median, ale chyba pri pouziti aritmetickeho prumeru bude mensi, nez pri pouziti medianu v predchozim pripade.

Zkratka dat je malo a neni jednoduche na ne napasovat nejake rozdeleni a z nej spocitat nejpravdepodobnejsi hodnotu (to by bylo optimalni). Takze nezbyva, nez kouzlit, testovat realna data a vymyslet metodu, ktera udela zbytecne velkou chybu v co nejmensim poctu pripadu.

[Sasa3]

Ono se da relativne snadno dopocitat, kolik dark a master bias snimku je potreba. Kazda korekce samozrejme zanasi do vysledneho snimku dalsi sum. Zakladni pravidlo je, aby vneseny sum byl vyrazne mensi nez sum na opravovanem snimku, ktery je vetsinou dan pozadim oblohy. Pokud bude 5-10x mensi, nebude zvyseni sumu prakticky patrne.

[MP]

Ono kdyby slo o sum, ktery ma statisticky charakter, bylo by to jednoduche. Ale ono jde hlavne o temne proudy (systematicke odchylky) na ktere je namodulovany ten statisticky sum. A ty dva typy odchylek by se mely oddelit skladanim darkframu - statisticky sum snizit a zbyle systematicke odchylky odecist. Jenze tu mame dva zakladni problemy :
1. I ty systematicke odchylky nejsou konstantni, meni se s teplotou chipu, teplota chipu se meni nejen s teplotou okoli, ale i zahrivanim behem expozic a chladnutim mezi nimi apod. To znevyhodnuje vetsi mnozstvi darkframu - cim dele je fotime, tim vic se ty posledni budou lisit od light snimku.
2. Vetsi systematicke odchylky nejsou linearni a nemuzeme je odecitat. Moc zalezi na tom, jak urcime hranici "hotpixelu", kde vzdame korekci pomoci darkframe a proste interpolujeme z okoli. Kdyz moc vysoko, zustanou stopy po hotpixelech (ne cerne nebo bile, ale proste je tam rozdil proti okoli), kdyz moc nizko, ztratime nektere detaily prilis castym pouzitim interpolace (pripadne interpolaci v "nevhodnych" mistech vytvorime artefakty).

[Ross]

Mel bych dotaz.
Pouzivate nejaky program pro vyber nejlepsich framu pri snimani mesice nebo vybirate snimky rucne?Ja jsem vybiral rucne z jednoho videa (asi 4000 framu) a zabralo mi to asi 3 hodiny.Vim, ze na planety se da pouzit PCFE, ktery obraz orizne a seradi snimky podle kvality.Ale na mesic jsem to nemohl pouzit, protoze jsem chtel zachovat cele pole 640x480 a PCFE to vzdycky oreze.Tim padem mi orezal i casti, ktere jsem chtel zachovat, protoze nebyly vzdy uprostred snimku.
Tak by me zajimalo, jestli se da vyber nejkvalitnejsich framu nejak urychlit.

[MMys]

Registax umí výběr podle ostrosti a podobnosti s referenčním snímkem až v oblasti 512x512 pixelů. Ale problém je jiný, u snímků se širším zorným polem je každá oblast snímku poškozena a seeingem zdeformována jinak, takže snímky na sebe stejně moc nepasují.

Od toho je v Registaxu 5 tzv. multipoint alignment, který z části eliminuje alespoň posuny odpovídajících si částí snímků vůči sobě.

Nic lepšího, dotaženého z uživatelského hlediska do srozumitelné podoby, neznám.

Ale doporučuji nejprve prostudovat princip funkce a významy jednotlivých kroků a voleb. Ten SW není zrovna triviální.

[Ross]

Zkusim si s tim teda jeste jednou pohrat v registaxu.
Nez jsem zacal snimat kamerou jsem si myslel, ze pole 640x480 je dost male na to aby byly videt rozdily zpusobene seeingem, ale mas pravdu, taky jsem si uz toho vsiml.
S tim multibodovym vyberem nemam bohuzel dobre zkusenosti.Vzdycky kdyz jsem to zkousel takto delat, mi z toho vylezl uplne rozhazeny nepouzitelny vysledek.Asi budu muset najit k tomu nejaky navod jak v tomto pripade postupovat.
Dik.

[MMys]

Mě multipoint funguje dobře, viz třeba http://hvbo.cz/foto_astronomy_cz/Hi_res ... 4_2009.jpg

Body pro multipoint vybírám ručně, většinou výrazné objekty na povrchu. A nezapomenout nastavit funkci prolnutí segmentů (feather) tak aspoň na 5-10 pixelů. Jinak při doostření vylezou spoje jednotlivých oblastí.

[Ross]

Prave se tady s tim trapim.Funkci feather mam zapnutou, ale at nastavim jakekoli hodnoty, tak porad ve vysledku ty spoje vidim.Proste zatim se mi porad nedari dostat obstojny vysledek pri multipointu.
Tvuj mesic je naprosto paradni.Takhle nejak bych chtel udelat mozaiku v budoucnu.Nejdriv ale musim nasbirat potrebna data a taky vyresit zpracovani.