Astronomické fórum

Plně automaticky asi ne, PixInsight není SW primárně na astrometrii. Jedině zjistit souřadnice v pixelech a dopočítat. Ale to bych si snad raději vzal jiný SW.

Vím, že je to asi dotaz hodný naprostého začátečníka, ale nedá mi to... Když použiju ABE nebo DBE, strašně mi v obraze vzroste šum, i když úroveň pozadí zůstane úplně stejná (kolem 0,210 pro oba). Čím to je? Dá se tomu nějak zabránit? Oba náhledy jsou stretchlé na stejnou úroveň, vlevo před a v pravo po extrakci pozadí.
edit: zajímavé je, že když se pokusím udělat ABE/DBE až po strechnutí obrazu, šum neroste.

Ahoj.

To se ti jenom zdá. Je to tím, že když jsi odečetl pozadí a vyrovnal jej, tak strečnutí ve stínech je pak mnohem větší. (Už na první pohled jsou hvězdy větší!) - pokud nevěříš, zkus analýzu šumu.

Díky tomu to taky po strečnutí už není vidět. Já mám podobný problém - když snížím šum na lineárních datech a pak udělám MS, tak výsledek je úplně jiný, než když udělám MS rovnou.

Díky!
A rovnou další dotazy:
1) pokud mám v obraze náznaky IFN (bohužel jenom malinko), jak zabráním tomu, aby mi je DBE úplně nezrušilo? Tady například jsou v obraze jak nějaké zbývající fleky od gradientů, tak slabě viditelné IFN.
2) je normální, aby local normalization pro 600 zaregistrovaných obrázků zabrala 3,5 hodiny? (už nikdy nebudu flákat minutové expozice... počítám tu normalizaci na třech PC zároveň, abych to dnes alespoň složil )

Aby sis nezlikvidoval jemné struktury v pozadí, je nutné u DBE nastavit co nejvyšší vyhlazení (Smoothing factor). A prohlédnout si vygenerované pozadí, musí být hladké, nesmějí v něm být žádné podezřelé příliš ostré struktury.

A nebo udělat poctivě flaty a DBE vůbec nepoužívat (ale to ej v našich podmínkách asi sci-fi, protože tam budou stejně jasové gradienty od nehomogenit oblohy a okolního osvětlení).

Lokální normalizace je časově složitá úloha, protože funguje na principu waveletové dekompozice obrazu, což je výpočetně opravdu masakr. U desetiminutových subexpozic mě to nijak neomezuje, ale minutové, to musí být fakt extrém. Já bych na LRGB tu ASI-nu používal v režimu maximálního dynamického rozsahu. A expozice natáhl na únosné maximum (podle mě tak 5minut). Nemá smysl se okrádet o dynamiku vyšším ziskem a kompenzovat to skládáním více krátkých expozic. Jiná situace může být u úzkopásma, tam se vyplatí minimalizovat četcí šum použitím vyššího zisku, ale tam zase můžeš dělat dlouhé expozice protože je málo světla.

jediné opodstatnění pro vysoký zisk a krátké expozice má tzv. Lucky Imaging technika - prostě když máš dlouhé ohnisko a obraz často poškozený seeingem, můžeš exktrémně zkrátit expozice a doufat, že vybereš ze sady snímky málo poškozené seeingem, a pouze ty složíš. Ale tohle při tvém ohnisku nemá smysl.

Díky za rady. Ted budu doufat, že jsem to DBE měl udělané dobře, když jsem jím normalizoval celou tu nálož snímků, nerad bych to počítal zase celé znova Je ten smoothing faktor důležitý pro zachování IFN už ve fázi přípravy referenčního snímku pro lokální norm., nebo až potom, když budu DBE dělat na ostro na nové složenině?

Tohle jsem celé naflákal s unity nastavením (gain 139),kdy je maximální expozice bez přepalů pro LRGB cca 1min. Ale po téhle zkušenosti už to víckrát neudělám a LRGB budu fotit na gain 0 a expozici 3-5 minut.

Pokud už sis ty IFN zlikvidoval tom referenčním snímku pro lokální normalizaci, tak ti je to velkou měrou potlačí i v jednotlivých normalizovaných snímcích.

