Astronomické fórum

Mně to na 64bit Win10 zatím nefunguje vůbec, stále jen černé okno A to ani s mými Nikon NEF soubory, tak ani tady s kolegovým (palkog) CR2, na který sem dal odkaz... Veškeré Visual C knihovny bych v systému mít měl...

Na Linux Mint 19.1 jsem v prvním případě končil s hláškou - nepodporovaný, poškozený soubor - i když knihovny s verzemi libraw v systému jsou. Aktualizoval jsem libraw na poslední verzi LibRaw-0.19.2 , k tomu ještě libgphoto2 a fits_prohlížeč začal rawy načítat - stařičké snímky ještě z EOS 300D (*.CRW) zobrazuje správně, z EOS 450D, 500D, 1000D (*.CR2) vše pruhované viz. příspěvek #206.

Suhlasim s Aletelom - Linux Mint 19.1 + raw z Canon 600D = farebne pruhy.

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.

Aletel: libgphoto to nevyužívá. Kompiluju to s verzí libraw 0.18.9-Release.

Dávám k dispozici ukecaný program, který pracuje čistě s libraw a vytvoří TIF přímo pomocí interní funkce. Soubor se uloží vedle otevřeného souboru pod stejným jménem. Pro kontrolu koukněte i na něj.
Nekonzistence rozměrů obrazu se mi projevuje pouze u testovacího rawu Nikonu D850 staženého z DPReview, u všech ostatních problém nemám, a to ani s 80MPix HiRes snímkem Olympusu. Časově nejnáročnější jsou pouze snímky od Fujifilmu, kvůli jejich bayerově masce.

Lin 64b [url]htp://grytom.g6.cz/fits/raw/zobrazeni.tar.gz[/url]
Win 64b [url]htp://grytom.g6.cz/fits/raw/zobrazeni.zip[/url]

Oprava adresy
Lin 64b http://grytom.g6.cz/fits/raw/zobrazeni.tar.gz
Win 64b http://grytom.g6.cz/fits/raw/zobrazeni.zip

PS: našel jsem doma počítač, kde to nefunguje, tak to nemusíme ladit na dálku.

Poznatek #1: ve Windows ta knihovna neumí otevírat soubory s diakritikou (cesta k souboru, název souboru), mezery nevadí
Poznatek #2: pruhy se vyskytují u souborů s lichým počtem sloupců, u FITS souborů to mám ošetřené, u RAW ještě ne

Tomáš Grygarčík píše:Poznatek #2: pruhy se vyskytují u souborů s lichým počtem sloupců, u FITS souborů to mám ošetřené, u RAW ještě ne

Jen aby nedošlo k mýlce a zbytečnému laborování, je to přesně naopak - sudé řádky pruhují, liché jsou zobrazením v pořádku.
Potřebuji nakopnout, jak spustit ukecanou verzi "zobrazeni" pro linux? Vyzkoušel jsem, co kdy zabralo, ale jsem ve slepé ulici.

Diakritiku jsem obešel přes buffer, který předávám knihovně, takže otevírat by se mělo všechno.
Pruhy se mi dělaly jen na Windows, zjistil jsem totiž, že alokovaná paměť u RGB bitmapy zabírá nesmysly, po nastavení formátu RGBA už to funguje.

FITS prohlížeč:
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

Strohý RAW prohlížeč:
Linux x86_64 http://grytom.g6.cz/fits/raw/zobrazeni.tar.gz
Windows x86_64 http://grytom.g6.cz/fits/raw/zobrazeni.zip, libraw.dll stáhněte z fits_prohlizec.zip

Akorát ty NEFy na výšku jsou občas problém.

Aletel: jádro problému bylo v šířce snímku.

No tak nic, odstranil jsem jiné pruhy, ale co je důležitější, už dokážu nasimulovat vámi všemi popsané horizontální pruhy. Chyba je někde v rozdělení dat mezi vlákna.

Jestli to na Linuxu nejde spustit, spusťte to z terminálu. Jestliže to napíše chybu "undefined symbol: QTextEdit_setPlaceholderText", pak je zapotřebí aktualizovat knihovnu Qt5Pas1 na verzi 2.0.2.

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

Znovu jsem překopal rozdělení zátěže na jednotlivá vlákna a prozatím jsem nenarazil na jediný problém. A NEFy začaly taky spolupracovat.

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

U mna sa to teraz zobrazuje v poriadku.

Taky vše funkční. Dobrá práce Tomáši.

Na CR2 z 40D to funguje teď pěkně. Jen se to trochu courá, ale to hold tak už je Díky za super minimalistický a univerzální soft!

U mě už nyní chodí. Testováno na NEF a CR2 z různých foťáků. Jen mě zaráží rychlost (tedy spíš pomalost). Přepočet dat se vždy vejde do 100ms, to by bylo v pohodě a pochopitelné. Ale NEF, co má 34MB se načítá asi 7-8sec. zatímco FITS, který má srovnatelných 32MB, je načtený ani ne za sekundu (a přepočet dat je 22ms, což chápu, fits je mono, není tam debayering a podobně).

Oba porovnávané soubory mám vedle sebe na SSD, a proto mi to hlava nebere. To těch 8 sec. trvá ten debayering v knihovně ? To je jediný rozdíl. Možná by nebylo od věci povolit prohlížet i monochromatická RAW data. Stejně jako tomu je u OSC kamery. Dát zaškrtávátko Debayer RAW. Pokud by nebylo pooleno, fungovalo by se s tím jako s FITSy s bayer maskou. To funguje výborně.

LibRAW toto určitě umí (vypnout debayering), protože LibRAW používá i PixInsight, a tam RAWy lze otevřít jako Pure RAW.

Mě to samé zarazilo u Adobe Lightroom, RAW z Canonu je mžik, některé jiné RAW z ostatních přístrojů je někdy utrpení.

Já už jsem to tady říkal, ale zapadlo to. Prohlížeče Canon Raw používají pro náhledy běžné vestavěný jpg.