Stránka 16 z 31

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

Napsal: 22. 04. 2019, 11:26
od Psion
Já měl namysli import a debayering RAW do Adobe. Pamatuji, že i import RAW ze Sigma foťáků byl velmi pomalý.

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

Napsal: 13. 05. 2019, 20:48
od Tomáš Grygarčík
Měl jsem obrovskou nechuť programovat. Velice pomalu jsem se prokousával implementací zobrazení náhledů a už lze v dialogovém okně určit, jestli se chcete podívat na surová data či uložený náhled. Jedinou vadou na kráse je striktní zobrazení náhledu na šířku, tak doufám, že na astro to nikomu nebude vadit. Dialogové okno se zobrazí jen při zobrazení RAW souboru, u FITu zase zmizí. Umístěné je nahoře vedle histogramu.

Načtení náhledu je rychlejší, jenže někteří výrobci ukládají náhled v plném rozlišení, takže s tou rychlostí to při 20+ MPix snímku není zas tak super.

Linux x86_64 http://grytom.g6.cz/fits/raw/fits_prohlizec.tar.gz
Windows x86_64 http://grytom.g6.cz/fits/raw/fits_prohlizec.zip

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

Napsal: 04. 06. 2019, 18:30
od Cztwerec
Ahoj Tomáši, děkuju moc za prohlížeč, pomohl mi vybrat špatné snímky! Je to díky tobě opravdu rychlé. Debayeroval jsem fity pomocí matice RGB v Maximu na barevné fity. Nemohu je ve tvém prohlížeči otevřít. Znamená to, že musím nechat v původním surovém formátu bez debayerizace? Asi jsem to přehlídnul, nebo to tak prostě je? Prostě jsem to tak potřeboval udělat...

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

Napsal: 04. 06. 2019, 20:10
od Tomáš Grygarčík
Barevné (vícevrstvé) FITy nejsou podporovány tou komponentou, kterou k jejich načítání používám. Už jsem uvažoval, že ten debayer nějak spáchám, ale poslední měsíc opravdu není chuť cokoliv programovat. :oops:

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

Napsal: 04. 06. 2019, 21:39
od Cztwerec
Úplně v pohodě Tomáši a opravdu děkuji!

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

Napsal: 21. 07. 2019, 17:24
od Tomáš Grygarčík
Trocha oprav a záplat, například proti souborům se zápornými hodnotami: http://grytom.g6.cz/fits/

Je tady někdo, kdo by to chtěl používat na 32bit Windows? :?:

U ARM verzí jsem se pokusil o přepsání nejčastěji volané funkce do ASM a dosáhl jsem akorát tak zpomalení, takže stále bez optimalizací. Nicméně všiml jsem si jedné zásadní vlastnosti - na stejném HW (Raspberry Pi 3) je ARMv8 (64bit) verze ve výpočtech dvakrát rychlejší, než ARMv7 (32bit). :idea:

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

Napsal: 21. 07. 2019, 20:45
od zuzi
A čím to že po přepsání na ASM to je pomalejší, že jsou kompilátory tak moc pěkně už optimalizované, že rukama to v ASM nejde líp?

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

Napsal: 21. 07. 2019, 20:52
od Tomáš Grygarčík
I tomu procesoru nějakou dobu trvá, než zapíše 64bit číslo do vlastního registru. Tím, že jsem pracoval se stále menší oblastí registru (16bit namísto plného 64bit) se mi podařilo v jedné aplikaci docílit výrazného zrychlení práce. U ARMu jsem včera poprvé spáchal funkční ASM kód pro ARMv8 a dnes i pro ARMv7 (oba se trochu liší! :shock: :x ), takže zatím pracuju s celými registry.

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

Napsal: 21. 07. 2019, 20:58
od Bill
zuzi píše:A čím to že po přepsání na ASM to je pomalejší, že jsou kompilátory tak moc pěkně už optimalizované, že rukama to v ASM nejde líp?
Jo tuhle hru jsem kdysi taky hrál - samozřejmě, že člověk to nakonec v tom asembleru dá rychleji, ale je to náročné a nejlépe když člověk od překládače trochu opisuje...

