Dotaz: Více vláknový prohlížeč PDF.

[lertimir]

Pokouším se pracovat s plány návrhu Metropolitního plánu Prahy, používám Okulár a bohužel i když mám 8 volných jader používá jedno, a potom práce z grafickými plány je utrpení. Trvá mnoho desítek sekund než system zareaguje na otevření, zoom, přesun. Neznáte nějaký vícevláknový prohlížeč, který by to zrychlil.

Odpovědi

[Max]

"Intel(R) Core(TM) i7-6700" + "Nvidia GTX 960" + 16GiB ram a nemám s tím problém. Jen na otestování jsem zkusil "O_03_Vykres_predpokladanych_zaboru_ZPF_01.pdf" - 300MiB a další (i 500MiB pdf) z balíčku "2.2_Graficka_cast_oduvodneni_2.zip" a nepozoruji tebou popsané prodlevy.
Jen občas během zoomu mám bílou obrazovku, ale po přiblížení se vykreslí relativně rychle (cca 1s)
Taktéž používám Okular.
Zdar Max

[lertimir]

Tím to bude. Mám 8 jádrový AMD (ne Ryzen). A Intel je na 1 vlákno významně výkonnější než ty starší AMD.

[Max]

A jseš si jist, zda je to CPU? Není to třeba chyba u GPU? Jde o to, že grafická karta s podělanýma driverama má za následek to, že jde grafický výkon do háje a CPU na 100%.
Zdar Max

[Max]

V práci mám :

Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz
Intel Corporation HD Graphics 630 (rev 04)
16GiB DDR4

A cpu na 100%, zoom se moc nehýbe atd. Už je to problém, takové pdf prohlížet.
Z toho usuzuji, že spíš než na problém CPU by to mohl být problém GPU/ovladače na grafiku.
Zdar Max

[pc2005]

Jako že chybný drivery zpomalujou vykreslování aplikace, ale samotný PDF jede rychle? To se dá otestovat pomocí pdftopng.

[Filip Jirsák]

Proč si myslíte, že by to vícevláknový prohlížeč zrychlil? Nemyslím si, že by PDF prohlížeč dělal operace náročné na CPU. Řekl bych, že důležitá je spíš velikost RAM.

[OldFrog {Ondra Nemecek}]

Proč si myslíte, že by to vícevláknový prohlížeč zrychlil? Nemyslím si, že by PDF prohlížeč dělal operace náročné na CPU. Řekl bych, že důležitá je spíš velikost RAM.

Nevím sice, zda lze stránku pdf renderovat vícevláknově, ale složité vektorové pdf dá CPU spolehlivě zabrat.

[Filip Jirsák]

Není lepší složité vektorové PDF vykreslovat pomocí GPU?

[OldFrog {Ondra Nemecek}]

Chtěl jsem tím říct jen to, že to může být výpočetně náročné. Jedno, zda na CPU nebo GPU (i když GPU na tom bude asi lépe vybavené).

[lertimir]

Mám 24GB na desktopu a 8GB na notebooku. Vše na SSD, desktop na SATA, notebook na NVMe. pamětí to asi není. Ale ty 300MB PDF, které mají jednu stránku výkresu, (patrně vektorově napanou a vše se počítá) se mi rendrují dost pomalu.

[pc2005]

Aha, tak jestli chceš renderovat PDF, který má jen jednu stránku a PDF je velký 300MB, tak RIP . S 300MB má můj komp problém už ve formátu raw bitmapy (~80 Mpix, 8kx10k), natož kdyby to byly jen popisující data vektorového výkresu.

A chceš z toho i něco kopírovat, nebo jen prohlížet část po části? Možná by bylo efektivnější si ten pdf předkonvertovat do png obrázku (docela by mě zajímala výsledná velikost ).

[lertimir]

tiskli jsme to. Jsou to A0,

[lertimir]

A co s tím chci dělat. Primárně tomu porozumět. A nasledně zpracovat námitky k problematickým částem území. Což je zpousta posouvání a prohlížení, Přecházení mezi jednotlivými místy, legenda je na výkresu dole, takže po výkkresu dost běhám.

[Petr Šobáň]

A co si to otevřít dvakrát?

Jedno okno s legendou a v druhém se budeš pohybovat a potom posun pouze o kousek nemusí být tak náročný.

