Rychlý FITS prohlížeč

[Tomáš Grygarčík]

Přidal jsem kroky 5 a 500. Pamatování pozic bylo jen u šipek doleva a doprava, teď by si to měl pamatovat při každém vybraném souboru.
Linux | Windows
********************************************************
Palkog
Nezaneprázdněná vlákna teď uspávám na 5 ms. Těžko říct, jestli původních 1 ms bylo důvodem obrovského vytížení.
Protokol teď dělá přímo aplikace, a to do /tmp/zaznam.log
Taky by se mi hodil výstup z cat /proc/cpuinfo
upovídaná verze

[BiF]

Předem se omlouvám a stydím za hloupou otázku, ale co znamená to "Počet vláken"?

[Bill]

Mrkni třeba tady:
https://cs.wikipedia.org/wiki/Vl%C3%A1kno_(informatika)

[BiF]

Asi jasný, díky...

[Tomáš Grygarčík]

Počet vláken znamená, kolik paralelních úloh dokáže procesor zpracovat. Využívám to u přepočtu obrazovych dat, kdy výpočty rovnoměrně rozdělím mezi jednotlivá vlákna. Úspora času sice není lineární (10 vláken to neudělá 10× rychleji), nicméně u velkých objemů dat (třeba u 16Mpix 16bit snímků) je to vítané navýšení rychlosti.

[MMys]

Už je to parádně použitelné, nic zásadního tomu už nechybí.

Je tam ještě drobná chybička. Když načtu jeden snímek, nepřejdu na další, a na tom prvně načteném si popotahnu si výřez jinam, a pak hnu limity historamu, zresetuje se výřez do levého horního rohu (není zapamatovaný). Pamatuješ ho až při přechodu na další obrázek. Je třeba zapamatovat tu polohu ihned po popotažení výřezu, ne až se změnou snímku.

Ještě mě napadá jedna docela užitečná funkce. Když to zapnu s parametrem konkrétního souboru, jestli by se nemohly projednou spočítat černý a bílý bod pro ten první snímek a ty pak vzít jako výchozí nastavení historamu pro prohlížení celé sady. Tím uvidím, jak si stojí ostatní snímky proti tomu se kterám jsem začal. Jde mi o to že trefení optimálního nastavení historamu je trochu laborace s těmi šoupáky, když ty meze vůbec neznám. Tohle by to řešilo eleantně. Plus třeba možnost vyvolat ten auto-stretch i ručně tlačítkem na aktuálním snímku. Určení těch limitů asi přes percentil, nikoli absolutní min/max hodnoty, aby to ignorovalo extrémy (hotpixely, mrtvé černé pixely). Ty percentily buď vylaborovat nějak univerzálne a nebo udělat nastavitelné.
V MaxIm DL je rozumný horní percentil pro bílý bod 99.9 a dolní pro černý bod někde mezei 5-20%

[Tomáš Grygarčík]

Skrolování opraveno.
V kontextovém menu tlačítka limitů a v hlavním kontextovém menu je teď možnost "Automaticky roztáhnout histogram". Najde krajní hodnoty, které mají aspoň 1% zastoupení 1% nejvyšší nalezené hodnoty. Do startu aplikace se mi to dávat nechce, obzvlášť když si to ukládá do INI a bez ruční změny rozsahu si to pamatuje kdykoliv po spuštění.
Linux | Windows
********************************************************
Palkog
Nic moc mi to nepomohlo, tak ještě jedna upovídané verze zaměřená na vykreslování:
upovídaná verze

[MMys]

Jo, takhle to bohatě stačí.

[MMys]

A ještě dotaz. Jak resampluješ ten obraz při přizpůsobení do okna ? Tipoval bych, že pouze vezmeš nejbližší pixel původního obrazu, který odpovídá poloze po resamplingu, ostatní zahodíš ? Když tím prohlížím nějaké duchařiny (viz níže) tak je to dost zašuměné. Ale jde to zmenšit líp, jen nevím, jestli je to výpočetně průchodné a o kolik by se to zpomalilo, kdybys spočítal průměr pixelů, které po resamplingu tvoří ten výsledný. Jen nevím, jak se vypořádat s případy, kdy zmenšení není celočíselné. Asi nějakou interpolací.

Rozdíl v tom, co je tam vidět, je ale zančný. Stretchnutí jsem nastavil v obou SW stejně.

Mimochodem, stejně se při zoomování chová i Photoshop (čím je obrázek menší, tím je méně zašuměný - převedl jsem si to na TIFF a udělal pokus) a jde to velice rychle, i když v PS vypnu podporu GPU, takže to nějak jít musí.

FitsView_resize_method.jpg (1.9 MiB) Zobrazeno 2464 x

[/url]

[Bill]

