Dobrý den.Rád Bych poprosil někoho, kdo má zkušenosti s prací s orthomapami, aby mi poradil ohledně vhodného HW.V současné době pracuji na stroji:Intel P45 + Core2 Quad na 3.33 Ghz4 GB RAM DDR2HDD WD Velociraptor 10000 ot/minATI 3650 myslímWin XP ProAutocad LT 2008Při načtení cca 70 mapových podkladů jako Xrefy pod situační výkres je práce s výkresem nepříjemně pomalá. Mapy jsou v rozlišení cca 6000x4000 bodu a jpeg mají velikost cca 8MB.Zkoušel jsem trial verzi Civil 3D 2009 a bez zlepšení.Zkoušel jsem Nvidia Quadro 3700 bez zlepšení.Chtěl bych se zeptat, jestli mi pomůže lepší HW, SW nebo je to pro práci obecně příliš složitý podklad.Děkuji za každý nápad.PS: kolega IT technik mi říkal, že mu z nepochopitelného důvodu pomohly dvě nejpomalejší grafiky zapojené do SLI, což se mi zdá osobně podivné. Myslím, že výkonná grafika pomůže jen pro 3D a rendering. Na situačky ve 2D je zřejmě zbytečná, nebo se pletu?

Výkonnost grafické karty se měří mnoha parametry. Pro rychlost rastrových obrázků v AutoCADu nejsou podstatné její 3D akcelerační funkce, ale datová propustnost grafické karty.
 
Urychlení lze dosáhnout použitím rastrových funkcí AutoCADu Map nebo Civil (nejen použít příkaz IMAGE v Mapu), dostatkem paměti pro cache rastrů, rychlým (sladěným) počítačem a použitím efektivních formátů rastrových snímků.

Jedna věc je HW a druhá - a asi významnější - uvědomit si, co mám za data a jestli je potřebuji všechny najednou ...
S tím souvisí, že není ortofoto jako ortofoto. Rozhodující je, jakému mapovému listu odpovídá a s jakou podrobností, nemluvě o hloubce barev a nastavené jpg kompresi
A podle "velikosti " fotky (míněné v metrech) je si potřeba uvědomit, jestli potřebuji všechny najednou
Například teď jsou v Praze Ortofoto, odpovídající listu v měřítku 1:1000 (fyzicky 625 x 500m) s rozlišením 10 cm/pixel, čili 6250x5000 px, velikost souborů jpg 6-13 MB (podle hustoty kresby).
Poskládám-li 72 těchto listů do obdélníku 9x8, zobrazí rozsah 5625 x 4000 metrů.
Ale dříve byly ortofotky, odpovídající listům v měřítku 1:2000 (fyzicky 1250 x 1000m) s rozlišením 20 nebo 40 cm/pixel.
Poskládám-li je stejně, dojdu k území o rozměrech 11250 x 8000 metrů!
 
Potřebuji to mít všechno najednou - v jednom Xrefu, anebo bude lepší si to logicky rozdělit na více Xrefů a ty si načítat podle potřeby?
 
Před pár dny jsem pracoval na podkladu 4 x 4 fotky (1:1000, 10cm/px, 6250x5000px, 7-8 MB každá, celkem fyzicky 2,5x2 km). Ty byly připojeny do jednoho DWG (společného pro všechny ortofoto), které jsem si připojil jako Xref a podle potřeby do základního DWG (momentálně 9 MB) uvolňoval/značítal. Je pravdou, že jejich načtení do stavu, kdy jsem měl  zoom All, trvalo poprvé asi 60s, ale posuvy a zoomování + i - (včetně dalších zoom all) zabraly tak 1-3 s a to není neúnosné
 
PC už má leccos za sebou, neznačkový (snad už konečně bude něco novějšího, abych si tam dal 2008/2009)
Intel Pentium 4/ 3GHz na Intel D865
2GB RAM DDR400
Matrox Parhelia AGP8x
HD - WD - SATA - 80 GB/7200ot. - systém, programy
      - WD - PATA - 120GB/7200 ot - data
Windows 2000 Prof.
Civil 3D 2006
 
 
 Mantlík2009-02-05 16:41:46

Díky za opověď.Chystáme v práci energetickou studii města, proto bych rád pracoval s co největším územím najednou.Mapy máme pravděpodobně taky 1:1000. Originál je v TIFF ve velikosti cca 350 MB a kolega z nich udělal JPEG s 80 % kvalitou na velikost cca 8 MB.Napadlo mě ještě udělat dvě velikosti JPEG, jednu pro práci v 0% kvalitě (cca 1,5 MB) a tu 80ku nechat až na tisk. Možná to dost pomůže.Vyzkouším

