LRGB - délka,poměr expozic, binning

[MilAN]

jaký je rozdíl mezi tou P2 a D2 variantou a případně proč je pro mé účely lepší varianta P2 ?

Rozdíly najdeš v tomhle grafu propustnosti. Klikáním na barevná pole se ti zobrazí dotyčný filtr i spektra zdrojů. D2 je podobný CLS, chybí tam potom dost barevných informací pro rekonstrukci barev.
https://www.sciencecenter.net/hutech/id ... /index.php

[MMys]

Jo, přesně to jsem i myslel, ale to není typ II c.

[DaveOne]

Ještě se vrátím k tomuto :
,,Jelikož na bídné obloze je expoziční doby vždy málo, lze RGB snímky sečíst s těmi jasovými, a tím si L kanál bezpraceně vylepšit. Škoda přeci ty fotony využít jen do jasové složky. Platí že 1x R+G+B by mělo být ekvivalent 1x L. (když zanedbám průběh charakteristik filtrů). ,,

Říkáš tedy, že při finálním skládání L-kanálu v Pixi mám zahrnout do snímků i všechny vybrané z RGB ? takže finální složenina L bude mít tím pádem více jasové složky. Ano ? Nezanese to, ale do L snímku (master light) ten nadměrný šum a gradienty z RGB kanálů ?

[nou]

Nie viac signalu nikdy nie je naskodu. Ono aj prevedenim farebneho obrazku do ciernobieleho sa znizi sum pretoze spravime zjednoducsene povedane (R+G+B)/3 teda ako keby sme zlozily tri snimky.

[mirkovacik]

A treba /3? Nie je to cisty sucet, aby tohralo s tymi L?

Odoslané z HUAWEI VNS-L21 pomocou Tapatalku

[MMys]

mirkoavcik:
A proč děleno třemi ? Každý filtr přeci pustí zhruba třetinu fotonů (zanedbávám nepřesnost způsobenou překryvy spektrálních pásem). Takže po součtu by to mělo být téměř totéž (ne úplně, neřeším 3x vs. 1x vyčítací šum, ale to je u RGB fuk, tam dominuje šum fotonový).

Pokudu z toho vezmeš aritmetický průměr, tedy jak píšeš /3, bude přeci výsledek 3x slabší než originální L-ko.

nou: to také není pravda. Viz výše. Přes každý filtr projde jen třetina signálu. Tedy barva převedená do monochrom metodou průměr z RGB složek bude mít ty úrovně 3x nižší.

Obecně: Ne že by to extra vadilo, ale používaný SW musí umět dělat při skládání normalizaci. Pokud ji neumí (nebo si ji neznalý uživatel nezapne) tak ty snímky vyhází sigma clip algoritmus, budou-li v menšině.

Já osobně to řeším tak, že sekládám všechny kanály. Potom součetm z RGB udělám syntetické Ls a pak udělám vážený průměr z L a Ls a jako váhu použiji hodnotu šumu. Tedy více zašuměné Ls se uplatní menší vahou.

[nou]

Vyjadril som sa trocha nepresne. Ten sum poklesne vzhladom na povodny farebny obrazok ak to nie je uzkopasmovy objekt. Jeden 3xN min RGB snimok je ekvivalent 1xN min L snimku ak teda zanedbame read/dark noise.

Nemaly by byt vahy rovne pomeru dlzky expozicie L a (R+G+B)/3? Pretoze ak sa nemylim hodnota sumu bude rovna odmocnine z casu expozicie.

[MMys]

Těžko soudit, mohou do toho vstupovat i spektrální charaketrisktiky senzoru a kdoví co ještě. Já to prostě neřeším, ten šum raději změřím ve výsledých složeninách, a je to.

[Bill]

Tak pokud se to skládá v PI, tak to si nastaví váhy podle šumu automaticky.

[MMys]

Ale já mám pocit, že ImageIntegration šlo až od tří snímků ? A proto jsem to dělal přes PixelMath. Možná už to ale neplatí.

[hades]

Stále to platí

[Bill]

Ale já přece mohu integrovat rovnou všechny snímky L, R, G, B dohromady. Pak to funguje automaticky.

[MMys]

Ne tak docela, protože když jsou v R, G a B odlišné struktury (a to prostě často jsou), tak ti to sigma clip hezky vyhází. Když ale uděláš součet R+G+B, tak výsledek vypadá (kromě šumů) prakticky identicky jako L, a po normalizaci žádný clipping nehrozí.

[mirkovacik]

Ahojte,
vie mi niekto toto vysvetliť?

Ľavý snímok je syntetické L-ko vytvorené z RGB snímkov (DSLR) a pravý snímok je tiež L-ko vyrobené z RGB snímkov ale s nasadeným UHC-E filtrom.

Je to zo zintegrovaného snímku, oba majú veľmi podobné podmeniky fotenia - oba cca. 270 snímkov, oba tie isté expozície, ISO, foťák. Ľavá časť bola pri teplote cca 19 stupnov, pravá cca. 6 stupnov. Fotené 2 dni po sebe z toho istého miesta v tom istom čase, čiže aj svetelné podmienky okolo podobné.

Na L-ku z UHC-E časti je významne väčší kontrast (pravá časť), viditeľnosť štruktúr. L-ko z čistých RGB (ľavá časť) je oveľa horšie.

Ale štatistiky zo subframe selectora sú v prospech L-ka z RGB. (Aspoň tak ja interpretujem čísla vo vyznačených stĺpcoch tabuľky.)

Prečo je pomer signál/šum lepší na tom L-ku, ktoré vyšlo z čistých RGB a nie na tom L-ku, čo je fotené s UHC-E?

Znamená to, že subframe selector nie vždy vie, čo je to signál a čo šum? Ale to by potom znamenalo, že váhy z tohoto nástroja sa nemôžu používať bez ďalšieho rozmýšľania do spracovania.

Uvedomujem si, že subframe selector dobre funguje na snímkach vzišlých z rovnakého spôosobu fotenia. A všetky RGB medzi sebou by vyhodnotil správne a všetky snímky fotené s UHC-E by vyhodnotil správne medzi sebou. A že problém bude porovnávanie jabĺk s hruškami - medzi snímkami s UHC-E a bez UHC-E filtra.

Alebo je niekde inde problém?

Pôvodne som myslel, že by som dal RGB snímky bez UHC-E filtra do integrácie s tými s UHC filtrom za účelom vytvorenia umelého L-ka, ale potom som si to rozmyslel, že asi to nie je dobrý nápad - pokaziť si to, ale táto diskusia ma nakopla, či by sa to predsa len nedalo použiť, ale zasa tento pokus mi vraví, že asi nie.

Mýlim sa? Dobre interpretujem hodnoty z Pixi nástroja? Alebo by sa predsa len nejako dalo zlepšiť L-ko vyrábané zo snímok s UHC-E filtrom pridaním snímok bez UHC-E filtra??

[Bill]

Prečo je pomer signál/šum lepší na tom L-ku, ktoré vyšlo z čistých RGB a nie na tom L-ku, čo je fotené s UHC-E?

No filtr část signálu odfiltroval, takže S/N je horší. Ten algoritmus nemůže vědět, co do obrázku patří...
Podle mne nejlepší je složit snímky focené stejným způsobem a pak výsledek "vyrobit" pomocí PixelMath...