[lertimir]

zkusím.

[pc2005]

Hmm takže view only? Tak to bych asi nejdřív renderoval do bitmapy teda. Koneckonců poppler přesně tohle dělá. Ještě bys mohl napsat vlastní viewer, který by vždycky přigeneroval obdélník který vznikne při posuvu stránky. Měla by to být metoda displayPageSlice z třídy PDFDoc v headerech /usr/include/poppler/PDFDoc.h. Mám základní skeleton kód, kdybys chtěl poslat, ale je to prasárna a ty obdélníky bys musel dodělat :-P.

[Aleš Kapica]

Jo bohužel dnes je taková doba, že pokud chceš aby ti něco fungovalo pořádně, tak nezbývá než si to udělat sám. A netýká se to jen softu, ale prakticky všeho. Kamarád učitel na ZŠ si takhle od píky musel vybudovat barák, protože každý co mu na něm dělal akorát zkurvil materiál. A kamarádka coby vystudovaná veterinářka budující si soukromou praxi je na tom obdobně - hrubá stavba se konečně byť se zpožděním chýlí ke konci, tak aktuálně sbírá znalosti ohledně strukturované kabeláže.

[lertimir]

No rozměrově je to specifikované 1505mm x 1505mm. když bych to nechal vyrendrovat na 600dpi dostanu 35551x35551 pixelů. ale zatim nevím, co použít, aby výsledek vyrendroval z vektorů a nevzal jen vloženou bitmapu. Ta je jen cca 4500x4500 a to je málo. (možná by 300dpi stačilo)

[Aleš Kapica]

Mupdf to dává celkem v pohodě - zoom končí na 288dpi, což bych řekl že bude limit podkladové bitmapy. A v tom bude i celý zádrhel. Kdyby to bylo celé vektorové, tak by se to mohlo renderovat rychleji. Takhle při zvětšování narůstá ta podkladová bitmapa do nechutného objemu dat a celé to brzdí.

[pc2005]

To PDF z jednoho toho balíku co jsem zkoušel má jenom 150DPI. Když jsem dal export do 300DPI bitmapy, tak už byly všechny pixely (co jsem zkoušel) duplikované. Mohlo by to být taky 144DPI, ale to už vyjde skoro nastejno... (a mělo by to být definovaný v pdf souboru IMO)

[pc2005]

Hmm ale koukám, tak ten gigovej bude mít možná 300DPI.

[pc2005]

Jestli to trvá tak dlouho, tak je něco s PDF souborem IMO. Možná moc vysoké detaily, nebo neefektivní uložení. Normálně by to mělo být na moderním CPU rychlejší.

Reakce na otevření je dekódování jedné stránky. Nejsem si jistý do jaké míry lze dekódování jedné stránky PDF paralelizovat. Vím, že poppler je thread safe a umí dekódovat podmnožinu stránky, ale je otázka zda si to interně nedekóduje celý.

Vím, že FlexPDF umí víc vláken (OpenMP), ale jen ve smyslu načítání víc stránek najednou. Navíc to není příjemně ovládaný frontend a navíc má tendenci dekódovat všechny stránky do RAM nehledě na její velikost.

Evince nepoužívá vlákna na nic (aspoň podle rychlého testu s ps axjf).

Dekódování v poppleru jde zrychlit snížením DPI, ale nevím o žádným prohlížeči, co by na to měl nastavovátko.

Metropolitního plánu Prahy ... 1.1 Textová část výroku

Ono to má 1.1GB? WTF!

[lertimir]

Ano je to velké, ale s textem není problém, náročné jsou grafické plány.

[OldFrog {Ondra Nemecek}]

Zkuste mupdf nebo mupdf-gl

[OldFrog {Ondra Nemecek}]

Ještě zkuste qpdfview

[R]

Problem je v kniznici poppler, ktoru pouzivaju takmer vsetky PDF prehliadace pre Linux. Vzdy to bolo tragicky pomale, hlavne ak PDF obsahuje bitmapy. Rychle CPU tento problem zamaskovali - pokym sa nepracuje s velkymi bitmapami.

[R]

Pokym sa to dalo, pouzival som Acrobat Reader 4.05 vo Wine. Bolo to radovo rychlejsie...

[Milan Uhrák]

