PixInsight

[altoz]

Vrátím se k původnímu dotazu aldy - na MHV jsme si trochu hráli s fotkou M16 a zkoušeli přes masku aplikovat LocalHistogramEqualization (jak píše oko1) a HDRMultiscaleTransform. Obojí vedlo ke zvýraznění struktur, ale pokaždé s trochu jiným výsledkem. Každopádně bych ale nejdřív začal s dekonvolucí na lineárním snímku v oblastech s vysokým SNR.

Vůbec mi přijde, že při postprocesingu v PI je nejdůležitější vytvořit si adekvátní masky pro selektivní úpravy. To je taky to s čím vždycky nejvíc bojuju a taky už došlo při tvorbě masek na PixelMath :).

[Aletel]

Přechod na PixInsight je dost krkolomný a zabere hodně času, než jej uživatel dostane pod kontrolu. Poté však už na Photoshop ani nepomyslí a zapomene. Sám mám problém pochopit, jakým stylem si vyložit a plnohodnotně použít údaje ze "Statistics" pro stanovení hodnot redukce šumu atd. případně k čemu všemu se vztahují a kde je používat, aby nešlo o cestu pokus - omyl.

K některým postupům mi pomohly polopaticky vysvětlené ukázky např.
http://lightvortexastronomy.blogspot.cz ... nique.html

[alda]

Tak to tady studuji a čtu, zároveň koumám postupu na fóru PIXI a
jak napsal Zdeněk, správně vytvořená maska je asi základ pro tyhle operace. Tady je fakt, že ve Photoshopu jsem si mohl namalovat jakoukoliv masku a tady musím vyjít z nějaké matematické operace a to je někdy trochu problém. Vzhledem k filosofii úprav fotek je to samozřejmě OK, ale je to fuška.

[pepe30]

V PixInsight je mnoho postupou na vytvorenie kvalitnej masky.Nie je tu taktiež problem "domalovat" potrebné časti pomocou CloneStamp ,ale je to všetko o skúšaní a hladaní tej najoptimalnejšej metode k dopracovaniu sa kvalitnej masky. Osobne v Photoshope iba riešim nejaké farebné dopracovanie snimky.
PixInsight je super program len je treba neustale sa v ňom zdokonalovať

[alda]

Jo jo, snažím se stále něco koumat na jejich fóru, ale často mám pocit, že jsem se něco naučil a pak ejhle ono je to možná jinak. Konkrétně by mně třeba zajímalo, jestli používáte BatchPreprocessing Script i na seskládání výsledné fotky. Já pro svou DSLR ano. Všichni, ale píšou, že se to nemá používat pro seskládání, ale pouze pro kalibraci a registraci. Složení pak dělat samostatně a zkoušet co je lepší. Někteří ale tvrdí, že stejně v 80% případů to vyjde nejlépe s automatikou v tom scriptu. Tak nevím, hlavně je zásadní podmínka mít jak porovnat různě seskládané snímky a vybrat ten lepší. Jenže co je lepší, v té fázi to nepoznám.
Proto bych se rád dozvěděl, jak tuto první zásadní fázi řešíte vy ostatní.

[altoz]

Já teda používám tenhle skript vždycky. Vzhledem k tomu že obvykle skládám velké množství snímků (50 a víc), používám LinearFit. Z nabízených algoritmů mi přijde nejlepší. Co občas přes ten skript neprojde, je registrování fotek z delšího ohniska, kdy výchozí parametry registrace moc dobře nesedí a je to pak potřeba zopakovat ručně. To se dá ale snadno odhalit.

Maximálně tak při pokusech vylovit nějaký asteroid si pohraju s integrací ručně.

[FunTomas]

...Všichni, ale píšou, že se to nemá používat pro seskládání, ale pouze pro kalibraci a registraci. Složení pak dělat samostatně a zkoušet co je lepší. Někteří ale tvrdí, že stejně v 80% případů to vyjde nejlépe s automatikou v tom scriptu. Tak nevím...Neviem v čom je problém? Nie je predsa nič jednoduchšieho vyskúšať ten postup a pozrieť sa na výsledný obrázok. Je výsledok zle zregistrovaný? Zle sčítaný? Ak áno, je tu problém a buď ho vyriešiš v nastavení toho skriptu, alebo použiješ procesy registrácie a integrácie na sfinalizovanie obrázku.
Ak je výsledok v poriadku, tak sa vykašli na to čo píšu ostatní a používaj svoj postup s ktorým si spokojný.

