abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 14:44 | Komunita

Mozilla.cz informuje, že Firefox bude možná upozorňovat na úniky vašich hesel. V Mozille prototypují upozorňování na únik informací o vašem účtu, pokud se na seznamu Have I been pwned? objeví služba, ke které máte ve Firefoxu uložené přihlašovací údaje. Informace se objevila v pravidelném newsletteru o vývoji Firefoxu.

Ladislav Hagara | Komentářů: 5
dnes 00:22 | Bezpečnostní upozornění

Společnost ZONER informuje o bezpečnostním incidentu, při kterém došlo ke zcizení a zveřejnění části přihlašovacích údajů zákazníků k elektronické poště a webhostingu CZECHIA.COM.

Ladislav Hagara | Komentářů: 0
včera 23:44 | Nová verze

Byla vydána nová stabilní verze 1.13 (1.13.1008.32) webového prohlížeče Vivaldi (Wikipedie). Z novinek vývojáři zdůrazňují možnost zobrazení otevřených i uzavřených listů pomocí ikonky Okno na postranní liště a vylepšené stahování (YouTube). Nejnovější Vivaldi je postaveno na Chromiu 62.0.3202.97.

Ladislav Hagara | Komentářů: 8
včera 20:55 | Nová verze

Byla vydána verze 2017.3 dnes již průběžně aktualizované linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux. Aktualizovat systém lze pomocí příkazů "apt update; apt dist-upgrade; reboot". Z novinek lze zmínit 4 nové nástroje: InSpy, CherryTree, Sublist3r a OSRFramework.

Ladislav Hagara | Komentářů: 1
včera 01:55 | Bezpečnostní upozornění

Společnost Uber potvrdila bezpečnostní incident a únik dat v roce 2016. Unikly údaje o 57 milionech cestujících (jména, emailové adresy a čísla mobilních telefonů) a 600 tisících řidičích (navíc čísla řidičských průkazů).

Ladislav Hagara | Komentářů: 1
21.11. 23:44 | Humor

Co vypíše příkaz man půl hodiny po půlnoci? Text "gimme gimme gimme". Jedná se o virtuální velikonoční vajíčko připomínající skupinu ABBA a její hit Gimme! Gimme! Gimme! (A Man After Midnight). Problém nastane, pokud gimme gimme gimme nabourá automatizované testování softwaru. To se pak příkaz man musí opravit [Bug 1515352] [reddit].

Ladislav Hagara | Komentářů: 10
21.11. 18:11 | Zajímavý článek

Mozilla.cz informuje, že Firefox na Fedoře podporuje Client Side Decorations. Firefox na Linuxu se vykresluje včetně standardního záhlaví okna, které je v případě webového prohlížeče většinou nadbytečné a ubírá drahocenné vertikální místo na obrazovce. Verze distribuovaná uživatelům Fedory však nyní obsahuje experimentální podporu pro takzvané Client Side Decorations, které umožňují vykreslování „oušek“ panelů do záhlaví okna.

Ladislav Hagara | Komentářů: 12
21.11. 05:00 | Bezpečnostní upozornění

Maxim Goryachy a Mark Ermolov ze společnosti Positive Technologies budou mít v prosinci na konferenci Black Hat Europe 2017 přednášku s názvem "Jak se nabourat do vypnutého počítače, a nebo jak v Intel Management Engine spustit vlastní nepodepsaný kód". O nalezeném bezpečnostním problému informovali společnost Intel. Ta bezpečnostní problém INTEL-SA-00086 v Intel Management Engine (ME), Intel Server Platform Services (SPS) a Intel

… více »
Ladislav Hagara | Komentářů: 43
21.11. 01:33 | Zajímavý projekt

Na Humble Bundle byla spuštěna akce Humble Book Bundle: Java. Za 1 dolar a více lze koupit 5 elektronických knih, za 8 dolarů a více 10 elektronických knih a za 15 dolarů a více 15 elektronických knih věnovaných programovacímu jazyku Java od nakladatelství O'Reilly. Peníze lze libovolně rozdělit mezi nakladatelství O'Reilly, neziskovou organizaci Code for America a Humble Bundle.

