Rychlý FITS prohlížeč - nezná někdo ?

[nou]

Narazil jsem na jakousi nekonzistenci, kdy mi libraw občas u snímků na výšku vrátí rozměry na šířku, což způsobí totální rozbití obrazu (a interní ukládání do tiffu je správně!), ale na pruhy jsem nikde nenarazil.

Je este toto problem? V libraw_output_params_t treba nastavit user_flip=0 pretoze default -1 to otaca podla flagu v RAW subore ktory nastavil fotoaparat podla orientacie v dobe fotografovania.

[palkog]

Vsimol som si jeden problem pri zobrazovani raw. Ak zobrazim nahlad a dam zapamatat nastaveni histogramu, tak pri prechode na iny subor sa zmeni nastavenie na: tiene=0, jasy=1. Automatika ide dobre aj zobrazenie surovych dat. Mozno nejaky problem so zaokruhlovanim pre maly rozsah hodnot...

Este doplnim, ze ide o raw z Canonu.

[Tomáš Grygarčík]

Je este toto problem?

Není, odstranil jsem to už dávno. Chyba byla v rozdělaní práce výpočetním vláknům.

pri prechode na iny subor sa zmeni nastavenie na: tiene=0, jasy=1

Měl jsem tam natvrdo převod z 16bit rozsahu. Opraveno.

Schrastil jsem jednoduchý kód na čtení EXIFu z JPEG a náhledy z RAWů už po načtení automaticky otáčím. EXIF se rovněž zobrazí v pravém sloupci s hodnotami. Funkčnost je nutno vyzkoušet na širším vzorku souborů.

Dále jsem upravoval různé části programu, takže pozor na nové chyby.

[Tomáš Grygarčík]

Narazil jsem na memory leak při načítání EXIFu z náhledu v RAWu. Neměl by mít vliv na funkčnost, přece jenom jsem to zjistil až po měsíci, co jsem to zakomponoval. Sem-tam drobná oprava a trochu ušetřené RAM, což je užitečná leda tak na Raspberry Pi.

[MMys]

Vím že jsi na začátku psal, že to dělat nebudeš, ale on se z toho stal tak dobrý SW, že by si to fakt zasloužilo. To o čem mluvím je možnost nelineárního stretchnutí. Nevymýšlel bych nic zbytečně složitého, musí stačit jednoduchá gama korekce. Tedy zachovat nastavení černého a bílého bodu, prostě vše jak je nyní, akorát to v tom intervalu dovolit stretchnoud dle potřeby více či méně exponenciálně. Přidat nastavení jednoho gama koeficientu.

Z důvodu rychlosti by se to asi muselo realizovat dopředu předpočítanou lookup tabulkou (ta by se přepočítala vždy jen při změně gamma koeficientu a černého a bílého bodu). Na 16-bitové FITSy by to bylo velmi jednoduché, prostě vstupní lineární data by fungovala jako index pole lookup tabulky. S float fitsy je to horší, tam už by byla tabulka nesmyslně velká, tam by se to už asi muselo počítat napřímo. A nebo to nejprve překlopit do 16-bitů a pak teprve aplikoavt gamma korekci, ale to může vést k posterizaci, vzniku skvrnek a map u float fitsů, kde je většina informace uložena ve spodku histogramu.

[Tomáš Grygarčík]

Linux 64b | Windows 64b | Windows 32b

V této testovací verzi se po kliknutí na histogram otevře nové okno s možností naklikat si body a udělat si vlastní lineární křivku. Levým myšítkem se body přidávají, pravým mažou. Lze je volně přetahovat. Aplikace na obraz se provede až po kliknutí na tlačítko Použít. Výpočet mezi body je lineární, kdo to chce hladší, ať si křivku nakliká (až 256 bodů).


Varování:
Zatím jsem to moc extra neladil, je to první verze, kde mi to nehlásilo chyby. Nastavením táhel na hlavním formuláři (třeba automatikou) se naklikané body smažou. Body se po ukončení aplikace neukládají. Zpětně občas nesedí krajní hodnoty na táhlech na hlavním formuláři. Hrejte si s (polámanou) křivkou a dejte vědět, jestli jdu správnou cestou.

[MMys]

Vyzkoušel jsem na různých snímích. Jo, funguje to, akorát je to zbytečně těžkopádné, stejně to ve finále stačí aproximovat třemi úseky.
Osobně bych to okno s převodní charkteristikou vůbec nedělal, přijde mi to jako zbytečná komplikace (a ještě s nedostatkem, že bod nejde dát myší až hodně do levého kraje, některé fitsy to vyžadují, jinak tam není moc vidět)