Za seba môžem povedať toľko, že používam tento postup len keď mám veľa inej roboty. Pustím ho a po polhodine (už aby to niekto optimalizoval) mám skalibrované obrázky. Zvyšok robím v samostatných procesoch (registrácia a integrácia), pretože sa mi občas stane, že obrázky nie sú správne zregistrované (pri širokoúhlych obrázkoch) a treba upraviť parametre registrácie. Načo sa potom zdržovať s definovaním nového skriptu pre registráciu skalibrovaných obrázkov, keď je na to proces? Rovnako to platí aj pre integráciu zregistrovaných obrázkov. Niekedy je to oriešok (kométy a asteroidy pohybujúce sa po poli, prípadne satelity a lietadlá rušiace dáta). Vtedy treba trocha laborovať a preto opäť s už registrovanými obrázkami. Načo to robiť celé cez skript?

[MMys]

Dělám to úplně stejně. Párkrát jsem s tím laboroval a zkoumal výsledný šum. Výsledek je že na běžné složení většího množství snímů (desítky na každý kanál) taky používám LinearFit clipping. To se dobře přizpůsobuje proměnným podmínkám noci.

[alda]

No oni do toho teď čerstvě přimíchali i nějaký DrizzleIntegration algoritmus a vypadá to zajímavě. Musím to vyzkoušet, uvidíme.

http://pixinsight.com/forum/index.php?topic=7184.0

[kolec]

Skusal som spominany drizlle ... Pouzil som ditherovane snimky ( primarna poziadavka). Samotna moja zostava je mierne pevzorkovana(1.04´´/pixel)
A vysledok: - vplyv na tvar hviezd bol velmi pozitivny a mojom pripade na moje prekvapenie poklesol i sum pozadia(vizualne dost vyrazne).
Pouzil subor 35 x1200s snimok Ha  .
Cely algoritmus ziskania vysledku sa este predlzi, protoze v podstate ide o tvorbu drizlle dat (pri priebehu povodneho algoritmu),  ktore sa pripisuju k povodnym suborom a nasledne sa specialnou operaciou "Drizlleintegration"  vyuzivaju .
Samozrejme tvorba drizlle dat je mozna i cez "batch preprocesing" alebo pri tzv. rucnom skladani snimok.
Ako som na zaciatku pisal , vysledok je odvisly od  , mnozstvom dat, sposobu ziskania(dithering), typu zostavy(pod alebo presamplovana).
Doporucoval by som vyskusat (drizlle data v subore nijako neovplyvnuju povodne data) a porovnat s povodnym algoritmom.
Az na zaklade vysledku sa rozhonut ci tento algoritmus pre jeho zostavu je vhodny.
Este poznamka k ditheringu - z urciteho hladiska i system , ktory nie je naalignovany + priehyby, produkuje snimky ktore by sa mohli povazovat za ditherovane. Opakujem mohli povazovat.
Vzhladom na to , ze nemam take hlboke matematicke vedomosti a mam iba hmlistu predstavu ( i ked Juan Conejero cituje literaturu,) o mechanizme vypoctu, neviem povedat ci takto "ditherovane " snimky sa daju povazovat skutocne za ditherovane z hladiska drizzle algoritmu

K mojmu sposobu spracovanie snimok . Od vtedy co som mal G4 (pri nej som sa stretol s extremnymi poziadavkami na presnost napr flat- este raz podakujem Martinovi za rady), a pri spracovani cez batch preprocesing (nemate pod kontrolou cely proces)  som na rozdiel od rucneho spracovania
dostal horsie vysledky , tak spracuvavam vysledne snimky vyhradne rucne. Mam na to spravenu sadu procesnych ikon, cize proces nie je ovela dlhsi oko klasicky.
Okrem toho v klasickom procese (je tu pouzita metoda vahy jednotlivych snimok od sumu) , sa porovnava sum z inych poli - i ked niekedy mierne inych a niekedy viac - zavisi to od toho ako sa snimky posuvaju , ci uz v ramci ditheringu , alebo ineho vplyvu, sumu okrajov, flipu  atd.
pri rucnom procese si jednoduchym postupom presne urcim najmensie aktivne pole na vsetkych snimkach a sum sa v jednotlivych snimkach porovnava iba z tohto pola, na zaklade toho sa stanovy vaha jednotlivych snimok a tie sa do vysledneho snimku  zarataju s ich prislusnou vahou.
Samozrejme, ze je na diskusiu prinos v kvalite vyslednej snimky. Nemozte cakat prudke zlepsenie snimok na uroven hubble telescopu, tobos zle snimky nevylepsi ani pan boh  a nie to este nejaky drizlle... Tieto algoritmy su skor nadstavbou. Ale kde u koho konci zakladna a zacina nadstavba - tot o otazka