Jenom takový příklad (obecný) - desítky let starý turbopascal:

2*x překládač x+x
3*x překládač x+x+x
4*x překládač x+x=y, výsledek = y+y ...

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

Napsal: 21. 07. 2019, 21:06
od Tomáš Grygarčík
Bill píše:a nejlépe když člověk od překládače trochu opisuje...
Bez toho by to nešlo :lol: právě takhle jsem hledal, kam assembler ARMu zapisuje výsledek funkce, protože makro "__result" je platné jen pro AT&T dialekt x86/x86_64.

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

Napsal: 22. 07. 2019, 08:51
od hades
Tome, díky za tvou práci

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

Napsal: 22. 07. 2019, 11:27
od astar
Bill : už si nepamatuji jak to bylo v Trubopascalu (taky jsem jej používal) ale teď v Lazarusu pokud napíši v ASM násobení , tak musí být násobení i ve výpisu . Obzvlášť 4*x bude rychlejší než x+x+x+x , jedna instrukce proti čtyřem . Nezjistil jsem rozdíl v rychlosti mezi instrukcí násobení a sčítání .

Tomáši ,nebude to ve vzdáleném volání procedury v tom ASM ? Jak to dělá klasický překlad ?
Taky jistý přínos je uchovávat hodnoty co nejvíce v registrech ( opakované čtení) a vhodnou skladbou příkazů . Mně to pomohlo ve zrychlení (jiný program optika) o 20 -30 %.
Př. dělení des.čísel trvá dlouho , tak hned nepožadovat výsledek pokud mohu provést příkazy jiné , načtení nebo přesun hodnoty do jiného registru a pod a pak zpracovat výsledek dělení . To ty jistě znáš . :)

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

Napsal: 22. 07. 2019, 14:29
od Tomáš Grygarčík
Celočíselné násobení a dělení beze zbytku jde udělat krásně jednou instrukcí shl / shr. A to ani nemusí být v ASM.
Ta volaná funkce porovnává, jestli se vypočítaná hodnota pixelu vejde do rozmezí 0-255. Právě tam pracuju pouze s 8bit délkou registru.

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

Napsal: 22. 07. 2019, 16:13
od astar
Nechci nijak radit , jistě jsi zkušenější programátor. Pokud se jedná jen o porovnání , rozhodnutí - skok, tak bych nevolil volání funkce = Call xxxx v ASM ale rovnou to napsal na místo . Zvětší se velikost exe , ale bude to rychlejší. Instrukce Call taky trvá nějakou dobu .
Spíše pro ostatní . Instrukce SHL a SHR jsou vlastně posuvy registru a jde o celočíselné násobení, dělení 2,4,8,16 ... . Při násobení lichým číslem to nejde použít a musí se použít instrukce IMUL AL,3 nebo AX, EAX, RAX ( 8,16,32,64bit registr).
To už sme ale někde jinde :)

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

Napsal: 22. 07. 2019, 22:20
od Tomáš Grygarčík
Pár zjištění pro dnešní verzi:
1.) Free Pascal nepodporuje inline funkce s kódem assembleru, takže vždy dochází k volání mých funkcí napsaných v ASM :evil:
2.) ASM kód vložený přímo do funkce místo volání byl stejně rychlý, jako inline funkce bez ASM. Psal jsem to tedy zbytečně. :(
3.) sloučil jsem dvě volané funkce do jedné a trochu upravil další věci, což u mě mělo za následek o 3 až 5 milisekund rychlejší zpracování (z 18 ms na 13 ms), na notebooku o kolosálních 30 ms (160 ms před a 130 ms po úpravě)! :o
4.) 32bit verze je dvakrát pomalejší i na Windows :?:

TL:DR: zrychlil jsem to

http://grytom.g6.cz/fits/