Dotaz: Zmenšení obrázku convertem

[DWD]

Pomoci

convert -resize 700x600! obzazpuvodni. png novyobraz.png

jsem zmenšil obraz PNG asi na čtvrtinu. Přesto má asi třikrát více kolobajtů, než původní. Přitom bych očekával, že bude mít méně kB, než předtím. Čím to je a jak to ovlivním?

Odpovědi

[Zbyněk Petr (Zboňa)]

Ahoj, velikost souboru, tedy jeho kvalitu muzes nastavit pomoci prepinace -quality [0-100] (myslim, ze to je cislo v procentech).

vice man convert

[Grunt]

U PNG? Tam se nastavuje tak max. úroveň komprese a algoritmus pomocí -quality XY, kde X je úroveň [0-9] a Y je algoritmus [0-5]. Nejlepší komprese se dá dosáhnout pomocí -quliaty 95.

[Grunt]

identifiy novyobraz.png && identify obrazpuvodni.png. BTW, je opravdu menší? Protože co já vím, tak před vykřičníkem má být lomítko aby ten vykřičník nesežral BASH.

[DWD]

Je ten obraz pravduzmenšený, prohlédl jsem si ho. A ten vykřičník tam potřebuji kvůli tomu, aby ty rozměry byly změněné kompletně a to i za cenu změnění poměru stran.

[DWD]

Když zadám

convert -resize 700x600! -quality 95 puvodni.png novy.png

, vůbec není množství kB menší. A ať už místo 95 dám co chci, je to pořád stejné - pohybuje se to mezi 830KB - 900 KB.

[DWD]

Pro hromadnou úpravu velikosti obrázků jsem použil skript:

#!/bin/bash
  mkdir zmensene
  for soubor in *.png ; do    
      convert $soubor -resize 700x600! -quality 80 zmensene/$soubor
  done   

Mám v adresáři 62 obrazů, různě velkých a potřebuji z nich udělat všechny stejně velké, přičemž názvy musí být zachované. Pendrek ten skript ale funguje. V podadresáři "zmensene" sice mají všechny obrázky upravenou velikost, jak potřebuji, ale místo 62 obrázků je jich tam 123, protože se některé opakují. Taky se u většiny z nich zkomolily názvy, například "nedit4-t.png" se zkomolí na "nedit4-t12.png" a tak různě. Taky se různě popřehazovaly názvy. Prostě mi tam nadělal zmatky a binec. Podadresář "zmensene" i s obsahem jsem vymazal a skript spustil znovu. Zase úplně stejný výsledek. Ten skript bude zmetek a nejsem schopný ho opravit.

[Grunt]

Jasně. Já jen říkám, že se to píše -resize 800x600\!. Toť vše.

[Jalien]

Případně na výsledné PNG poté použít OptiPNG.

[fraxinus]

Povodny obrazok je mensi lebo pouziva menej farieb (napr. nejaka kresba). Po zmenseni sa pouzije interpolacia co z 1-farebnej ciary urobi rozmazanu smuhu s vela farbami. Skus na zmenseny obrazok v gimpe pouzit efekt posterize. Ten redukuje paletu farieb. Redukuj dokial to bude dobre vyzerat.

[Michal Kubeček]

U některých verzí ImageMagick je potřeba použít -depth 8, protože defaultně vytvářejí 16-bitové PNG.

[DWD]

Co se týká názvů a počtu souborů ve vzniklém podadresáři, skript už funguje dobře, už tam nedělá binec. A to i když před ten vykřičník přidám to zpětné lomítko, ikdyž ne, obě možnosti jsem vyzkoušel. Možná, že mi to ten binec dělalo kvůli tomu, že v tom jednom řádku jsem měl

for soubor in *.pn* ; do    

místo

for soubor in *.png ; do    

Mohlo to být tím? Další věc velikost souborů. Po zmenšení obrázků se velikost souborů zvětší, místo zmenší. Asi to bude pravda, že to bude kvůli zvýšení počtu barev. To bych v Gimpu opravit mohl, ale raději bych to udělal pomoci příkazového řádku, abych to mohl udělat hromadně pro více obrazů jedním příkazem nebo skriptem. A zase aby názvy souborů zůstaly zachované i v upravených obrazech.

[DWD]

Ten binec, který mi to dělalo, bude možná kvůli něčemu jinému, než kvůli tomu tomu, že jsem měl ve skriptu

for soubor in *.pn* ; do    

místo