Ale som sa nejako rozpisal

kolec

[alda]

Prosím potřeboval bych poradit, jak složit snímky RGB a H-alfa, vše uděláno pomocí DSLR.
H-alfu jsem udělal tak, že jsem debayeroval (hnusné slovo) rawy, z výsledku vzal R-kanál, vše stejně i s BIASY, FLATY A DARKY.
Výsledné H-alfa jsem dostal po kalibraci, registraci a sloučení těchto vytvořených snímků (asi podobné postupu s mono kamerou).
Výsledek je H-alfa černobílý snímek s menším rozlišením jako RGB, to je jasný. Hledal jsem různé tutorialy jak provést sloučení s RGB, ale většina je pro CCD kamery (ikdyž by to mělo být asi podobné). Asi je více možností, vložit jako H-alfu jako L-kanál a pod.
Ani nevím, jestli sloučení dělat na surových datech a pak teprve po spojení dále udělat postprocesing snímku v Pixi nebo zpracovat oba snímky zvláště a pak až na konec to sloučit (to je asi blbost).

Prosím jak to děláte ???

BTW: zkoušel jsem drizzle vytváří mi sem tam malé zelené hnusné hodovité artefakty.

[FunTomas]

Ha z foťáku zregistruj v tomto prípade s RGB obrázkom. Ako referenčný obr. vezmi RGB. Program zväčší Ha, čo v tomto prípade nevadí.
Zregistrované obrázky je možné zložiť cez LRGB. L=Ha, ostatné kanály zmazať. Pri aplikovaní preniesť ikonu na RGB obrázok.

[Evzen]

Alda: Na to je v PI "script/utilities/NBRGB combination". Aplikuje se na RGB obrázek a ve scriptu se zadává který úzkopásmový obrázek se má přidat do kterého kanálu RGB. V tomto případě Ha do R.
Pokud použiješ postup podle Funtomase, rozhodně bych L udělal z Ha+R+G+B s nějakými přiměřenými vahami. Jednotlivé kanály R, G , B získáš z RGB procesem ChannelExtraction. Samotná Ha jako L není zrovna šťastné řešení.

[MMys]

Nebo to jde taky udělat v PixelMath (jednotlivé barevné kanály se odlišují indexem v hranaté závorce, 0 je R, 1 je G a 2 je B):
Tedy odzaškrtnout Use a sigle RGB/K expression a do jednotlivých řádků R/K, G a B napsat:

(1-x)*RGB_image[0]+x*HA_image[0]
RGB_image[1]
RGB_image[2]

kde místo RGB_image dáš název svého RGB snímku, místo HA_image název snímku v H-alfě (je šumák jestli červeného nebo monochromatického, bude to fungovat s obojím).

Číslo x z intervalu <0; 1> udává poměr, kterým nahradit R kanál H-alfou. Tedy když dáš třeba x=0.3, tak se 30% z R kanálu nahradí H-alfou.

Snímky musí být zregistrované, a pokdu možno už nějak stretchnuté, znormalizované do nějakého rozumného přibližně stejného rozsahu, nebo naopak ještě vůbec nezpracované. Nakonec to záleží na účelu, za kterým to děláš.

Lze vymyslet i jiné matematické konstrukce, kde se to třeba přičtě navíc, aniž ubíráš z původního R kanálu, ale pak začíná obraz ujíždět do červena a je třeba ho stejně ještě nejak doladit.

Ale na laborování je asi nejlepší již zmíněné NBRGB.

[Psion]

Ta práce s PixelMath je naprosto geniální a unikátní.