Asia lähti liikkeelle täältä: http://foorumi.avaruus.fi/index.php?topic=7938.msg102808#msg102808 (http://foorumi.avaruus.fi/index.php?topic=7938.msg102808#msg102808)
Lainaus käyttäjältä: Timpe - 28.11.2012, 23:27:49
Tämän kohteen kuvaaminen on sekin venynyt luvattoman kauas alkuperäisistä suunnitelmistani, mutta tässä tämä "piilotettu galaksi" nyt on melko vaatimattomalla 7h 25min kokonaisvalotusajalla. Kuvattu kahtena marraskuun iltayönä 300/1500mm Newtonilla ja QSI 583ws CCD-kameralla (Astrodonin LRGBHa-suodinsetillä). Osavalotukset RGB kanavissa 8min (2x2 bin) + L/Ha kanavissa 15min (1x1 bin). Punaisen kanavan sekaan on sekoitettu 45min Ha-valoa + L-kanavaan loput 30min Ha:t tuomaan nuo kierteishaarojen vety-alueet paremmin esiin (sekoituksen kaava on tässä: LRGBHa = 135+30min : 80+45min : 80min : 72min).
Lainaus käyttäjältä: naavis - 29.11.2012, 22:42:18
Ymmärsinköhän nyt oikein, että olet tehnyt eri värikanaviin sekoittamista varten erisuuruisia pinoja H-alfasta? Kannattaa mieluummin pinota kaikki kuvaamasi Ha-ruudut ja sitten lisätä pino värikanaviin halutuilla painotuksilla. Jättämällä ruutuja pinosta pois huononnat kuvan signaali-kohina-suhdetta turhaan. Mitä enemmän valoa Ha-pinossa on, sitä parempi approksimaatio se on taivaalta tulevasta Ha-valon jakaumasta. Jättämällä ruutuja pinosta pois huononnat approksimaatiota ja käytännössä lisäät kohinaa lopulliseen kuvaan.
Luultavasti ajateltiin eri tavalla samasta asiasta, mutten tiedä onko oma pinoamistapani ollut yhtään ehdotettua fiksumpi. Teen näet loppukuvan pinoamisen suoraan MaxIm DL:n Stack... velhon kautta. Lisään ensin tuonne kuvakansion, mistä löytyvät kaikki tietyn kohteen (etukäteen kalibroidut) LRGBHa yksittäiskuvat. Kuvakansiossa ja samalla Stack... näkymässä on siis ensin tämän tyyppinen rakenne (kuvausöiden mukaan):
1
-L
-R
-G
-B
-Ha
2
-L
-R
-G
-B
-Ha(jne.)
Raahaan sitten 2-L kansion kuvat 1-L kansioon, samoin teen R, G ja B kanaville. Stack-ikkunaan kertyy siis yksi LRGB kansiopuu, missä ovat kaikki pinotut kuvat oikeissa lokeroissaan. Tämän jälkeen mietin mihin kanaviin tiputan ne Ha-kuvat; esim. tässä tapauksessa olen siirtänyt 3 x 15min Ha-kuvia R-kanavan kuvien sekaan. Tuon jälkeen R-kanavassa on 10 x 8 min (R) + 3 x 15 min (Ha) kuvia, mitä kaikki pinotaan yhteen tuon Stack-velhon viimeisilla välilehdillä. MaxIm ei käytännössä osaa kohdistaa 1x1 bin (Ha) ja 2x2 bin (R) kuvia oikein automaattitoiminnoillaan, joten kohdistan ne kahden tähden manuaalikohdistuksella. MaxIm resamplaa jossain vaiheessa nuo 2x2 bin R-kuvat 1x1 bin kokoon ennen kuin näistä tehdään LRGB-loppukuvan punainen värikanava. En käytännössä poistu Stack-velhosta ennen kuin LRGB-loppukuva on valmiina. Kohinasta en ole ollut huolissani, kun sitä ei yksinkertaisesti ole ollut haitaksi saakka ennen t-o-d-e-l-l-a rankkoja Levels/Curves-venytyksiä (kokonaisvalotusaikani ovat olleet näissä tapauksissa yli kuuden tunnin).
Mikä menee siis pieleen?
En tässä heti miten osaa antaa kovin tyhjentävää vastausta, mutta aloitetaan nyt siitä, että eri värifilttereillä kuvattuja ruutuja ei missään tapauksessa pidä pinota keskenään, ainakaan millään muulla tavalla kuin summaamalla. Kaikki tilastolliset pinoamistavat heittävät häränpyllyä, jos eri kanavien kuvia sekoittaa keskenään pinoamisvaiheessa, ja signaali-kohina-suhde voi huonontua hyvinkin merkittävästi.
Jos haluat sekoittaa esimerkiksi H-alfa-valoa värikanaviin, se kannattaa tosiaan tehdä niin, että pinoaa vain saman värikanavan ruutuja keskenään, ja sitten summaa näitä pinoja halutuilla painotuksilla keskenään. Jättämällä pinoista kuvia pois eri painotusten aikaansaamiseksi huononnat kuvanlaatua aivan turhaan.
Yritän illemmalla kehitellä vielä selkeämmän vastauksen, toivottavasti tämäkin jo auttoi vähän!
Ok, kiitos alustuksesta aiheeseen. Jotain tuloksia tuolla kuvaamallanikin tavalla toimimallakin tulee, kun olen niitä foorumilla esitellyt... :shocked:
Mutta kertokaa tietävämmät tästä Ha-kanavan pinoamis/yhdistämisasiasta lisätietoa, koska näistä asioista ei oikein löydy tietoa ainakaan suomeksi. Tuossa IC342:n tapauksessa Ha-kanavaa on yhteensä 5 x 15min (75min) ja sen signaalitaso oli hyvin matala (=liitteessä tulee rankasti venytetty FITS-ruutu, mistä näkee ettei Ha-signaali todellakaan hallitse kuva-alaa edes 15min yksittäisvalotuksen jälkeen).
Itse lisään Photoshopissa Ha:n LRGB-kuvaan kahdella eri tavalla (siis samaan lopputulokseen).
1. L+RGB omina layereina ja näiden päälle lisään Ha:n Overlay-kerroksena, deletoin siitä kirkkaat tähdet ja käytän High Pass filtteriä. Näin saat Ha:n yksityiskohdat kuvaan pilaamatta tähtien värejä.
2. Vielä yksi Ha-layer (Lighten), josta deletoin Green ja Blue channelit (niin että niistä tulee mustat). Tämän layerin histogrammia/levelsiä venyttämällä saat punaista korostettua.
Tässä kannattaa nyt erottaa toisistaan kaksi eri asiaa. Kovia faktoja ovat:
1) Ha:n yhdistäminen LRGB-dataan onnistuu monilla eri keinoilla ja
2) Kaikki keinot liittyvät siihen että yhden filtterin data on pinottu ensin keskenään ja vasta sitten sotkettu muihin filttereihin.
Eri filttereiden pinoaminen yhteen kuvaan on pöhköä.
Kakkoskohdan perusteena on se, että jos pinotaan Ha ja R yhteen, menetetään täysin mahdollisuus kontrolloida jälkikäsittelyssä Ha:n ja punaisen suhdetta toisiinsa. Lisäksi jos pinossa käytetään jotain muuta kuin yksinkertaista summaa/keskiarvoa, pilataan täysin tilastollisten pinoamismenetelmien edellytykset toimia oikein.
Esimerkiksi kun käytetään sigma-clippiä, saattaisi jollain filtterillä kuvattuna jonkun sumualueen tietty pikseli saada arvoja väliltä 1490..1510. Nyt jos siihen pikseliin osuukin satelliitti joka tuottaa 2500 adua, voidaan tuo yksi väärä arvo heittää hyvillä mielin pois.
Sitten jos laitetaankin samaan pinoon raakadataksi kahden eri filtterin tuotoksia, voi sumun kirkkaus sillä toisella filtterillä olla vaikka 2090..2110 adua. Nyt pinossa lopputulokseksi saadaankin keskiarvoksi noin 1800 adua (jos kumpiakin ruutuja oli sama määrä), mutta vaihteluväli (melkein sama kuin keskihajonta eli sigma) onkin yli 500, kun se äsken oli 20. (tässä on hieman oiottu laskuissa mutta periaate pitäisi selvitä hyvin)
Tuloksena on se että jos sigman kerroin maximissa on vaikka 3, kaikki häiriöt jotka ovat 3*500 = 1500 adun päässä keskiarvosta jäävätkin suodattumatta pois, kun ne edellisessä tapauksessa häipyivät tehokkaasti. Muistakaa että häiriöt voivat olla sekä pimeitä että kirkkaita ja tulla sekä taivaalta että kennosta.
Eli kaikki filtterit aina omiin pinoihinsa jolloin jälkikäsittelyn lähtökohtana on hyvät silkinsileät pinot joka värille/emissioviivalle. Näistä voi sitten siirtyä kohtaan yksi eli yhdistää niitä jollain miljoonasta eri photoshop-taikatempusta tai sitten jotenkin muuten. Nähdäkseni tässä voi joko yrittää toimia jotenkin järkevästi, tai sitten ottaa taiteellisia vapauksia jolloin saa hienompia lopputuloksia nopeammin. En esimerkiksi itse osaa tätä tehdä mitenkään kovin älykkäästi.
Mickut (ja naavis) PixInsight-liikakäyttäjinä ovat puhuneet jostain järkevän oloisesta matikkaan perustuvasta proseduurista jossa yhdistäminen tehdään oikein ja ennenkaikkea toistettavalla tavalla. Varsinkin tuo toistettavuus olisi kyllä tähtikuvien käsittelyssä asia johon kannattaa pyrkiä. Valitettavasti olen itse tippunut kärryiltä ajat sitten.
Vähän toivoinkin, että Lauri osallistuisi keskusteluun. Itseltäni tuppaa puuttumaan kyky selittää asiat helposti ja yleistajuisesti, Laurilta se taas sujuu kuin tanssi. :grin:
Lainaus käyttäjältä: naavis - 05.12.2012, 14:04:43
Vähän toivoinkin, että Lauri osallistuisi keskusteluun. Itseltäni tuppaa puuttumaan kyky selittää asiat helposti ja yleistajuisesti, Laurilta se taas sujuu kuin tanssi. :grin:
Samaa mielta. Laurilla tulevaisuus opettajana tai tietokirjailijana. Niin hyvia ja selketa ovat hanen esityksensa.
t vesa
Lainaus käyttäjältä: Lauri Kangas - 05.12.2012, 12:44:44
Sitten jos laitetaankin samaan pinoon raakadataksi kahden eri filtterin tuotoksia, voi sumun kirkkaus sillä toisella filtterillä olla vaikka 2090..2110 adua. Nyt pinossa lopputulokseksi saadaankin keskiarvoksi noin 1800 adua (jos kumpiakin ruutuja oli sama määrä), mutta vaihteluväli (melkein sama kuin keskihajonta eli sigma) onkin yli 500, kun se äsken oli 20. (tässä on hieman oiottu laskuissa mutta periaate pitäisi selvitä hyvin)
Tämä selvä eli pitänee muuttaa jatkossa toimintatapoja (kiitos Lauri!) :smiley:
Käsittelyn toistettavuus on tässä vaiheessa vielä kaukana tulevaisuudessa, kun raakakuvien loppukäsittely julkaisuvalmiiksi on jostain syystä jonkinlaista pakkopullaa itselleni. Kerran sen vielä tekee melko mielellään, jotta näkee millainen loppukuva kuvatusta materiaalista syntyy, mutta muutoin ei jaksaisi hieroa niitä vanhempia raakakuvia yhtään pidempään kuin on pakko. Olisi varmaan ihan hyväksi, mutta kun ei ole palavaa intoa tähän tai lopputuloksena syntyneen tif-kuvan loputtomaan muokkaamiseen PS:ssa... ("henkinen inertia" iskee välillä näin allekirjoittaneeseen ;)
Lainaus käyttäjältä: Lauri Kangas - 05.12.2012, 12:44:44
Eri filttereiden pinoaminen yhteen kuvaan on pöhköä.
Samaa mieltä.
Lainaus käyttäjältä: Lauri Kangas - 05.12.2012, 12:44:44
Kakkoskohdan perusteena on se, että jos pinotaan Ha ja R yhteen, menetetään täysin mahdollisuus kontrolloida jälkikäsittelyssä Ha:n ja punaisen suhdetta toisiinsa. Lisäksi jos pinossa käytetään jotain muuta kuin yksinkertaista summaa/keskiarvoa, pilataan täysin tilastollisten pinoamismenetelmien edellytykset toimia oikein.
Esimerkiksi kun käytetään sigma-clippiä, saattaisi jollain filtterillä kuvattuna jonkun sumualueen tietty pikseli saada arvoja väliltä 1490..1510. Nyt jos siihen pikseliin osuukin satelliitti joka tuottaa 2500 adua, voidaan tuo yksi väärä arvo heittää hyvillä mielin pois.
Sitten jos laitetaankin samaan pinoon raakadataksi kahden eri filtterin tuotoksia, voi sumun kirkkaus sillä toisella filtterillä olla vaikka 2090..2110 adua. Nyt pinossa lopputulokseksi saadaankin keskiarvoksi noin 1800 adua (jos kumpiakin ruutuja oli sama määrä), mutta vaihteluväli (melkein sama kuin keskihajonta eli sigma) onkin yli 500, kun se äsken oli 20. (tässä on hieman oiottu laskuissa mutta periaate pitäisi selvitä hyvin)
Mickut (ja naavis) PixInsight-liikakäyttäjinä ovat puhuneet jostain järkevän oloisesta matikkaan perustuvasta proseduurista jossa yhdistäminen tehdään oikein ja ennenkaikkea toistettavalla tavalla. Varsinkin tuo toistettavuus olisi kyllä tähtikuvien käsittelyssä asia johon kannattaa pyrkiä. Valitettavasti olen itse tippunut kärryiltä ajat sitten.
Eri mieltä syystä. Tilastolliset pinoamismenetelmät vaativat toimiakseen sen, että kuvat ovat keskenään normalisoituja. Suurin osa ohjelmista (esim MaxImDL) tekee sen näkymättömissä, PI:ssä tuohon normalisointitapaan voi hieman vaikuttaa. Jos normalisointia ei tehtäisi, ei kuvia voisi pinota kuun vaiheen vaihtuessa eri öinä. Syy miksei eri suotimien (L/C/valosaaste ehkä poislukien) läpi kuvattuja ruutuja kannata pinota keskenään, on se, että kohteiden eri osat ovat erikirkauksisia toisiinsa nähden, eikä tällöin voi luotettavasti laskea mikä kohta on pölypalloa, kosmista sädettä, lentokonetta tai kohdetta.
Käytetään esimerkkinä vaikka kohdetta jossa on vierekkäset, yksiväriset, kirkkaat detaljit kullakin kanavalla: jos nämä pinotaan tilastollisilla tavoilla keskenään luminanssiksi, tappelee kunkin kanavan kirkas pikseli yksin kahta muuta himmeää pikseliä vastaan. Lopputulemana kaikki detaljit katoavat. Jos taas kanavat pinotaan yksittäin ja sen jälkeen yhdistetään summana tai keskiarvona luminanssiksi, erottuvat jokaisen kanavan detaljit oikein nätisti.
Tähän osittain liittyen ja osin liittymättä olen raapustellut pari päivää ajatuksiani muutamaan blogipostaukseen ja ensimmäinen, kuvien valinnasta pinoamiseen asti yltävä, alkaa olla kohta julkaisukunnossa.
-Antti
edit: Pinoamista käsittelevä osuus (http://blog.kuntsi.com/2012/12/tahtikuvankasittelyn-perusteita.html) tuli valmiiksi.
Mainio blogipostaus!
Lainaus käyttäjältä: mickut - 05.12.2012, 20:15:31
Eri mieltä syystä. - - Syy miksei eri suotimien (L/C/valosaaste ehkä poislukien) läpi kuvattuja ruutuja kannata pinota keskenään, on se, että kohteiden eri osat ovat erikirkauksisia toisiinsa nähden, eikä tällöin voi luotettavasti laskea mikä kohta on pölypalloa, kosmista sädettä, lentokonetta tai kohdetta.
Tämä on juuri se sama syy jota yritin itsekin sanoa, eli oikeasti ollaankin samaa mieltä?
Eli yhdellä filtterillä kohteen jokin osa sijoittuu jollekin kirkkaudelle (plusmiinus jokin hajonta) ja toisella filtterillä jollekin muulle kirkkaudelle (plusmiinus jokin eri hajonta). Tähän vielä jokin lentokone tai pölypallo jollain ihan omilla kirkkauksillaan, niin saadaan koko roskan keskiarvoksi + keskihajonnaksi jotain ihan kummallista.
Tästä keskiarvosta ja keskihajonnasta ei sitten voidakaan päätellä mitään tiettyä hyväksymisväliä jonka sisälle jäävät arvot hyväksytään pinoon ja muut heitetään pois. Normalisoinnista jätin selvyyden vuoksi mainitsematta, ettei kukaan pelästy pois. Yllä kirjoitetussa siis oletetaan että data on jo normalisoidun laatuista eli kerätty lyhyessä ajassa vakio-olosuhteissa ja ilman häiriöitä.
Normalisointiin liittyy muuten yksi juttu josta en ole vielä päässyt perille (ehkä se lukee tuossa blogipostauksessa, mutta sen lukemista ennen täytyy nukkua vähän). Nimittäin jos pinoan minuutin ja kahden minuutin mittaisia valotuksia, niin normaalia summaa käyttämällä kaikki sujuu hyvin. Mutta jos normalisoin kaikki ruudut yhtä kirkkaiksi esim. sigma clippiä tai jotain muuta varten, niin silloinhan kerron lyhyempien valotusten kohinaakin isommaksi ja se kohina pääsee vaikuttamaan lopputulokseen liikaa.
Onko normaaleissa sigmapinotoiminnoissa jokin joka tietää eri ruutujen valotusajan ja pitää kirjaa siitä, että normalisoidusta, sigman perusteella roskista puhdistetusta datasta niille kahden minuutin ruuduista otetuille numeroille annetaan tuplasti isompi painoarvo keskiarvoa laskettaessa?
Lainaus käyttäjältä: Lauri Kangas - 06.12.2012, 02:25:05
Onko normaaleissa sigmapinotoiminnoissa jokin joka tietää eri ruutujen valotusajan ja pitää kirjaa siitä, että normalisoidusta, sigman perusteella roskista puhdistetusta datasta niille kahden minuutin ruuduista otetuille numeroille annetaan tuplasti isompi painoarvo keskiarvoa laskettaessa?
Esim. CCDStack tekee juuri näin eli antaa kuville painoarvot mm. niiden valotusajan perusteella.
Lukiessani mickutin 'eri mieltä' -vastauksen, tulin siihen tulokseen, että hän oli Laurin kanssa samaa mieltä eli olen Laurin vastauksen kanssa samaa mieltä. :grin:
Lainaus käyttäjältä: Lauri Kangas - 06.12.2012, 02:25:05
Onko normaaleissa sigmapinotoiminnoissa jokin joka tietää eri ruutujen valotusajan ja pitää kirjaa siitä, että normalisoidusta, sigman perusteella roskista puhdistetusta datasta niille kahden minuutin ruuduista otetuille numeroille annetaan tuplasti isompi painoarvo keskiarvoa laskettaessa?
PixInsight käsittääkseni mittailee pinottavien ruutujen kohinamääriä, ja keksii niille eri kokoisia kertoimia ennen lopullista pinoamista siten, että kohinattomammat ruudut saavat isomman painotuksen kuin kohinaiset.
Lainaus käyttäjältä: Lauri Kangas - 06.12.2012, 02:25:05
Tämä on juuri se sama syy jota yritin itsekin sanoa, eli oikeasti ollaankin samaa mieltä?
Todennäköisesti, piti vain varmentaa ettei jää väärä olettama taustalle. Olennaista ei siis ole kohteen kokonaiskirkkaus eri suotimilla, vaan sen kohteen värivaihtelut, joista seuraa kirkkausvaihtelujen muotoerot eri suotimien välillä.
Lainaus käyttäjältä: Lauri Kangas - 06.12.2012, 02:25:05
Normalisointiin liittyy muuten yksi juttu josta en ole vielä päässyt perille (ehkä se lukee tuossa blogipostauksessa, mutta sen lukemista ennen täytyy nukkua vähän). Nimittäin jos pinoan minuutin ja kahden minuutin mittaisia valotuksia, niin normaalia summaa käyttämällä kaikki sujuu hyvin. Mutta jos normalisoin kaikki ruudut yhtä kirkkaiksi esim. sigma clippiä tai jotain muuta varten, niin silloinhan kerron lyhyempien valotusten kohinaakin isommaksi ja se kohina pääsee vaikuttamaan lopputulokseen liikaa.
Onko normaaleissa sigmapinotoiminnoissa jokin joka tietää eri ruutujen valotusajan ja pitää kirjaa siitä, että normalisoidusta, sigman perusteella roskista puhdistetusta datasta niille kahden minuutin ruuduista otetuille numeroille annetaan tuplasti isompi painoarvo keskiarvoa laskettaessa?
On ja ei. Periaatteessa erimittaisiakaan ruutuja ei pitäisi tuon vuoksi pinota samaan syssyyn kerralla, ellei käytössä ole hyvin kehittynyttä matematiikkaa. "Normaaleilla" työkaluilla nuo erimittaiset valotukset pinotaan per valotusaika, ja sen jälkeen kukin valotusaikapino sovitetaan yhteiseen lineaariseen kirkkausmaailmaan. Noista normalisoiduista osapinoista voidaan sitten pinota se lopullinen korkean dynaamisen alueen pino hylkäämällä kustakin osapinosta tarvittaessa ylä- ja/tai alapäätä.
Monimutkaisemmalla matematiikalla tuo ison alueen normalisointi voidaan tehdä pinoamisvaiheessa ja hylätä lineaarisovituksen kautta huonosti sopivat pikselit (kuten liikaa skaalautunut kohina). Samalla pitää nysvätä muitakin hylkäyskriteerejä pitkien valotusten tähtien saturaation vuoksi. Näitä erimittaisten kuvien pinoamista en vielä ottanut käsittelyyn blogipostauksessa, se vaatii hieman enemmän kirjoitusta ja vaikuttaa työnalla olevaan postaukseen "kuvaaminen".
Keskenään samanmittaiset ruudut kannattaa normalisoida PI:ssä omien testieni mukaan joko flux tai average moodeissa, jolloin taivashehkun vaikutus poistuu melko hyvin. Niitä kaikkia hylkäysmoodeja en ole vielä päässyt testaamaan vajaavaisen kuvadatan vuoksi.
-Antti
Hei
Koitetaan pysya perassa.
Kun puhutaan lineaarisista kuvista, niin silla tarkoitattaneen ccd kennolta tullutta kuvaa, joka ei ole ihmissilmin nahtavissa.
Lineaarinen kuva saadaan eilineaariseksi ja silman havaittavksi esim histogram prosessin kautta ???
Mika on normalisoitu kuva ?
Kaytan PI ohjelmaa ja valilla tuntuu, etta Photarin ja PI:n termit eivat aina ole samoja.
t vesa
Lainaus käyttäjältä: vesa k - 06.12.2012, 13:05:42
Kun puhutaan lineaarisista kuvista, niin silla tarkoitattaneen ccd kennolta tullutta kuvaa, joka ei ole ihmissilmin nahtavissa.
Lineaarinen kuva saadaan eilineaariseksi ja silman havaittavksi esim histogram prosessin kautta ???
Mika on normalisoitu kuva ?
Kaytan PI ohjelmaa ja valilla tuntuu, etta Photarin ja PI:n termit eivat aina ole samoja.
Lineaarinen kuva on kuva, jolle on tehty vain lineaarisia muutoksia: yhteen-, vähennys-, kerto- ja jakolasku. Esimerkiksi MaxImDL:n ScreenStrech on lineaarinen näkymä (yleensä lineaariseen) kuvaan, jossa suoritetaan noita mainittuja neljää laskutoimitusta niin että haluttu lähtöarvoalue muuttuu näytettäviksi arvoiksi säätämällä halutut musta- ja valkopisteet. Ei-lineaariseksi kuva muuttuu kun sille tehdään mitään muita laskutoimenpiteitä, esimerkiksi kontrastikorostus, käyrien säätö tai histrogrammin muutos.
PixInsightissa voi tehdä ei-lineaarisen näkymän lineaariseen kuvaan, PI:n Screen Transfer Function on vastaava kuin MaxImDL:n Screen Stretch, mutta sisältää musta- ja valkopisteen lisäksi epälinearisoivan gamma-arvon. Tällä on suuri merkitys kuvan käsiteltävyyden kannalta. Fotarissakin on nykyään kuulemma jonkinlainen suodatinkerros, jossa allaolevalle kuvakerrokselle voi tehdä epälineaarisen muunnoksen näytölle piirtämistä varten muuttamatta itse dataa, tätä kannattaa hyödyntää.
Vaikka näyttölaitteiden rajoitukset estävät meitä näkemästä kovin suuria kirkkauseroja tietokoneelta, ei kuvadataa "saa" muuttaa epälineaariseksi liian aikaisin, suuri osa kuvankäsittelyyn kehitetyistä algoritmeista olettaa kuvadatan olevan lineaarista. Tärkein näistä on väritasapainon säätö, se ei voi edes teoriassa onnistua epälineaariselle datalle kuin tuurilla koska kirkkausvaihteluiden suhteet eivät ole enää samat. Samoin kohinanpoistoa ja tähtien muotojen hienosäätöä kannattaa tehdä jo lineaarisella datalla, jossa kohina on arvoalueeltaan vielä varsin pientä ja tähdet eivät ole vielä pullistuneet tunnistamattomiksi palloiksi.
Normalisoitu kuva on mikä tahansa kuva, joka on normalisoitu. Yksittäisen kuvan normalisointi tarkoittaa yksinkertaisimmillaan kuvan tummimman pikselin asettamista nollaksi, kirkkaimman ykköseksi (tai halutun kuvaformaatin suurimmaksi arvoksi), ja sen jälkeen tehdään vähennys- ja kertolaskua samoilla arvoilla kaikille pikseleille tuohon väliin. Usean kuvan kohdalla muitakin tapoja on käytettävissä, kuten kuvien keskinäisen kohinan arviointi, keskikirkkausarviointi ja niin edelleen, mutta kaikki operaatiot yksittäiselle kuvalle ovat edelleen lineaarisia. Normalisoiduilla kuvilla on samankaltaiset tilastolliset ominaisuudet, mikäli ne on otettu samankaltaisissa olosuhteissa (valotusaika, kamera, suodatin, kaukoputki, kohde), mutta niille ei ole (yleensä) tehty muita kuin lineaarisia operaatioita. Irtoruutujen normalisointia ei kannata tehdä itse, ellei oikeasti tiedä mitä tekee, ja minä en ainakaan keksi mitään syytä normalisoida yksittäisiä ruutuja erikseen.
Fotarin ja PI:n termistö voi vaihdella. Fotaria en ole käyttänyt, joten en osaa siitä sanoa, PI:n termistö täsmää hyvin kuvankäsittelyteorian termistön kanssa.
-antti
Hmm.. tässä vaiheessa lienee viiisainta olla kaikkien kanssa samaa mieltä...
Tuo yksittäisten ruutujen normalisointi jäi epäselväksi, itse käytän ccd stackia tuossa työvaiheessa, joten ainakin Petrillä sama käytössä.
Kertokaa jos jossain vaiheessa menee työvaiheet pieleen, näin olen toiminut tähän asti :
* Kuvapinon ( yksi värikanava ) kalibrointi flät/bias/dark
* Rekisteröinti
* Normalisointi koko pinolle ( käytän yleensä auto toimintoa )
* Data reject, tässä yleensä Possion sigma reject ( satelliitit ym roskat ), muut menetelmät eivät oikein tarkoitukseltaan vielä auennut.
* Pinonta joko sum tai mean, ja tietty tallennus jatkokäsittelyä varten
Meneekö about niinkuin pitää vai täysin metsään ??
Utelee Jari
Lainaus käyttäjältä: JariP - 06.12.2012, 19:03:11
Kertokaa jos jossain vaiheessa menee työvaiheet pieleen, näin olen toiminut tähän asti :
* Kuvapinon ( yksi värikanava ) kalibrointi flät/bias/dark
* Rekisteröinti
* Normalisointi koko pinolle ( käytän yleensä auto toimintoa )
* Data reject, tässä yleensä Possion sigma reject ( satelliitit ym roskat ), muut menetelmät eivät oikein tarkoitukseltaan vielä auennut.
* Pinonta joko sum tai mean, ja tietty tallennus jatkokäsittelyä varten
Meneekö about niinkuin pitää vai täysin metsään ??
Utelee Jari
Kuvapinon kalibroinnin jälkeen ja ennen rekisteröintiä, on syytä tehdä esim. reject bloom sekä/tai reject hot/cold pixels.
Kuvien pinoamiseen käytän STD sigma rejectiä yleensä 2%:lla tai arvoa 2.2-2.5 riippuen pinottavien kuvien määrästä tai paljonko kuvista täytyy häiriöitä saada pois.
Muuten teen itse hommat samassa järjestyksessä.
Lainaus käyttäjältä: JariP - 06.12.2012, 19:03:11
Meneekö about niinkuin pitää vai täysin metsään ??
Kuulostaa juuri siltä kuin pitäisikin. CCD Stackia ei ole tullut käytettyä, mutta sen tapa tehdä asoita vaikuttaa myös ihan järkevältä. Mahdollisuus hylätä dataa useilla eri kriteereillä, ja CCD Stackin myyntipuheen perusteella eri vaiheissa, kuulostaa hyvältä.
-Antti
Lainaus käyttäjältä: mickut - 06.12.2012, 13:35:51
Ei-lineaariseksi kuva muuttuu kun sille tehdään mitään muita laskutoimenpiteitä, esimerkiksi kontrastikorostus, käyrien säätö tai histrogrammin muutos.
Tai gamma-korjaus (http://en.wikipedia.org/wiki/Gamma_correction), joka on eksponentiaalinen muunnos: lopputulos = lineaaridata
gamma. Sitä käytetään usein lineaaridatan säätämiseksi vastaamaan silmän sävyhavainnointikykyä varten.
edit: "[" lisää