Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Udělal jsem si pár rychlých testů a nic moc. Nejde jen o to, že je verze 1.0 nejméně 100x pomalejší než libjpeg (a to máme ještě i akcelerované libjpeg-turbo), ale kvalita mě nepřesvědčila. Artefakty ostrých hran jsou skutečně menší, ale kompenzuje to vyšším kostičkováním. Prostě taková adaptivní kvantizace se zoufalou pomalostí. U stařičkého JPEGu se už žádný zázrak čekat nedá.
Je to horší, než libjpeg, ale Google a následně novináři budou tvrdit, že je to lepší. Tak zatím vypadaly všechny kompresní algoritmy od Googlu.
Mne sa zda ze pri tej druhej ukazke sa s Guetzli dost pomenili farby...
WEBP jsem objevil až včera, kdy jsem si chtěl uložit obrázek a místo JPG jsem dostal nějaké .webp. Fast Stone Image Viewer tuto příponu asi vůbec nezná, zrovna tak ani Windows 10? Navíc jako internetová adresa obrázku bylo uvedeno .jpeg, což mě mate ještě dvakrát tolik.
Pracujeme s obrazky relativne dost, tak jsem zkusmo naimplementoval tento komprimator.
Vysledky jsou, co se rychlosti tyce - zalostne. Bezna nase uloha pro Ryzen trva 4-6minut, zde po 1hod bylo asi 10% (100% 16jader :D). Vysledky co se tyce kvality mi prijdou subjektivne horsi nez MozJpeg, ktery pouzivame nejcasteji a zaroven jsou soubory pri podobne kvalite VETSI.
Za me tedy palec dolu, nebot casova narocnost - byt by v nasem pripade byla tolerovatelna - a vysledky dohromady nejdou.
Co by me osobne prislo zajimave by bylo pouziti vice kvantizačních tabulek (dle standardu by jich mohlo byt az cca 10) pro jednu slozku. Takze mista prazdnejsi by byla komprimovana jinak, nez mista s obsahem apod. Podle vseho by to melo byt mozne, nebot v kazdem bloku je moznost ulozit ID kvantizační tabulky. Zatim se mi ovsem nic takoveho nepovedlo, natolik se v kodu nevyznam.
Můžu se zeptat, na jak veliké obrázky jste to aplikoval? Jak jsem pochopil, cílová skupina jsou webové dokumenty, takže tam bych bral jako maximum tak 4K.
Od cca 400*400px do cca 2000*2000px. vyzkouseli jsme asi 100 obrazku v ruznych kvalitach a porovnavali opticky podobne velike datove soubory apod.
MozJpeg udelal obrazky i podstatne mensi nez Guetzli (nejnizsi kvalita je povolena 84, pak je potreba rekompilovat). Takze napriklad MozJpeg kvalita 70 (velikost X) byl porad podobne kvalitni nez Guetzli 84 (velikost skoro 2X). Ovsem MozJpeg 80 (velikost podobna 2X) byl o dost peknejsi. Ano vim, ze je to subjektivni, neda se to ani poradne zmerit, protoze sice muzete pouzit MSSIM porovnani, ale to je ciste matematicke, ne oku (kazde oko jine) lahodici, takze sum v jednom muze byt rusivy, byt je celkove nizsi nez ve druhem.
Zkratka a dobre - 30% dolu ? Ani nahodou (mozna za nejakych uzasnych podminek - obrazky namalovane primo pro ne). Nekdy mozna 10% dejme tomu - teoreticky by to asi slo, ale nekdy je ten obrazek podstatne vetsi - nekdy i nez obycejne ulozeni z Lazarusu (mela by to byt puvodni implementace JPEG) bez jakekoliv optimalizace.
Ovsem cas ? Des a hruza. Za tech 30% bychom to obetovali - mozna, jak nad tim premyslim, spis asi ne, je rozdil 6mim ve cca 10hod (po 1hod bylo cca 10%). (Na 4 jadrech I7-4790K jsme nadavali i na par desitek minut - Ubuntu 17.04, pod XEN,16Gb,dedikovany hdd apod. Ted na Ryzen 1800X native(ne XEN), 32Gb ram, 256NVme SSD opravdu mezi 4-6minutami - dle typu ulohy.
Legracni je, ze na vypocetni vlakna mame timeout - u bezneho obrazku a MozJpegu na 20s (schvalne nadsazen aby nekilloval moc casto). U Vetsich pak 1min. U Guetzli jsem musel timeout zvysit na 300S a stejne se zabijeli, tak jsem dal 600S !! A pomer zabiti uz byl rozumnejsi. Coz znamena, ze pri plnem 16vlaknovem prevodu vicemene stejnych fotografii v ruznem rozliseni kvalite apod nestaci Guetzli ani tech 10minut. Budto desne neoptimalizovany kod, nebo se holt trefili, ze Ryzen je v tom razantne pomaly.
Děkuji za odpověď. V takovém stavu se mi to jeví jako nepoužitelné.
Neni zac, rado se stalo. Btw: Swap se nevyuzival, pameti bylo volne jeste velmi hodne (cykluje to u nasi aplikace, takze se neda rict kolik, ale swap ani byte a ramka mezi 16 a 3 gb volne)
Zdá se mi, že je to spíše nějaká alfa nebo beta verze, takže tam nejspíš nějaký prostor pro optimalizaci je, ale na druhou stranu se zdá, že je to cílené na obrázky s vysokou kvalitou, a tam mi zase přijde zbytečné šetřit na velikosti (kdopak dneska třeba dává grafy do gifu?).
Když už je tu tolik zkušených osob, zeptám se, jaký je v současnosti nejlepší jpeg enkodér s GUI, které umožňuje nastavení cílové velikosti souboru(?)
Cerna je taky barva :) MozJpeg ma docela pekne CMDLINE rozhrani - jinak cokoliv co pouziva LibJPEG by melo jit zmenit na MozJpeg jen zmenou knihovny (overeno nemam, pouzivame ve vlastni aplikaci jinak), jak se pak nastavuji dalsi parametry prevodu nevim, ale pry to kompatibilni je uplne.
Na nejaky fotky bych klido zkusil JPEGmini - ten ma sice nejaky omezeni (pokud se ted nepletu, mmj prave to ze jen GUI) ale je pak gratis. Jinak je to docela raketka, ale vysledky maji pekny.
Primo velikost vysledneho souboru nevim kdo umi, protoze to de facto znamena to ulozit a podivat se - predpoklad uspesnosti komprese je v tomto pripade asi i slozitejsi nez to proste poukladat a vybrat. Dal by se na to napsat prima skript.. zkusit malou a velkou kvalitu a iterovat do nejblizsi nizsi nez pozadovane. Ale bude to trvat
Nejlepsi co jsem zatim zkusil je XAT image optimizer: http://windows.podnova.com/software/698562.htm
Tim jde vyrobit opravdu maly a kvalitni jpeg s trochou usili. Tusim, ze existuje i command line verze.
Neznal jsem, kouknul jsem, info - neumi commandline, jen batch, jen Win a posledni verze je 5 let stara (coz nemusi znamenat nic spatneho, ale podpory vyrobce apod se nedockate.)
Když už se bavíme o zmenšování velikosti grafických souborů, tak se zeptám na neztrátové zmenšování. Čas od času pracuji s velkými objemy dat z elektronového mikroskopu, který je ukládá ve formátu TIFF. Ty předhodím https://pnggauntlet.com/ a musím říct, že s výsledkem jsem velmi spokojen (tímto doporučuji). Avšak nechám si rád poradit jak neztrátově zmenšit ještě více. Děkuji.
Nedávno jsem testoval bezeztrátové kompresory PNG a nahradil jsem dříve používanou trojici pngcrush+pngout+advpng za tuhle dvojici:
pingo -s4 file.png
ECT_x86 -9 --reuse file.png
A je to v drtivé většině případů ještě o dost menší a přitom výrazně rychlejší
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.