[QUOTE=Vladimír Michl]
Urychlení lze dosáhnout použitím rastrových funkcí AutoCADu Map nebo Civil (nejen použít příkaz IMAGE v Mapu), [/QUOTE]
Můžete mne, prosím, trochu naťuknout? (Možná to je i tím, že jsem zatím ustrnul na civilu 2006 a ty funkce jsou v něčem novějším)
 
[QUOTE=Vladimír Michl]
dostatkem paměti pro cache rastrů, ...[/QUOTE]
Tím myslíte nastavení v Map->obrázek->možnosti->paměť->limit paměti? KOlik byste obecně nastavil?
Anebo myslíte něco jiného?
 
[QUOTE=Vladimír Michl]
a použitím efektivních formátů rastrových snímků.[/QUOTE]
dneska tu v jiném vláknu zaznělo, že TIFF a PNG jsou výhodnější, než JPG? V čem konkrétně ? V rychlejším zpracování? Viděl jsem ortofotky v TIFFu 2-3x větší, než srovnatelné jpg.

Výkresy se dávají do JPEGu aby zabíraly méně místa na disku. Při práci se stejně "dekompresují" a pracujete v reálné velikosti souboru. Pokud tedy nemáte systém s hardwarovou podporou komprese JPEG :-). V Mapu ani v Civilu nepracuji, ale dedukuji, že pan Michl upozorňuje na funkce v Mapu/Civilu, které paměti ulevují softwarovou cestou (interní komprese). Ale jinak, z praxe: používáme bitmapy s dvěma rozlišeními (nízkým a vysokým) na různých hladinách (nebo v různých xrefech) a ty zapínáme dle potřeby. Pokud ovšem ortomapy nejsou tím jediným co máte na přesnou práci :-)

[QUOTE=vlkoun]Díky za opověď.Chystáme v práci energetickou studii města, proto bych rád pracoval s co největším územím najednou.Mapy máme pravděpodobně taky 1:1000. Originál je v TIFF ve velikosti cca 350 MB a kolega z nich udělal JPEG s 80 % kvalitou na velikost cca 8 MB.Napadlo mě ještě udělat dvě velikosti JPEG, jednu pro práci v 0% kvalitě (cca 1,5 MB) a tu 80ku nechat až na tisk. Možná to dost pomůže.Vyzkouším
[/QUOTE]Pokud budete potřebovat pracovat s velkým územím najednou, tak by za to stálo rastr zmenšit, ne? To by pomohlo nejvíc. Pokud rozlišení zmenšíte na polovinu, tak ušetříte 3/4 paměti. Před tiskem pak prohodíte rastry a podle potřeby i změníte měřítko rastru. Snížit kompresi z principu podle mě nemůže pomoct pokud ponecháte bitovou hloubku pixlů, což může být u JPG problém (buď je plnobarevný nebo šedivý).  Může pomoci formát s indexovanými barvami.

Upozorňoval jsem jen na vhodnost použití správných nástrojů (ne LT), správných funkcí (příkaz _Image z AutoCADu má méně možností než vložení obrázku z menu Mapu/Civilu, mj. právě cache) a správného formátu rastrů. Nejde ani tak o konkrétní souborový formát (i když i ten má vliv), ale spíše o skutečně potřebné rozlišení a barevnou hloubku.
 
Tyto vlivy se mohou na celkovém výkonu projevit příznivěji než jen hardwarový pohled.

[QUOTE=Mantlík]dneska tu v jiném vláknu zaznělo, že TIFF a PNG jsou výhodnější, než JPG? V čem konkrétně ? V rychlejším zpracování? Viděl jsem ortofotky v TIFFu 2-3x větší, než srovnatelné jpg. [/QUOTE]Nevím kde to zaznělo, nenašel jsem, ale jen pokud vím, tak JPG dostanu v 8-mi bitových barvách jen šedivý. Prostě nezvládne indexované barvy jako TIF, PNG, nebo GIF.  Docela bych se vsadil (nemohu to ale nijak dokázat), že si AutoCad vnitřně převede rastr na nějaký nekomprimovaný formát (třeba bitmapu apod...). Urychlení tedy může nastat pouze na čase čtení z disku (nebo jiného úložiště), naopak ale pak je zpomalení při převodu (tedy "zpracování obrázku" - to je pravděpodobně ten převod...).

Alfred:
 

To vlákno je ve fóru Civil, Map, GIS a jmenuje se "Paměť pro Map"
 