for soubor in *.png ; do    

Už si to nepamatuji. Ale teď jsem přidal do skriptu přepínač -depth 8, opravdu pomohl, soubory mají asi třikrát menší objem dat, než ty zmenšené předtím, ale pořád to není ono, pořád je velikost dat o něco větší, než u nezmenšených obrázků.

[Grunt]

Mohlo to být tím? Další věc velikost souborů. Po zmenšení obrázků se velikost souborů zvětší, místo zmenší. Asi to bude pravda, že to bude kvůli zvýšení počtu barev.

A kvůli tomu aby jsme tady nemuseli hádat z křišťálové koule jako nějací věštci, jestli je to zvětšením bitového prostoru nebo převodem z palety na PNG24 jsem nahoře napsal ten příkaz identify (též z balíku ImageMagick), který zobrazí vlastnosti obrázku a mezi nimi i barevnou třídu a bitovou hloubku. Ale ne. Místo toho se tady furt bude vařit guláš. A úplně nejlepší by bylo poskytnout jeden vzorek ať si to může každý zkusit sám, zda-li mu to na jeho vlastním ImageMagicku bude též tvořit větší obrázky (klidně to totiž může být strukturou obrázku).

[DWD]

Příloha:

• cb001-t.png (136167 bytů)

Původní obraz:

[david@localhost img]$ identify cb001-t.png
cb001-t.png PNG 1092x793 1092x793+0+0 DirectClass 8-bit 132.975kb
[david@localhost img]$

Zmenšený obraz s použitím přepínače -depth 8:

[david@localhost zmensene]$ identify cb001-t.png
cb001-t.png PNG 700x600 700x600+0+0 DirectClass 8-bit 144.902kb
[david@localhost zmensene]$

Zmenšený bez přepínače -depth 8:

[david@localhost zmensenepng]$ identify cb001-t.png
cb001-t.png PNG 700x600 700x600+0+0 DirectClass 16-bit 368.328kb
[david@localhost zmensenepng]$

Příloha původní obraz.

[fraxinus]

Příloha:

• a.png (81216 bytů)

$ identify a.png

a.png PNG 700x600 700x600+0+0 DirectClass 8-bit 79.3125kb

ale robil som to v gimpe + posterize na 31 farieb

[Grunt]

Dej pokoj s posterizací. Lepší je to přímo adaptivně nakvantovat, popř. doladit DItheringem.

[Grunt]

Takže jo. Používáš HDRI verzi ImageMagicku (16 či více bitovou) a musíš vždycky explicitně uvést, že chceš 8-bitů na kanál. Jinak i když obrázek zmenším, tak je i u mě větší a je to přesně z toho důvodu, proč jsem si myslel. V původní nezmenšené verzi máš ostré hrany (většinou na 1 pixel) a po nich většinou širé pole, což se hodně dobře komprimuje. ImageMagick v defualtu používá pro škálování Mitchell-Netravali filter (je fakt dobrý, ale hodí se spíš pro obrázky z reálného světa jako jsou fotky) kde se zohledňuje frekvenční podstata, hrany se rozmažou, což udělá ještě víc hodnot než tam je a obrázek se blbě komprimuje. Pokud chceš aby se to dobře komprimovalo, musíš použít lepší interpolační filtr, takže místo -scale třeba -adaptive-scale (je to Mesh interpolace) a nebo se interpolace úplně zbavit (třeba tím, že použiješ Nearest-neighbor interpolaci což uděláš tak, že přidáš parametr -filter box – ale zas to budeš mít kostičkované). Oba parametry u mě udělaly menší výsledek (ale stejně ne o moc). Více viz Resize or Scaling. Dalšího zmenšení velikosti dosáhneš tím, že třeba zmenšíš počet barev. Viz. Color Quantization and Dithering a nebo jak už se někdo výše zmínil, tím že výsledný PNG ještě zoptimalizuješ. Ale já osobně bych pouvažoval o nějakém lepším rozměru (třeba 2× menší).

[Grunt]

Ono totiž když to zmenšíš, tak tam máš ještě víc barev než v původním obrázku:

$convert 161157-cb001-t-27641.png -unique-colors txt:- | head -n 1
# ImageMagick pixel enumeration: 14845,1,255,rgba
$ convert 161157-cb001-t-27641_zmensene.png -unique-colors txt:- | head -n 1
# ImageMagick pixel enumeration: 20839,1,255,rgba

