Rychlý FITS prohlížeč

[MMys]

No trošku kostrbaté to je, ale asi 5x rychlejší (na 16Mpix mono FITSech). Nicméně to zrychlení je jenom v tom překreslení, v praxi to skoro není poznat, protože převážnou většinu prodlevy při přechodu na další snímek tvoří načtení z disku. I když to je SSD-čko (byť nijak extrémně rychlé). Na plotnovém disku to nelze poznat prakticky vůbec (rozdíl je u mě nějakých 80 vs. 15ms na vykreslení).

Jak to necháš na WIN je mi celkem jedno, použitelné je obojí, reálný rozdíl při procházení adresáře u mě na hraně detekovatelnosti. A stejně se to po prodlevě dointerpoluje hladce. Ale ten starší režim je o trošku hezčí i před vyhlazením.

[astar]

Poznámka:
Toto měření krátkých česových úseků je zatíženo chybou cca 16msec alespoň pod Windows . Není rozdílu mezi funkcemi New() a Gettickcount. Čásové úseky pak rostou cca právě po těch 16 msec . Alespoň co jsem se dočetl , tak obnovovací frekvence čtení systémového času ve W je 1/60 sec . Další věc co ovlivňuje trvání je běh dalších procesů na pozadí . Tak se musí brát ty krátké časy hodně z rezervou .

[pavelseb]

astar: no to asi nebude úplně pravda v pohodě se dají měřit milisekundové operace
Je pravda že nevím jak přesně to myslíš (možná nějakou konkrétní funkce), ale například v C# pomocí aktuálního času v pohodě na jednotky ms.

[nou]

astar ma na mysli GetTickCount ktory naozaj presnost 10-16ms.

[Tomáš Grygarčík]

GetTickCount už dlouho nepoužívám, jednoduchý čas si počítám sám ze systémového Now(). Přesnější měření dělám z fpGetTimeOfDay (Now() na Linuxu z něj vychází a pouze zaokrouhluje) a na Windows z QueryPerformanceCounter + QueryPerformanceFrequency a časy vychází stejně, akorát s mikrosekundami.

[astar]

Omluva : Ve vlastním fit prohlížeči jsem zaměnil proměnné při zobrazování (i a l -blbě zvolené ) , tak jsem neustále zobrazoval hodnotu přes GetTickCuont a tedy nezjistil rozdíl , proto jsem o tom napsal. Člověk někdy kouká a nevidí to co má před očima .
Jak napsal Martin, je to bezvýznamné v případě plotnového disku . Načtení 23 MB souboru pak trvá cca 170-220 msec .

Jinak v mém programu přepočet zobrazení velikosti 1600-1000 pix trvá 12-20 (předtím 16 nebo 32) msec z fitu 23MB.

[Tomáš Grygarčík]

Omluva : Ve vlastním fit prohlížeči jsem zaměnil proměnné při zobrazování (i a l -blbě zvolené )

Jeden z důvodů, proč jsem C a všem jeho příbuzným nikdy nepřišel na chuť. Zlatý Pascal.

Upravil jsem podmínku, že se zmenšuje n-násobně, až když je obraz n-násobně menší, předtím se zmenšoval víc a následně trochu roztáhl, bylo to rychlejší, ale kostičkovanější.
Trochu jsem si hrál s nastavením optimalizací napříč všemi platformami, kdyby to někomu nešlo spustit, či házelo chyby (neplatná instrukce apod.), dejte vědět.

Došlo mi, že to dělám hlavně kvůli sobě. Já ten program používám přímo při focení v terénu na pomalém notebooku, kdy si data prohlížím a neustále měním nastavení histogramu pro optimální zobrazení. Data už jsou v paměti, načítání z disku neřeším, pouze je přepočítám a zobrazím, a proto je mi příjemnější, když se překreslí 4× až 5× rychleji (protože přepočet zabere stále stejnou dobu).

[astar]

Tomáši, taky jsem na tom stejně , C mi nějak nepřirostlo k srdci . Používám staré Delphi nebo někdy Lazarus a to pokud ty Delphi neumožňují . Jasně nejsem profík jako ty ,jen samouk. Pro větší rychlost některých výpočtů pak používám i assembler.