Co se týče zmínky o barvách, možná jsem to zcela nepochopil. Ale JPG v 8-mi bitových barvách má podle mne 256*256*256 = 16,7 mil.barev. I když snížím počet barev na 256 (8 bitů), zůstane fotka barevná a ne černobílá
Ale zpochybňovat to nehodlám, nejsem v rastrech až tak vzdělán, a tak nevím, co znamenají indexované barvy ....
 
Na tom vnitřním převodu možná něco bude, když se podívám Irfanem na vlastnosti jedné ortofotky, najdu tam třeba
- 16,7 mil. barev (24 bits per pixel)
- počet unikátních barev 86492
- velikost na disku 6,94 MB
- současná velikost v paměti 89,42 MB

Sam nejsem nejaky odbornik na vnitrni format rastru. Zkusim to lajcky popsat.

S baravami mate pravdu - v RGB rezimu je to 256x256x256barev, tedy na jeden pixel je potreba 8x8x8 bitu a tedy barevna hloubka je 24bitu na pixl (BPP).
Teoreticka velikost je pak:
sirka x vyska x 24BPP (napr rastr 800x600x24=11520000bitu=1440000B=1406kB=cca 1.37MB

V rezimu indexovanych barev si vyberu kombinaci napriklad 256 barev (muzu zvolit i jiny pocet - zalezi na software). Na zacatku souboru mam prevodni tabulku kde je napsano ze barva RGB(24BPP)=indexovana barva (pri 256 barvach je to 8BPP).
Vyse uvedeny priklad je
800x600x8=3840000bitu=480000B=468kB + indexova tabulka

Teoreticky tedy zabere takovy rastr neco malo vic nez tretinu pameti.

A jeste k tomu formatu JPG. Barevna hloubka JPG je bud 24BPP (tedy rezim RGB) a tedy barvy a nebo sedivy rastr a barevna hloubka 8BPP. Neumi indexovane barvy. Zkuste si treba v IrfanView - u fotky snizte barevnou hloubku na 256, ulozte rastr a znovu otevrete - bude opet 24BPP. Pokud by jste chtel 8BPP JPG tak musite v dialogu ukladani zaskrtnout, ze bude rastr sedivy.
Pak zkuste to same (originalni rastr, snizit pocet barev, ulozit jako PNG, GIF, nebo TIF). Po otevreni bude 8BPP.
Prohlednete si rastry a na stavove radce je velikost na disku / velikoste v pameti.

[QUOTE=alfred]Zkuste si treba v IrfanView - u fotky snizte barevnou hloubku na 256, ulozte rastr a znovu otevrete - bude opet 24BPP. Pokud by jste chtel 8BPP JPG tak musite v dialogu ukladani zaskrtnout, ze bude rastr sedivy. [/QUOTE]
 
Hmm, máte pravdu, ukládat a znovu otevřít jsem to nezkoušel a spokojil se s tím, že na stavovém řádku se po snížení počtu barev na 256 objevilo ....x8BPP. Musím být důslednější
Co se týče indexace barev - dík za osvětlení, tohle mi stačí, hlouběji to nepotřebuji

[QUOTE=Mantlík]
Hmm, máte pravdu, ukládat a znovu otevřít jsem to nezkoušel a spokojil se s tím, že na stavovém řádku se po snížení počtu barev na 256 objevilo ....x8BPP. [/QUOTE]

No, ono je to asi v tu chvili pravda (tech 8BPP), ale pak se to pri ulozeni do JPG zase vrati na 24BPP. Navic pri ukladani si JPG vytvari ty sve "ctverce" (nevim jak se to nazyva presne) a tam interpoluje barvy, takze indexace u tohoto formatu se ztratovou kompresi asi postrada smysl...

nase zkusenost/shrnuti vyse uvedeneho:
- carove vykresy ukladat do png (jde zprusvitnit pozadi a je relativne rychla prace).
-barevne vykresy jako JPG - normalne 24bit, komprese tak, aby se to tisklo kvalitne. Pokud je problem s celkovou velikosti, tak mit obrazek 2X - jednou velky a podruhe v malem rozliseni, zvetseny pres scale a prepinat hladiny, jak uz psal hynekn
- u carovych vykresu se vyplati JAKAKOLI vektorizace - delame ji v letitem sw, ktery jsem kupoval jeste v dobe win3.1...neresim vubec, jak jsou vysledne vektory pouzitelne - staci mi to, ze autocad je sviznejsi, kdyz mam podsvicene vektor misto bitmapy

Porovnání hlavních výhod a nevýhod rastrových formátů je též na:
http://www.cadforum.cz/cadforum/qaID.asp?tip=6418
 
Preferovaný formát pro vektorové kresby (když už musí být v rastrové podobě) je GIF.

Ještě bych doplnil, že formát GIF nemusí umět všechny (zejména starší) verze AutoCadu (viz téma Průhlednost rastru).

Už to začíná být trochu off-topic, ale na průhlednost (černobílého) rastru je dobrý tiff. Nezapomeňte ovšem v acadu průhlednost zapnout. Má to ještě tu výhodu, že si potom rastr můžete "obarvit" jakoukoliv barvou. Třeba šedě, jako podklad.

Ještě jednou jsem si spočítal čísla z prvního příspěvku, jen tak pro legraci. Ve 24-bitové barvě dělá 70 ortomap po 6000x4000pixelech něco kolem 5 GB paměti. V indexovaných barvách (256) to dělá třetinu. Taky úctyhodné. Pokud takový obrázek vytisknete v dosti vysoké kvalitě 300 dpi, bude veliký 3,5x3,5m. Obvykle pro barevný obrázek při tisku dostačuje kvalita 150 dpi (věřte-nevěřte, je to tak) a potom by byl veliký 7x7m. To je dost na podrobný územní plán Prahy i s širokým okolím :-) Tak to by bylo něco z IT demagogie