No a co udělat rychlý náhled tak jak je a na pozadí udělat "opravdický"resample a pokud nebude do nějaké doby změna obrázku tak to přeplácnout kvalitnější verzi?

Na resampling musí existovat hotové knihovny - tady jsou názvy běžně používaných algoritmů:

Resample.png (7.51 KiB) Zobrazeno 2464 x

Nebo to zkusit rovnou - třeba to nebude taková CPU zátěž...

[MMys]

Jo, to by asi taky šlo, ale pokud to dělá ve více vláknech, podle mě to nemůže být problém. Teď jsem dělal v PixInsight pokus, zmenšení 16-bitového 16Mpix obrazu na 29%, výsledky jsou níže.

Vyrobil jsem si hnusně zašuměný obraz, který má σ = 1.135e-01 (rozsah obrazu je float 0 až 1)

A na něj zkusil různé algoritmy resamplinu:

Nearest Neighbor: 41ms, σ = 1.140e-01
Bilinear: 41ms, σ = 7.859e-02
Bicubic Spline: 53ms, σ = 9.555e-02
Lanczos-3: 236ms, σ = 1.035e-01
Lanczos-4: 162ms, σ = 1.038e-01
Bicubic interpolation, Mitchell-Netravali Cubic filter: 125ms, σ = 2.944e-02
Bicubic interpolation, Catmull-Rom Cubic spline filter: 150ms, σ = 3.565e-02
Bicubic interpolation, Cubic B-spline filter: 116ms, σ = 1.907e-02

Je jasně vidět, že ty základní metody bez filtrace moc nepomáhají, pokles šumu je spíš symbolický.
Nejlepší s ohledem na výsledný šum je zjevně ta poslední metoda, a ani není moc pomalá. Na klasické denní snímky sice obraz trochu rozmazává, nejvíc ze všech algoritmů co PI má (Mitchell-Netravali je na snímky s ostrými hranami výrazně lepší, a stále s výborným potlačením šumu) ale na surové zašuměné FITSy by asi byla výborná.

A tady na webu Pixinsight je k tomu i potřebná matematika:
https://pixinsight.com/doc/docs/Interpo ... ithms.html

[Tomáš Grygarčík]

Jak resampluješ ten obraz při přizpůsobení do okna ?

Používám to nejméně pracné: Canvas.StretchDraw(); a systém ať to přepočítá jak nejlépe umí. Do vlastního řešení mne zatím nic nenutilo.

[MMys]

Tím se to vysvětluje. Systém defaultně udělá Nearest neighbor
Zkus před Canvas.StretchDraw() přidat:

SetStretchBltMode(Canvas.Handle, HALFTONE);

což by mělo způsobit že se počítaný pixel naplní průměrem z bloku původních příslušných pixelů. Alespoň dle popisu GDI u Microsoftu
https://docs.microsoft.com/en-us/window ... tchbltmode
(a doufej, že na Linuxu jsou ty funkce obdobné).

HALFTONE
Maps pixels from the source rectangle into blocks of pixels in the destination rectangle. The average color over the destination block of pixels approximates the color of the source pixels.

After setting the HALFTONE stretching mode, an application must call the SetBrushOrgEx function to set the brush origin. If it fails to do so, brush misalignment occurs.

Nějaké další informace jsou i zde:
https://docs.microsoft.com/en-us/window ... caling-use

Systém by to určitě měl umět i kvalitněji. No uvidíš. Pokud tohle nepůjde, tak leda napsat vlastní. Není to samozřejmě priorita, i tak je to parádní kousek SW, ale kdyby ses nudil

------------------
V extrémním zjednodušeném případě stačí obraz před zmenšením přefiltrovat nějakým jednoduchým filtrem (třeba tím průměrem) na bloku pixelů o velikosti přibližně poměru zmenšení (nebo nejbližší větší hodnoty) a teprve pak aplikovat StrecthDraw() úplně stejně jako nyní. Ale to už jsi stejně skoro jako kdybys psal vlastní interpolaci.

[Tomáš Grygarčík]

HALFTONE pomohlo (na Linuxu to není implementováno, protože WinAPI... ).
Linux | Windows

********************************************************

Palkog
Je to jen zoufalý pokus, ale zkompiloval jsem to v GTK2:
GTK2 neupovídaná verze

********************************************************

KpS
Ten soubor mi dal zabrat! I když jsou to celočíselná 16bit data, tak kvůli posunuté nule a nenulové škále se interně zpracovávají jako 32bit desetinná. Asi třetinu aplikace jsem musel přepsat. Čekal jsem, že jednou na nějaký takový případ narazím, ale nečekal jsem to až tak pracné.

[KpS]

Velký dík Tomášovi za fits_prohlížeč a za vyřešení komplikací, které způsobil jeden můj zaslaný fits. Vznikl v Iris, který používá signed 16 bits.