[MilAN]

Došlo mi, že to dělám hlavně kvůli sobě. Já ten program používám přímo při focení v terénu na pomalém notebooku, kdy si data prohlížím a neustále měním nastavení histogramu pro optimální zobrazení.

Tomáši, a tobě tohle neumožňuje dělat přímo program , ve kterém fotíš ?
Vím, že třeba Fire Capture ani CCDOPS neumožňuje práci z právě nafocenými obrázky přímo. Já používán kamery ATIK , a tam při snímání mohu celou dobu během expozice dalšího obrázku si při prohlížení dělat cokoliv- prostě ideální pro EAA

[Tomáš Grygarčík]

Na snímání jsem si napsal vlastní aplikaci už v roce 2014, a to hlavně na snímání planet. Když jsem si pořídil ASI1600MM, k mému zděšení to s dlouhými expozicemi moc nekamarádilo, přece jenom u videa se jede na kvantitu, než na kvalitu. Časem jsem dodělal spoustu maličkostí okolo, aby to fungovalo, nicméně je to nabalování nových věcí na staré jádro. Radši bych to napsal znovu od nuly, avšak se současným rozsahem aplikace (zhruba 13000+ řádků kódu) by to trvalo nepříjemně dlouho.

Momentálně je pro mne jednodušší snímat v jedné aplikaci a detailně kontrolovat v druhé.

PS: napsal jsem si vlastní, protože to, co bylo tehdy na Linuxu k dispozici, buď nefungovalo, anebo to bylo nedoladěné, anebo to původně nebylo pro astro a chyběly důležité funkce.

[Tomáš Grygarčík]

Tomáši, a tobě tohle neumožňuje dělat přímo program , ve kterém fotíš ?

Už mi to umožňuje. Trvalo to asi dvě hodiny i s odladěním. Na procházení snímků v terénu se stejně nevyhnu použití prohlížeče.

[Tomáš Grygarčík]

Už nějakou dobu jsem v hlavě nosil myšlenku na pěknější škálování obrazu, dnes jsem to spáchal:

Windows 64bit
Linux x86_64
Windows 32bit
Linux ARMv7
Linux ARMv8 (aarch64)

V horní liště jsou teď na výběr tři možnosti ke srovnání, výchozí je ta nově naprogramovaná:

• Původní
  nativní systémové vykreslení
• Nové jednoduché
  vynechávání pixelů, nejrychlejší a nejošklivější
• Nové komplexní
  výsledný pixel se počítá zprůměrováním pixelů (které v předchozí metodě vynechávám), navíc je to paralelizované, kvalitou se to blíží hladké interpolaci, u mono fotek s bayerem stále tvoří mřížku, na slabších procesorech to dá zabrat

Opravil jsem i měření času, občas tam lítala 1 vteřina.

[MMys]

U mě vše chodí, nové škálování nenechává ve více stretchnutém obarzu tmavé pixely v šumu, je to pěkně vyhlazené.

[palkog]

Zobrazuje sa to pekne. Vyrazny je aj rozdiel v rychlosti. Osobne by som tam nechal komplexne aj jednoduche vykreslovanie. Niekedy je podstatnejsia rychlost ako kvalita zobrazenia.

Este mam jeden navrh ku zobrazovaniu informacii z raw suborov. Aspon polovica hodnot je u mna prazdna (raw z Canon). Mozno pri inej znacke fotaku sa zobrazuju aj ine informacie. Nebolo by mozne nezobrazovat tie prazdne hodnoty? Bolo by to prehladnejsie.
Tiez mi v tych informaciach chyba ohniskova vzdialenost.

[Tomáš Grygarčík]

Pozměnil jsem terminologii způsobu vykreslení podle toho, co to vlastně dělá. Přeskakování pixelů jsem taktéž paralelizoval, protože proč ne? Vybraná volba se ukládá do INI.
Pohledal jsem něco sofistikovanějšího na čtení EXIFu a nyní se zobrazuje jen to, co se ze souboru přečte.

Odkazy na testovací sestavení:

Windows 64bit
Linux x86_64
Windows 32bit
Linux ARMv7
Linux ARMv8 (aarch64)