Hezký .... 
Sice už jsme úplně OT, ale pro tu srandu jsem si dosadil ještě do jednoho vzorečku
Praha má (zjednodušeně a spíše ještě s rezervou) cca 1400 ortofotek v rozlišení 6250 x 5000, což ve 24- bitové barvě v jpg v souhrnu představuje cca 131 GB dat ....

...což při použití mých demagogických výpočetních metod znamená obrázek o rozměrech 17,7 x 17,7 m při rozlišení 300 dpi a 35,4 x 35,4 m při 150 dpi...ale už toho opravdu necháme! Jsou na světě počítače, které takový obrázek pojmou najednou, ale na magistrátě ho asi nemají

[QUOTE=hynekn]....6000x4000pixelech něco kolem 5 GB paměti. V indexovaných barvách (256) to dělá třetinu. Taky úctyhodné. Pokud takový obrázek vytisknete v dosti vysoké kvalitě 300 dpi, bude veliký 3,5x3,5m. Obvykle pro barevný obrázek při tisku dostačuje kvalita 150 dpi (věřte-nevěřte, je to tak) a potom by byl veliký 7x7m. To je dost na podrobný územní plán Prahy i s širokým okolím :-) Tak to by bylo něco z IT demagogie [/QUOTE]
 
ted nevim, jestli jsem jen nepochopil nejaky zert, ale pro jistotu:

pixel = dot
dpi = dots per inch
1inch = 25,4mm
6000 pixelu / 300 = 20 inchu = 50cm
kolik dpi je treba pro tisk?


Je treba rozlisovat DPI a LPI (za laickost vysvetleni omluva, na nejakem dtp webu to bude urcite popsano lip).
Pokud mam tiskarnu, ktera umi na kazdy pixel umistit presne ten spravny odstin, tak plati svrchuuvedeny vzorecek - proste vydelim pocet pixlu hodnotou dpi a mam velikost, ve ktere vytisknu v nejvyssi kvalite.
Tiskarny ale obvykle neumi ty odstiny uplne vschny takze pouzivaji techniku michani ruznebarevnych tecek - podle toho, kolik maji barev inkoustu, technologii tisku...lze si predstavit, ze treba na to, aby tiskarna umela udelat tecku libovolne barvy (=pixel obrazku) potrebuje 2x2 tisknutelne / adresovatelne puntiky - pokud ma tedy tiskarna 600 dpi, tak to znamena, ze na 25,4 mm umi adresovat (trefit se) na 600 mist, tj. ma tiskovy bod 0,04mm. Pokud ale na namichani libovolneho odstinu potrebuje 2x2 body, tak realne neumi vytisknout ve vyssi kvalite nez 300 dpi ... a tuto hodnotu udava udaj lpi.
Noviny (cb) byvaly myslim na 80lpi, casopis 120...

 

[QUOTE=Rostislav Říha][QUOTE=hynekn]....6000x4000pixelech něco kolem 5 GB paměti. V indexovaných barvách (256) to dělá třetinu. Taky úctyhodné. Pokud takový obrázek vytisknete v dosti vysoké kvalitě 300 dpi, bude veliký 3,5x3,5m. Obvykle pro barevný obrázek při tisku dostačuje kvalita 150 dpi (věřte-nevěřte, je to tak) a potom by byl veliký 7x7m. To je dost na podrobný územní plán Prahy i s širokým okolím :-) Tak to by bylo něco z IT demagogie [/QUOTE]
 