Já bych šel cestou, kdy se černý a bílý bod určí pomocí nastaveného percentilu, naprosto beze změny. To funguje excelentně, na to nesahej. Jenom bych pomocí jednoho šupáku nebo boxu pro nastavení čísla udělal tu převodní charakteristiku v intervalu mezi černým a bílým bodem (tak jak je aktuálně nastavený, ať už automatem nebo ručně) nelineární, nejlépe exponenciální, prostě klasická gamma korekce:

http://xahlee.info/img/what_is_gamma_correction.html

Tedy křivku ovlivněnou jedním exponentem, s hodnotou 0 až 1 (nebo nějakých 0.001 až 1). Takto by převodní křivka vypadala mezi černým a bílým bodem. Před černým by byly v LUT tabulce samé nuly, za bílým bodem zase samé 1 (nebo jinou hodnoty místo té 1, nevím jak to počítáš konkrétně)

Na ladění křivky už máme photoshop, nebo Pixinsight. To mi jde v téhle aplikaci tak nějak proti celé její filozofii, tam něco ručně tvarovat. Ten jeden gamma koeficient musí bohatě stačit. Stačí v SIPSu (od Moravských přístrojů) i v Pixi.

M.

[Tomáš Grygarčík]

Linux 64b | Windows 64b | Windows 32b

Okno s křivkou jsem odstranil a místo něj jsem přidal nové zaškrtávátko "Gamma" a vedle něj kýženou hodnotu. Dělám to přes 16bit LUT, počítat to přímo bylo fakt příšerně pomalé (18 ms -> 180 ms ). 8bit data násobím $FF, 32bit (a více) přes shr řežu na 16bit. Stav a hodnota se zatím neukládají.

[MMys]

Naprosto super. Prolezl jsem s tím nějaké svoje sady snímků a je to přesně to co tomu chybělo. Díky

Ještě to budu testovat. Myslím že tam zatím můžeš dodělat, asby si to tu gammu a stav zaškrtávátka pamatovalo.

[zuzi]

A mě by se líbilo tahátko místo klkátka, ale to už je opravdu drobnost Je to parádní kus sw!

[Tomáš Grygarčík]

Nemusí se klikat, může se rolovat kolečkem myši.

Jestli má někdo 8bit snímky, byl bych rád za vyzkoušení, jestli v obraze nedochází k jasovým artefaktům (kvůli převodu na 16bit).

[MMys]

Nemám, ale pár jsem si jich vyrobil a i na 8-bitové FITS-y gamma korekce zdá se funguje normálně.

Ještě vyzkouším 32-bitové, s informací uloženou někde hluboko dole u začátku histogramu, jestli převodem do 16-bitů před aplikací LUT nevzniká nějaká posterizace.
---------------
edit - jo, i 32-bit float fits se chová mravně, klidně bych to vypustil jako ostrou verzi.

[Tomáš Grygarčík]

U 16bit nic neřeším, 32bit (a více) má informací habaděj, ale 8bit... tam je toho přeci jen málo. Na druhou stranu, kdo by fotil do FITu pouze v 8bit hloubce, že?

[MMys]

8bit data násobím $FF - jasně, to nic nezpůsobí, ale 8-bit FITS asi fakt nikdo neprovozuje, a navíc je to OK.

32bit (a více) přes shr řežu na 16bit - pochopitelně před plikací LUT, předpokládám. Zde právě hrozí malé riziko, že když uřízneš nejnižší bity, ale zároveň v těch bitech budou uložené jemné odstíny (typicky snímky DSO seskládané z 16-bit int FITSů do výsledného 32-bit FITSu), tak o ně tou bitovou rotací přijdeš, a následně po aplikaci gamma korekce může vylézt posterizace, mapy v obrázku se stejným jasem.

Ale zatím jsem nic takového nepozoroval. A navíc ten SW se primárně používá pro prohlížení nasnímaných dat (alespoň u mě) a tam nic takového nehorzí.

[Tomáš Grygarčík]

Ořezávám až po výpočtu hodnoty pixelu dle nastavení histogramu, předtím jsem to řezal přímo na 8bit výstup pro zobrazení, teď na 16bit pro LUT a teprve korigovaný výstup oříznu na 8bit data pro zobrazení.

Dodělal jsem ukládání a zkompiloval také pro ARM a ARM64.