A pokud budeš kvantovat (zmenšovat počet barev), tak by bylo ještě vhodné pouvažovat o GIFu (pro málo barev má kapánek lepší algoritmy).

[DWD]

Příloha:

• obrazy.zip (67940 bytů)

Teď jsem narazil na dva obrázky: Oba stejně velké, oba vyfocené a uložené snímačem obrazovky Ksnapshot, a oba v png. Jeden obraz obsahuje hodně barev (jambarevny.png) a jeden se skládá jenom z černé a bílé (jamcerny.png) a tím pádem by ten barevný měl mít daleko více kB, než ten černý. Přesto má ten černý skoro dvakrát více kB (41,7), než ten barevný(26,1). A v tom černobílém jsou jenom černé a bílé kusy, žádné rozmazané čáry.

$ convert jambarevny.png -unique-colors txt:- | head -n 1
# ImageMagick pixel enumeration: 1831,1,65535,RGB
$ convert jamcerny.png -unique-colors txt:- | head -n 1
# ImageMagick pixel enumeration: 47,1,65535,RGB

Příloha.

[chrono]

Nebol to pôvodne jpeg formát? Pretože sú tam artefakty presne ako na jpeg obrázkoch a tých farieb je tam kvôli tomu viac a ešte väčší problém je to, že to je náhodný vzor a to sa dosť zle komprimuje.

[DWD]

Ten černý byl původně jpeg, ale ten barevný png. Potom jsem oba vyfotil snímačem obrazovky a uložil do png. Tyto uložené snímačem obrazovky jsem použil do přílohy a do příkazů

convert obraz.png -unique-colors txt:- | head -n 1

tady. Když si ten černý obraz zobrazím v Konqueroru, nevidím hodně barev, vidím jenom černou a bílou, dokonce ani mezistupně šedé nevidím. Teď jsem si ten obraz při zobrazení v Konqueroru zkusil i zvětšovat, abych se přesvědčil, jestli tam nemám rozmazané místa. Rozmazaného nic sice nevidím, ale jsou tam trochu nepatrné fleky. Tak ta velikost souboru bude asi kvůli tomu. Ty fleky jsou ty artefakty?

[chrono]

Skús si to otvoriť napr v Gimp a zmenši gammu (Colors -> Levels a zmeň to stredné číslo, čo je normálne 1.0) na nejaké malé číslo (napr. 0.1).

[DWD]

To zmenšení gammy pomohlo, soubor se z 41,7 kB snížil na 31,8 kB, ale zviditelnily se ty nepatrné fleky. Potom jsem zkusil jinou úpravu: Ten obraz, místo snížení gammy, jsem upravil v Gimpu tak, že jsem zvýšil kontrast na maximum. Ty nepatrné fleky zmizely úplně a velikost souboru se snížila na 5,9 kB.

[chrono]

S tou Gammou som myslel len to, aby si sa mohol lepšie pozrieť, ako ten obrázok naozaj vyzerá. :)

Ak chceš z neho urobiť naozaj čierno biely, tak použi funkciu Treshold a potom zmeň obrázok z RGB na obrázok používajúci paletu a nechaj tam len dve farby (prípadne to na obrázok s paletou zmeň hneď, malo by to fungovať aj tak).

[Grunt]

S tou Gammou som myslel len to, aby si sa mohol lepšie pozrieť, ako ten obrázok naozaj vyzerá

To spíš nějakou barevnou redistribuci.

[Grunt]

Jak už bylo řečeno, obrázek není černý a bílý ale je to normální 8-bitový barevný PNG (myslím nemá ani paletu) + artefakty způsobené JPEG kompresí (ty se zvlášť blbě komprimují):

-rw-rw-r-- 1 petrvlasic petrvlasic 26678 2010-08-13 16:35 jambarevny.png
-rw-r--r-- 1 petrvlasic petrvlasic  3169 2010-08-14 13:09 jambaw.png
-rw-rw-r-- 1 petrvlasic petrvlasic 42726 2010-08-13 16:34 jamcerny.png
$ identify jamcerny.png 
jamcerny.png PNG 417x476 417x476+0+0 8-bit DirectClass 41.7KiB 0.010u 0:00.000
$ identify jambaw.png 
jambaw.png PNG 417x476 417x476+0+0 8-bit PseudoClass 2c 3.09KiB 0.010u 0:00.000

Právě z toho důvodu počítačovou grafiku nikdy (a nebo fakt jen v nejnutnějších případech) neukládáme do JPEGu.