ted nevim, jestli jsem jen nepochopil nejaky zert, ale pro jistotu:

pixel = dot
dpi = dots per inch
1inch = 25,4mm
6000 pixelu / 300 = 20 inchu = 50cm
kolik dpi je treba pro tisk?


Je treba rozlisovat DPI a LPI (za laickost vysvetleni omluva, na nejakem dtp webu to bude urcite popsano lip).
Pokud mam tiskarnu, ktera umi na kazdy pixel umistit presne ten spravny odstin, tak plati svrchuuvedeny vzorecek - proste vydelim pocet pixlu hodnotou dpi a mam velikost, ve ktere vytisknu v nejvyssi kvalite.
Tiskarny ale obvykle neumi ty odstiny uplne vschny takze pouzivaji techniku michani ruznebarevnych tecek - podle toho, kolik maji barev inkoustu, technologii tisku...lze si predstavit, ze treba na to, aby tiskarna umela udelat tecku libovolne barvy (=pixel obrazku) potrebuje 2x2 tisknutelne / adresovatelne puntiky - pokud ma tedy tiskarna 600 dpi, tak to znamena, ze na 25,4 mm umi adresovat (trefit se) na 600 mist, tj. ma tiskovy bod 0,04mm. Pokud ale na namichani libovolneho odstinu potrebuje 2x2 body, tak realne neumi vytisknout ve vyssi kvalite nez 300 dpi ... a tuto hodnotu udava udaj lpi.
Noviny (cb) byvaly myslim na 80lpi, casopis 120...

 [/QUOTE]Sprrrráávně. Proto uvádím jako postačující pro tisk barevných obrázků 150 dpi. CMYK tisk (třeba ofsetový) se řídí trochu jinými pravidly (nebo se doposud řídil, dokud nepřišli se stochastickými rastry) a tou je vzdálenost tiskových bodů řádek (LINES) rastru jednotlivých barevných složek. Ale i u inkoustových tiskáren nebylo vždycky veselo a netiskly všechny barvy do jednoho bodu. Chvíli to trvalo, než se naučily (ty tiskárny) barvy míchat tak, aby to vůbec šlo . Proto ten poněkud konzervativní přístup.

[QUOTE=hynekn] [QUOTE=Rostislav Říha][QUOTE=hynekn]....6000x4000pixelech ... Pokud takový obrázek vytisknete v dosti vysoké kvalitě 300 dpi, bude veliký 3,5x3,5m. .[/QUOTE]
 
 

pixel = dot
dpi = dots per inch
1inch = 25,4mm
6000 pixelu / 300 = 20 inchu = 50cm[/QUOTE]Sprrrráávně. Proto uvádím jako postačující pro tisk barevných obrázků 150 dpi. [/QUOTE]
 
Porad nechapu, kde se vzalo tech 3,5m.

...těch orto map o velikosti 6000x4000 (v úplně prvním příspěvku) je prý 70ks... Tak proto.

3470 mm, abych byl přesný

v tomto odvětví nepracuji, pracuji pouze v photoshopu a illustratoru, kde pracuji s originálem, který následně komprimuji a kamarádka je využívá k 3D v Mayi myslím. Když vzpomenu na tvorbu plakátu a jedné šablony v plné nekomprimované velikosti, mohl jsem se pohybovat někde kolem 20Mpixelů (při náročné editaci a spleti vrstev a otevřených dalších xMpixelových fotek jako zdroj se neskutečně sekalo), a na to má předchozí sestava

Intel E5200 - OC 3.6Ghz
P45 MB + 4GB 800Mhz Adata
GK ATI RX3850 oc 700/2000 s 256MB
Disky SATA 7200ot

prostě nestačila. Výměna za dvoujádrové ATI 3850 s 1GB ram pomohla znatelně. Proto si neoficiálně myslím, že paměť grafické karty je hodně důležitá, stejně jako její paměťová propustnost, která byla 4x vyšší stejně jako kapacita.

DOPLNĚNÍ: a vše nakonec také záleží na tom jakým způsobem pracuje dotyčný software. je totiž otázkou zda software vynucene tlačí data do Operační paměti nebo do paměti Grafické karty, která má paměti mnohem rychlejší (kdejaká karta za 1000+Kč)
K4my2009-03-10 10:20:54