pod wine mi běhá dobře foxit reader.

[x14]

Ta PDF jsou jen haldy obrovských bitmap s těmito vlastnostmi: CMYK s přiřazeným barevným profilem, komprese Deflate s prediktory. Předpokládám, že prohlížeč v rámci šetření paměti vždy znovu rozbaluje viditelnou část. Toto se bohužel musí udělat vždy celé od začátku.

Tomuhle víc jader nepomůže. Doporučuji z toho nedělat vědu a udělat si z toho udělat RGB JPEGy.

[lertimir]

dík.

[lertimir]

Přílohy:

• z-jpg.jpeg (309005 bytů)
• z-pdf.jpeg (197207 bytů)

Není to funkční. Ty bitmapy jsou v mnohem menším rozlišení než je fakticky ta vektorová vrstva. Např

magick identify S_02_Schema_formalnich_rozvoju.pdf 
S_02_Schema_formalnich_rozvoju.pdf PDF 4252x4252 4252x4252+0+0 16-bit ColorSeparation CMYK 68.9679MiB 32.020u 0:32.070

je vložená 68.9MB velká bitmapa v PDF. Ale celé PDF má 1,2 GB. To hlavní je ten původní vektorový podklad, který Okular počítá. A už když mám Okulár na zoomu 100% tak je rozdíl v kvalite pixelů a informací jasně vidět. (nemluvě když zazoomuju na 200% nebo 400%, tam je vidět každá garáž, každý altán na zahradě a hlavně přesné hranice. Přiložil jsem dva snapshoty z malé oblasti v Graficka_cast_1/Z_02_Hlavni_vykres_08.pdf. Jedno je snapshot z zobrazovaného Okuláru a druhý po konverzi z PDF do jpg a otevřené v Gwenview a nazoomované na stejné místo a velikost.

[klingger]

Miesto konverzie, odporúčam bitmapu vyextrahovať pomocou pdfimages. A na zobrazenie feh, alebo sxiv, ktoré tie bitmapy otvoria do dvoch sekúnd a posúvanie a zoomovanie je prakticky okamžité. Testované na C2D@2.2GHz so 4 GiB ram.

Ono celkovo tie pdf sú "divné". Podľa mňa tie bitmapy v nich nie sú vôbec komprimované, skúsil som jedno pdf (O_01_Koordinacni_vykres_05.pdf) preuložiť v Master PDF Editore a po uložení to má 44,7 MiB oproti 361,2 MiB bez straty kvality. Tiež si myslím že v tých PDF nie sú žiadne vektorové dáta, aspoň Inkscape, Master PDF Editor ani Adobe Illustrator CS2 mi žiadne nezobrazil.

[pc2005]

Jo souhlasím, ty PDF (teda minimálně jsem testoval Z_02_Hlavni_vykres_08.pdf) v sobě nemaj žádnou vektorovou bitmapu a mají v sobě ekvivalent asi 70MB PNG dat.

Docela by mě zajímalo co na to říkají autoři toho PDF.

[x14]

Hmm, tak to vůbec nesedí.

S_02_Schema_formalnich_rozvoju.pdf obsahuje nekomprimovanou(!) bitmapu 17715 x 17715 pixelů, 8 bitů CMYK.

Z_02_Hlavni_vykres_08.pdf obsahuje taktéž nekomprimovanou bitmapu 8888 x 8888 pixelů, 8bit CMYK.

Dá se to zjistit snadno i ručně v textovém editoru, stačí hledat třeba slovo width. Žádné vektory ani nic jiného už tam není.

Tyhle PDF soubory vytvořil blbec. Když se to první přeuloží do komprimované podoby má výsledné PDF velikost 35 MB a už tímto souborem se dá pracovat o řád lépe.

[OldFrog {Ondra Nemecek}]

Lertimir výše ale psal, že tam je bitmapa i vektory 436340#26

[lertimir]

Má pravdu. Ano, vytvářel to blbec. Jsou to jen bitmapy.

[kamowski]

nikdy som nemal tak veľký pdf súbor, nestačilo by ho zmenšiť, ak ho len prehliadaš?

compress pdf

[lertimir]

Viděl jsi, co to je? To jsou rozdělené mapové podklady Prahy s definicí, kde se co může nebo nemůže stavět. Fakticky v detailu asi 1 metr (možná méně) pro celou Prahu což je cca 500 km čtverčních. A ten detail je potřeba pro rozhodování kam tlačit třeba hranu mezi parkem a zastavitelným území. me zmenšeném se nemáš o čem rohodovat. nevidíš nic.

[kamowski]

toto je zbytočne agresívna reakcia
ja som teraz na mobilných dátach a neminiem si 1GB aby som to skúsil, prepáč
ty to máš iste v pc, zmenšil si to tým scriptom a bolo to zlé, či len tak ...oné?
nie je mi to jasné z tvojej reakcie

[lertimir]

Nezkusil, protože nemám ani Nautilus a ani žádné prostředí založené na GTK. A nejde o zmenšení. kousek nahoře jsem poslal dva ořezané screenshoty jeden z renderu vložené bitmapy o 4500x4500 a druhý z original PDF. Bitmapa je nepoužitelná.

[dustin]

V čem to prohlíží na úřadě či autoři?

[OldFrog {Ondra Nemecek}]

Dobrý nápad - možná by stačilo normálně na ten úřad zavolat. Ale asi to bude Adobe, co jiného.

[pc2005]

Nebo by šlo rozřezat bitmapu s vysokým rozlišením na jednotlivé dlaždice a použít engine google map.

[lertimir]

Na úřadě je to v Adobe a je to také pomalé. Autoří to nevím. Ve vlastnostech je napsán Photoshop CS6, ale to si myslím že je genrátor PDF. Autoři to musí mít vektorově a ve vrstvách. (i když i to by v Photoshopu asi šlo)

[dustin]

Pomalé = tak pomalé, jako v tvém okularu? Nějak si neumím představit, že by s tím každý den dělali a nevyžádali si od autorů (zaplaceného dodavatele) nějaké rozumné řešení.

[pc2005]

Je to pomalé i u mě na c2d 2.33GHz, 3GB RAM. Dokonce je to pomalé i když se to ukládá přes textové utility do PNG (150 DPI má asi 70MB). Ono i to otevření PNG 8kx8k není zrovna rychlý, ale jakmile se to dekóduje, tak to jako bitmapa docela sviští.

[lertimir]

čím jsi to převedl do png

[pc2005]

Příloha:

• index.html (2916 bytů)

Už jsem se dostal trochu dál. Tenhle skript ti vygeneruje ze vstupního obrázku (první parametr) dlaždice do openlayers (openstreetmaps):

#!/bin/bash
#hacked from https://openlayers.org/en/latest/examples/here-maps.html

#konvertuj to PDF
#package xpdf
#pdftopng -r 150 ./Z_02_Hlavni_vykres_08.pdf my_pdf_tmp_file
#package poppler
#pdftoppm -png -r 150 ./Z_02_Hlavni_vykres_08.pdf tmpppm
#package poppler
#pdftocairo -png -r 150 ./Z_02_Hlavni_vykres_08.pdf tmpcairo

#vysledny soubor z konverze
#FILENAME=./dpi150.png
FILENAME=${1}

MYDIR=./tiles
#DENSITY="-density 72"

#get resolution
TMPSIZEX=$(identify -format "%[fx:w]" ${FILENAME})

SIZEX=1
while [ $TMPSIZEX -ne 0 ] ; do
	TMPSIZEX=$(($TMPSIZEX/2))
	SIZEX=$(($SIZEX*2))
done

SIZEX=$(($SIZEX/2))	#just get the correct iteration
#sizes of tiles
SIZE=$SIZEX

echo $SIZE

mkdir ${MYDIR}

LEVEL=0		#do not touch
MYCOMMAND=""
#generate script for imagemagick for tiling
while [ ${SIZE} -ge 256 ] ; do
	MYCOMMAND="${MYCOMMAND} \\( +clone -crop ${SIZE}x${SIZE} -set filename:tile ${MYDIR}/${LEVEL}-%[fx:page.x/${SIZE}]-%[fx:page.y/${SIZE}] -resize 256x256 -write %[filename:tile].png +delete \\) -delete 1--1 "
	LEVEL=$(($LEVEL+1))
	SIZE=$((SIZE/2))
done

#damn these \( \)
eval "convert ${DENSITY} ${FILENAME} -resize ${SIZEX}x${SIZEX} ${MYCOMMAND} null:"

Ty konverzní programy mám 3, jsou na začátku v komentech. Všechny ale vedou stejně na nějakou formu knihovny poppler. Ještě by šlo ten PDF rovnou cpát imagemagicku, ale tam nevím jak získat rozměry pro dlaždice. Samozřejmě by to šlo asi stokrát líp, ale tohle byl první nástřel (jsem ani nevěděl že IM funguje jako zásobník v pipelajně příkazů).

Ještě potřebuješ javaskript z openlayers. A index.html (v příloze). Když to pak všechno nakopíruješ do stejnýho adresáře (openlayers soubory, index a adresář tiles co udělá ten skript), tak to stačí otevřít v prohlížeči a funguje to se zoomem i bez webserveru.

[dustin]

Takhle to asi nemají ani na tom úřadě a možná ani autoři

[pc2005]

A to mám dojem, že ten engine umí i SVG dlaždice . Ideálně by člověk dostal login k takové mapě a přes nějaký metadata tam prostě zadával ty připomínky.

[Aleš Kapica]

Příteli, zapomínáš na fakt, že žádný z dodavatelů software pro úřady nemá zájem dělat kvalitní, domyšlené a užitečné aplikace, protože by si tím sám řezal pod sebou větev. 8-P

[Peter Golis]

Ku cti im slúži aj to, že vždy dodržia zadanie v plnom rozsahu.

[klingger]

Konverzia je zbytočná ako som písal vyššie, použite pdfimages na vyextrahovanie tej bitmapy.

Na rozrezanie použite napr. https://github.com/VoidVolker/MagickSlicer a na zobrazenie https://openseadragon.github.io/

Výsledok vidieť tu: http://www.webstranky.net/pdf/

[pc2005]

pdfimages je jen jinej frontend ze stejnýho balíku poppler (jako ty 2 konverzní programy co jsem už posílal). Ale dobrý vědět, že mám na kompu minimálně 5 možností jak konvertovat pdf do png . O MagickSliceru jsem nevěděl, zajímavý, ale mě přišlo rychlejší si ten samej skript (obojí volá convert) napsat od nuly. Samozřejmě doporučuju taky už hotový řešení a ne ten můj bastl .

[klingger]

POZOR pdfimages NEkonvertuje pdf na bitmapu, ale uloží všetky bitmapy ktoré pdf obsahuje do samostatných súborov.

[pc2005]

A vida mea culpa toho jsem si nevšiml. Na druhou stranu ta ztráta informací nebude zas až tak velká (a bude jen pro maximální zoom).

[lertimir]

Takhle to není. Autoří jsou Institut plánování a rozvoje. Není to dodavatel produktu. Ale úřad který vydává data. Podobně jako např Český úřad zeměměřický a katastrální vydává mapy. V nějakém obecně čitelném formátu. Což PDF je.

[Peter Golis]

Čiže interne používajú nejaký GIS, a z neho urobia export vo formáte typu "neklikať, vrčí z toho počítač".

[kamowski]

dopracovali ste sa k nejakému použiteľnému riešeniu?

[dustin]

Tohle je přece velice pěkné a zcela použitelné.

[OldFrog {Ondra Nemecek}]

...pokud jde o pdf kde je jen bitmapa. Pokud je tam bitmapa + vektory, není to plnohodnotné, což naznačuje tento příspěvek - viz přílohy.

[x14]

Tak znovu: Jsou to jen bitmapy.

[OldFrog {Ondra Nemecek}]

Nezkoumal jsem to, pokud to jsou skutečně jen bitmapy, pak bude pdfimages opravdu nejlepší (a co si s nimi kdo udělá záleží už jen na něm).

[Aleš Kapica]

Tak jednoduché to není, protože je to většinou kombinace vektorů a podkladové bitmapy.

[x14]

Aha. Neprošel jsem úplně všechny soubory, jenom zde zmíněné jako problematické. A ty jsou čisté bitmapy.

Vektory jsou například v 01_MP_Pasma_celek_den.pdf a to mi pro změnu frčí bez problému a to i při zoomu 6400 %. Což už je zase úplně nesmyslný zoom - je z něj poznat, že ty vektory vznikly vektorizací bitmapy. Óóóó Bóóóže, to jsou dokumenty...