Já bych to snad klidně složil bez té lokální normalizace. Pokud v tom obraze nejsou nějaké výrazné stěhující se nehomogenity přes celou sadu snímků, tak přínos k výslednému šumu bude pár procent. Ale na rozhodnutí bych musel vidět ta data.

Kde jsi to vlastně fotil ? Myslím lokalitu a stav oblohy. A jaký je celkový expoziční čas, těch 600 x 1min. - tedy 10h ?

Ony zrovna v tomhle poli IFN moc vrazné nejsou. Výraznější jsou až o kus vedle, a víc vyniknou na širokoúhlejším snímku.
Máš podobný záběr jako já, a i časy jsou velmi zhruba srovnatelné (když nepočítám tu H-alfu). A moc IFN tam nemám. Porovnej:

http://hvbo.cz/index.php?id=m81-a-m82&lang=cz

MMys píše: Ony zrovna v tomhle poli IFN moc vrazné nejsou. Výraznější jsou až o kus vedle, a víc vyniknou na širokoúhlejším snímku.

Nějaké tam jsou - ale chce to lepší oblohu. Tohle jsou 3h...

Asi ten local normalization nechápu... Po třech hodinách se konečně spočítaly normalizační data, tak jsem to ráno dal složit, PĚT hodin čekal s nefunkčním počítačem, protože procesor jel na 100% a nešlo ani zapnout internet... (a to mám i-7 a 16GB RAM) a pak mi to vyhodilo "instance failed" a konec. Žádná fotka a spousta hodin v háji. Jediný, co se stalo, že v místnosti stoupla teplota o 1,5°C

Na tu normalizci se vybodni, u těchhle dat to moc nemá smysl. Zkus dofotit FF a znova to zkalibrovat a pak složit a doladit pomocí DBE. Nic víc asi udělat nemůžeš.

Pokud už dělat tu normalizaci, tak ji udělat s daty fyzicky, a prohlédnout si je. Nejdříve třeba jen na menší sadě.

Nikoli jen spočítat normlizační soubory a pak pustit image integration a doufat, že to klapne, bez kontroly dopředu, že jo to smysluplně nastavené.

Tuší někdo, proč v batch preprocesu padají některé fotky přes L filtr do stacku pro jiné barvy? Asi třetina všecl L expozic se přiřazuje do R a něco do B, tak nevím, jestli je to blbě v Pixi, nebo APT přiřadil špatně identifikátor (jsem si 100%, že jsou to opravdu L)

Porhlídni si FITS hlavičky u těch blbě zařazených souborů, co v nichh je. PI jede striktně podle fits hlavičky. Podle ničeho jinýho ani nemůže. Podle mě je nějaký bug v APT. Mě se to občas stalo, a bylo to tím (ale u mě to byla chyba mezi židlí a klávesnicí - blbě nakonfigurované filtrkolo v MaxIm DL).

Mám dotaz, jakým způsobem v Pixi provádíte dávkový ořez snímků?
Mám zaregistrováno několik sad snímků, ale pro další zpracování mě zajímá jen určitá část ve snímku. Zkusil jsem použít Blink, kde jsem si oblast zájmu v náhledu přes DynamicCrop ohraničil (třeba střed snímku). Následně jsem označil všechny snímky ve výběru (Ctrl+A), oříznul označený náhled a přes symbol nůžky pak vybral složku, kam oříznuté snímky uložit. Jenže po jejich nasypání do složky jsou snímky oříznuty sice rozměrově správně, ale zarovnáním od levého horního rohu z původních snímků, nikoliv z oblasti výběru. Tak nevím, co dělám špatně.
ProcessContainer má pro tento účel taky nějaké řešení?

Áaaaa... už mi bliklo v kebuli! V Blink místo ořezu DynamicCrop, tak "logicky" označit výběr pomocí náhledu Preview a pak symbol nůžky na Blink. Uf.

Podle mě nasypat snímky do ImageContainer, nastavit cestu pro výstup, a na Container pak aplikovat předem nastavený DynamicCrop

edit: Přes blink to tedy jde taky ? To mě ani nenapadlo tam hledat.