Ladislav Hagara | Komentářů: 0
21.11. 00:11 | Zajímavý projekt

Článek na OMG! Ubuntu! představuje rodinu písma IBM Plex. Jedná se o open source písmo (GitHub) navržené a uvolněné společností IBM (YouTube, Carbon Design System). Ukázka na Font Squirrel.

Ladislav Hagara | Komentářů: 14
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (9%)
 (1%)
 (1%)
 (1%)
 (75%)
 (14%)
Celkem 755 hlasů
 Komentářů: 37, poslední 21.11. 15:21
    Rozcestník

    Dotaz: Zmenšení velkého obrázku (650MB)

    31.1.2007 08:55 zombik | skóre: 6
    Zmenšení velkého obrázku (650MB)
    Přečteno: 1123×
    Dobrý den,

    řeším jedem malý problém. Mám velký obrázek (650MB) ve formátu tiff a chci jej zmenšit. Zkoušel jsem ImageMagick, ale ten mi hlasí "alocation memory failed". Nevite o programu, který by byl schopen zacvičit s takovýmto souborem?

    Dekuji

    Jura D.

    Odpovědi

    31.1.2007 09:09 Petr Šobáň | skóre: 79 | blog: soban | Olomouc
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    A kolik máš fyzicky v PC ram ?

    Pokud málo tak to asi nikdo nezvládne protože potřebuješ podle mě blok o velikosti 650M do kterého by se ten tiff nahrál, pak nějakou ram pro převod a zápis + něco na chod OS atd....
    31.1.2007 13:03 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    Proveditelnost by neměla záviset na množství fyzické paměti, ale na tom, kolik je k dispozici paměti virtuální. Jen to samozřejmě bude poněkud pomalejší…
    31.1.2007 21:54 Petr Šobáň | skóre: 79 | blog: soban | Olomouc
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    Ale závisí to na fyzické paměti, pro správnou funkci potřebuje načíst určitou část do ram - tento úsek většinou musí být souvislý, ale pokud má málo ram tak jsou v ram volné bloky roztroušené a nenajde se potřebný volný blok v celku. (i když tam ta volná paměť je, nevím jak je ten program dělaný ale předpokládám že aspoň pro jeden řádek musí být místo ve fyzické ram) a proto se mu nepovede alokace. Kdešto pokud je ram více snáže se najde volný blok o požadované délce.
    Luboš Doležel (Doli) avatar 31.1.2007 21:58 Luboš Doležel (Doli) | skóre: 98 | blog: Doliho blog | Kladensko
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    K čemu souvislé bloky ve fyzické paměti, když se používá paměť virtuální? Ta už se může namapovat kamkoliv.
    1.2.2007 16:32 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    Souvislost fyzické paměti - nebo vůbec fyzické adresy stránek - procesy nezajímá, k těm se vůbec nedostanou. Všechno kromě příslušné části jádra pracuje s virtuální pamětí. Jinak jsem si teď zkusil vyrobit TIFF 15000x15000 pixelů (velikost 644 MB) a convert mi ho bez problémů zmenšil na 1500x1500, jen při tom potřeboval skoro 2 GB paměti (samozřejmě virtuální).
    1.2.2007 18:10 Petr Šobáň | skóre: 79 | blog: soban | Olomouc
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    To jste na omylu program požádá třeba o 1M ram a tu potřebuje dostat v celku, takže pro alokaci musí být v RAM volný blok o velikosti 1M.

    Ovšem pro program se musí přidělit souvyslý blok o velikosti 1M jak to jádro udělá je tomu programu jedno - samozřejmě to jádro může rozdělit do více nesouvyslých bloků - ovšem mám dojem že dnešní jádra toto neumí.

    Samozřejmě pokud program bude požadovat třeba 10 bloků o velikosti 1M tak těch 10 bloků nemusí být fyzicky souvislé.
    1.2.2007 18:19 cronin | skóre: 49
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    program požádá třeba o 1M ram a tu potřebuje dostat v celku, takže pro alokaci musí být v RAM volný blok o velikosti 1M.
    V Linuxe je to pravda, v BSD nikoli, tam neexistuje fragmentacia pamate.
    1.2.2007 18:40 Petr Šobáň | skóre: 79 | blog: soban | Olomouc
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    Ono i v Linuxu se dělá na tom aby se volné bloky spojovaly, mám dojem že je to popsáno v nějakých jaderných novinách.

    Prostě program mu to napsal jasně = ImageMagick, ale ten mi hlasí "alocation memory failed"

    Takže uvolnit paměť, aby jí bylo fyzycky více, případně skusit přidat RAM fyzicky, podle mě program potřebuje načíst aspoň jeden řádek obrázku což podle mě dělá dost u tak velkého tifu.

    Případně vyskoušet jiný program který není založen na ImageMagicku a který s tím obrázkem bude pracovat jinak a nebude potřebovat tolik RAM.

    PS. Teď mě napadlo co si skusit přeložit ImageMagick z src zda v tom balíčku není nějaké omezení třeba pouze na to 1G ?
    1.2.2007 18:53 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    program požádá třeba o 1M ram a tu potřebuje dostat v celku, takže pro alokaci musí být v RAM volný blok o velikosti 1M

    Musí být volný blok virtuální paměti, ne fyzické (ta může být klidně celá plná - tedy až na rezervu definovanou v /proc/sys/vm/min_free_kbytes).

    5.2.2007 12:29 moira | skóre: 30 | blog: nesmysly
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    To jste na omylu program požádá třeba o 1M ram a tu potřebuje dostat v celku, takže pro alokaci musí být v RAM volný blok o velikosti 1M.
    Nejsem expert na jadro ale jak to popisujete, tak mi z toho plyne, ze virtualni pamet je prakticky nanic. Resp. pokud by se neco odswapovalo, tak by to musel byt cely alokovany blok pameti. Funguje to opravdu takto? Ja zil doted v predstave, ze fyzicka pamet a pamet jak ji vidi proces spolu vubec nesouvisi a provadi se preklad v procesoru pomoci tabulek.
    Překladač ti nikdy neřekne: "budeme kamarádi"
    5.2.2007 12:36 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    Nefunguje. Alokátor (i ta jaderná část - brk() a mmap(), natož user space - malloc(), new) samozřejmě pracuje s virtuální pamětí.
    5.2.2007 12:56 moira | skóre: 30 | blog: nesmysly
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)

    Aha, cili teda pulka bloku pameti zustane v RAM a druha bude na disku. Mezitim se ta odswapovana fyzicka RAM zaplni necim jinym (to je jedno cim) a nasledne nastane potreba priswapovat puvodni odswapovany blok zpet do RAM (rekneme, ze bude potreba). Protoze uz nemuze na sve puvodni misto, bude to nekam jinam. Dojde tedy k tomu, ze onen puvodni blok se ve fyzicke RAM "roztrhne". Proc tedy nejde naalokovat takto "roztrzeny" blok hned na zacatku, ale jak tvrdite, musi byt ve fyzicke RAM souvisly?

    Nebo je nekde v me uvaze chyba?
    Překladač ti nikdy neřekne: "budeme kamarádi"
    5.2.2007 13:37 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    Chyba je pouze v tom, že mi přisuzujete něco, co tvrdil kolega Šobáň. Já od začátku tvrdím, že alokátor pracuje s virtuální pamětí a ne s fyzickými adresami.
    5.2.2007 13:56 moira | skóre: 30 | blog: nesmysly
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    Pravda, omlouvam se, nevsiml jsem si.
    Překladač ti nikdy neřekne: "budeme kamarádi"
    5.2.2007 13:07 Andrej Herceg | skóre: 43
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    Tento program alokuje pamäť až kým malloc nevráti NULL (už nie je voľná pamäť). Potom sa každý druhý blok uvoľní a pokúsi sa alokovať blok veľký 2*SIZE. U mňa to vypíše chybu, napriek tomu, že je polovica pamäte voľná (ak sa nemýlim, volá sa to fragmentácia pamäte; častý problém pri používaní malloc).

    PS: viem prečo to tak funguje :)
    #include <stdlib.h>
    #include <stdio.h>
    #include <string.h>
    
    #define	MAX	1024*1024
    #define	SIZE	1024*1024
    
    char *pointers[MAX];
    
    int main(void)
    {
    	int 		i;
    	char		*tmp;
    	char		buf[16];
    
    	for (i = 0; i < MAX; i++) pointers[i] = NULL;
    
    	for (i = 0; i < MAX; i++) {
    		pointers[i] = malloc(SIZE);
    //		memset(pointers[i], 'A', SIZE);
    		if (pointers[i] == NULL) {
    			fprintf(stderr, "Nemozem alokovat pamat (pointers)\n");
    			break;
    		}
    	}
    
    	for (i = 0; i < MAX; i += 2) {
    		if (pointers[i] != NULL) {
    			free(pointers[i]);
    			pointers[i] = NULL;
    		}
    	}
    
    	tmp = malloc(SIZE*2);
    	if (tmp == NULL) {
    		fprintf(stderr, "Nemozem alokovat pamat (tmp1)\n");
    	}
    
    	for (i = 0; i < MAX; i++) {
    		if (pointers[i] != NULL) {
    			free(pointers[i]);
    			pointers[i] = NULL;
    		}
    	}
    
    	tmp = malloc(SIZE*2);
    	if (tmp == NULL) {
    		fprintf(stderr, "Nemozem alokovat pamat (tmp2)\n");
    	}
    	fgets(buf, sizeof(buf), stdin);
    	return EXIT_SUCCESS;
    }
    
    5.2.2007 13:39 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    To je sice hezké, ale to pořád pracujete s virtuálním adresním prostorem, ne s fyzickou pamětí.
    5.2.2007 13:47 Andrej Herceg | skóre: 43
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    Aha. Takže existuje nejaký program, ktorý na úpravu tiff obrázka používa fyzickú pamäť a nepoužíva virtuálnu?

    Samozrejme je pravda, že na úrovni fyzickej pamäte fragmentácia nie je problém (kernel môže dať stránku kamkoľvek a aj tak sa bude zdať, že virtuálna pamäť je spojitá).
    5.2.2007 14:10 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)

    Ne, proč? User space aplikacím po fyzické paměti nic není, ty s ní vůbec nepřijdou do styku. To je to, co tu celou dobu od začátku tvrdím - že má-li convert problémy s alokací paměti, není třeba přidávat fyzickou paměť, ale stačí dočasně zvětšit virtuální (přidáním swapu). Dokonce i ten zmiňovaný convert si poradí s 32 MB fyzické paměti a 256 MB swapu…

    5.2.2007 14:18 Andrej Herceg | skóre: 43
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    Áno je pravda, že stačí pridať akúkoľvek pamäť (teda stačí aj ten swap).

    Ale problém s alokáciou pamäte môže spôsobiť aj fragmentácia pri zlom používaní malloc. Ale to som mal napísať k inému komentáru (keďže tam kde som to dal, sa rozoberala fyzická a nie virtuálna pamäť).
    5.2.2007 13:52 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    Tak ještě jeden argument pro ty, kdo stále tvrdí, že je potřeba mít dostatečně velký souvislý blok ve fyzické paměti: právě jsem úspěšně pomocí malloc() alokoval 224 MB blok (pochopitelně virtuální) paměti na počítači s 32 MB fyzické paměti a 256 MB swapem. Kdo nevěří, může si to klidně vyzkoušet sám.
    31.1.2007 09:14 repli
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    Jednou jsem pracoval s obrázke 250 MB (mám 256 MB paměti), v Gimpu jsem ho za pár minut načetl. (Každopádně je to jako páchat sebevraždu)
    Dalibor Smolík avatar 31.1.2007 09:31 Dalibor Smolík | skóre: 54 | blog: Postrehy_ze_zivota | 50°5'31.93"N,14°19'35.51"E
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    convert obrazek.jpg -resize 1600x1200 obrazek.jpg (vyžaduje imagemagick)
    Rozdíly v řeči a ve zvyklostech neznamenají vůbec nic, budeme-li mít stejné cíle a otevřená srdce.
    31.1.2007 10:13 Petr Šobáň | skóre: 79 | blog: soban | Olomouc
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    ImageMagic mu nejde málo ram.
    31.1.2007 10:18 Petr Šobáň | skóre: 79 | blog: soban | Olomouc
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    Ono záleží v čem to je a podle mě se musí aspoň načíst do RAM jeden řádek obrázku naráz a u tiff v velkém rozlišení to dělá třeba několik Mega a programu se nepovede alokovat tak velkou souvislou část, pokud je málo Ram a je třeba moc fragmentovaná.

    PS. Proč nám neřekneš kolik tam máš ram ? Na 256M to asi neuděláš. On je totiž rozdíl 250M v 256M fyzické a 650M v 256M fyzické.
    31.1.2007 12:35 zombik | skóre: 6
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    Zdravi,

    a děkuji za reakce. V PC je celkem 1G RAM a je k dispozici cca 900MB swapu.

    Jura D.
    31.1.2007 13:04 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    Zkuste dočasně přidat swapfile (máte-li dost místa na disku). Také zkontrolujte, zda není problémem resource limit (podívejte se na výstup 'ulimit -a').
    31.1.2007 21:59 Petr Šobáň | skóre: 79 | blog: soban | Olomouc
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    A jak už tu řekly taky bych to skusil s co nejmenším počtem spuštěných démonů a programů, takže povypínat vše co jde a není třeba aby to běželo, a potom to skusit.
    1.2.2007 19:32 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    Na 256M to asi neuděláš. On je totiž rozdíl 250M v 256M fyzické a 650M v 256M fyzické.

    Právě jsem zmíněnou operaci, tj. zmenšení 15000x15000 obrázku (644 MB TIFF) příkazem convert z balíčku ImageMagick provedl na stroji s 64 MB fyzické paměti. Mám pro zajímavost zkusit ještě 32 MB?

    1.2.2007 19:33 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    Za slovem ImageMagick má být samozřejmě čárka.
    31.1.2007 13:11 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    Podle mě by to mohlo jít přes nástroje netpbm. Bohužel nemám žádný takhle zrůdně velký obrázek (je to vůbec obrázek? Velikost 650MB by spíš vypadala na image CD?) tak to nemohu vyzkoušet.
    31.1.2007 13:25 Peter Lehotsky | skóre: 26 | Prague
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    Muze to byt nekomprimovany Tiff a v tom pripade to nemusi byt ani barevne (300DPI a vetsi nez A2 resp. A1).
    31.1.2007 13:29 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    Při 1200 dpi by to byla necelá A3…
    31.1.2007 13:37 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    Bohužel teď nemám čas na hraní, ale použijte tifftopnm, pamscale a pak některý z nástrojů pnmtoněco, podle toho jaký chcete výsledný formát..
    31.1.2007 13:49 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    tifftopnm -byrow big.tiff | pamscale -xscale=0.5 -yscale=0.5 | pnmtopng > output.png
    
    Tahle kolona zmenší původní tiff na polovinu a uloží výsledek ve formátu png
    1.2.2007 08:30 zombik | skóre: 6
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    Děkuji za pomoc, ale nemám k dispozici pamscale (tifftopnm mám), prestože baliček Netpbm mám naistalovaný. Distribuce je debian testing. Pamscale je součástí jiné verze ?
    1.2.2007 09:31 Marble | skóre: 27 | blog: marble | Švédsko
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    s/pamscale/pnmscale/
    1.2.2007 12:23 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    pnmscale je v novější verzi netpbm obsolete
    31.1.2007 20:23 zombik
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    Jedná se o mapy zakoupené v největším rozlišení a potřebuji je zmešit pro učely prezentace.

    J.D.
    1.2.2007 07:34 rastos | skóre: 60 | blog: rastos
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    Aký soft (hoci aj ne-linuxový) odporúča na spracovanie použiť predajca?
    1.2.2007 08:32 zombik | skóre: 6
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    Prodejce nic nedoporučuje. Myslel jsem, že kolegyně si s obrázky poradí v GISu, ale také jí to nešlo a tak to zbylo na mě...
    1.2.2007 10:04 rastos | skóre: 60 | blog: rastos
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    To znamená, že vám predal 650MB dát, o ktorých ani neviete povedať či nie sú random. Super. Koľko ste zaplatili? (Zo zbežného pohľadu na TIFF format špecifikáciu to vyzerá, že TIFF súbor môže mať až 4GB ;-) )
    31.1.2007 13:29 fakenickname | skóre: 42 | blog: fakeblog
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    Btw, zkoušel jsi to převést imagemagickem při minimálním ztížení systému? například v single režimu nebo jestli máš náhodou po ruce nějaké SGIčko či Apple ;)
    31.1.2007 23:45 R
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    Skus namiesto imagemagicku pouzit nieco ine. Mozno otvorit v gimpe alebo v xnview.
    1.2.2007 10:37 Semo | skóre: 44 | blog: Semo
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    Este by som si overil, ze je zapnuta podpora High Memory Support na 4GB. Inak z 1GB fyzickej pamate jadro vyuziva iba cca 900MB. Nie je to zasadny rozdiel, ale trocha to pomoze. Overit sa to da jednoducho prikazom free.
    If you hold a Unix shell up to your ear, you can you hear the C.
    1.2.2007 15:25 zombik | skóre: 6
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    High memory Support je zapnut a je využívana veškerá pamět.
    1.2.2007 16:08 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    Zkusil jsi použít tu kolonu s tím pnmscale? pamscale je v novější verzi, ale to co máš ty bude mít nejspíš tohle. (Přejmenovali to..)
    5.2.2007 10:41 zombik | skóre: 6
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)-Vyřešeno
    Obrázek se mi podařilo zmenšit pomocí příkazů z Vaší kolony. Děkuji za pomoc! Nešlo mi to použít jako kolona a tak jsem použil příkazy postupně.
    tifftopnm big.tiff >vystup.pnm
    pnmscale vystup.pnm -xscale=0.1 -yscale=0.1 > vystup_zmenseno.pnm
    
    Toto cvičeni jsem provedl na P4 1.5GHz s 512 MB RAMM a šlo to docela rychle. Děkuji všem za odpovědi a názory na problém.

    Zdraví a hezký den přeje.
    Jirka Dušek
    5.2.2007 11:42 Petr Šobáň | skóre: 79 | blog: soban | Olomouc
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)-Vyřešeno
    Kolik to sežralo RAM při převodu jste se nekouknul co ?
    1.2.2007 13:34 cronin | skóre: 49
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    GIMP by to mal zvladnut.
    5.2.2007 12:21 klingger | skóre: 17
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    Vyskúšajte VIPS, ten je priamo robený na takéto veci.
    7.2.2007 09:01 zombik | skóre: 6
    Rozbalit Rozbalit vše Re: Zmenšení velkého obrázku (650MB)
    Dobrý den,
    vyzkoušel jsem program VIPS (nip2) a provedl požadované změny. Mohu vřele doporučit. Na PC P4 1.5GHz s 512 MB RAMM a 256 MB swapem bylo použito cca 120 MB paměti a cca polovina swapu. Změna velikosti obrázku trvala cca 1-2 minuty a bylo hotovo. Samotné načtení obrázku trvalo do 30 sekund.

    Zdraví a hezký den přeje.
    Jirka Dušek

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.