Das Kunst­werk heißt "Shit Flag".

Sor­ry Leu­te, heu­te wird es tech­nisch. Al­so igno­riert das hier ein­fach, wenn's nicht eu­er Ding ist.

Die Ge­schich­te geht so: Vor ei­ner Wei­le hab ich dem Blog ja äu­ßer­lich ei­ne neue Ge­stalt und un­ter der Hau­be ein tech­nisch et­was zeit­ge­mä­ße­res The­me spen­diert. Da­vor war es ganz ein­fach mit den Bil­dern: In vol­ler Auf­lö­sung hoch­ge­la­den, hat Im­sa­ni­ty das Zeug dann von selbst auf die da­ma­li­ge Brei­te von 604 Pi­xeln ska­liert. Mit der Word­Press-Vor­ein­stel­lung für die JPEG-Kom­pres­si­on (am An­fang "-qua­li­ty 90", dann in neue­ren Ver­sio­nen auf "-qua­li­ty 82" re­du­ziert), sah das üb­li­cher­wei­se auch halb­wegs an­sehn­lich aus, die Da­tei­grö­ßen hiel­ten sich mit durch­schnitt­lich we­ni­ger als 100 kB im Rah­men.

Mit dem mo­der­ne­ren The­me hiel­ten dann nicht nur et­was groß­zü­gi­ge­re Ab­mes­sun­gen son­dern na­tür­lich auch ein ge­wis­ses Maß an Re­spon­si­ve­ness Ein­zug. Den Bil­dern le­dig­lich ein paar zu­sätz­li­che Pi­xel spen­die­ren und "One si­ze fits all" für je­des Dis­play reicht da nicht mehr. Al­so lie­ber mal die neu­en Bil­der mit ak­tu­ell 960 Pi­xeln et­was groß­zü­gi­ger di­men­sio­nie­ren als nö­tig, viel­leicht zahlt sich das ja bei der nächs­ten gro­ßen Um­stel­lung noch mal aus; au­ßer­dem sieht's dann mit et­was Glück auch auf hoch­auf­lö­sen­den Dis­plays et­was we­ni­ger Schei­ße aus (wo­bei man­che Re­ti­na-Dis­plays wohl­be­merkt ein viel­fa­ches da­von ver­tra­gen könn­ten).

Jetzt muss ich al­so mit ziem­lich ge­nau zwei­ein­halb mal so vie­len Pi­xeln pro Bild han­tie­ren. Das macht sich selbst­ver­ständ­lich in der Da­tei­grö­ße be­merk­bar und so kommt der Wunsch auf, das Bytes/Pi­xel-Ver­hält­nis et­was zu op­ti­mie­ren. Schließ­lich will ich wenn's geht noch ein paar Jah­re so wei­ter­blog­gen, oh­ne mei­nem (noch) ver­gleichs­wei­se güns­ti­gen Hos­ter mehr Geld ab­drü­cken oder ei­ne neue Hei­mat su­chen zu müs­sen. (Auch wenn mich die Li­mi­tie­run­gen ei­nes 08/​15 shared Web­space lang­sam ner­ven und ich zu­min­dest mit 'nem or­dent­li­chen VSer­ver lieb­äug­le, bin ich doch ge­ra­de nicht wirk­lich in der Stim­mung für ei­nen Ser­ver­um­zug.)
Au­ßer­dem mag Goog­le flott la­den­de Sei­ten und ef­fi­zi­ent kom­pri­mier­te Bil­der sind da ein gro­ßer Fak­tor (und den­ke ich dann an SEO und die gan­ze da­mit ein­her­ge­hen­de Bau­ern­fän­ge­rei, kommt mir gleich das Kot­zen… aber das ist noch­mal ein ganz an­de­res The­ma). Zu gu­ter letzt muss ich dann noch or­dent­lich Spei­cher­platz frei­hal­ten, et­wa zum zwi­schen­spei­chern von Back­ups, die dann au­to­ma­tisch per FTP auf ei­nen Raspber­ry Pi bei mir Zu­hau­se ge­scho­ben wer­den. Al­les gu­te Grün­de, ein we­nig spar­sam mit dem Da­ten­auf­kom­men zu sein.

Mei­ne Ziel­set­zung: Ak­zeb­ta­bles Bild­ma­te­ri­al mit ei­ner durch­schnitt­li­chen Da­tei­grö­ße von grob 100 kB pro Bild.

 

Man kann's ja mal versuchen: Online-Bildoptimierer

Die­se Diens­te wer­den der­zeit an al­len Ecken und En­den an­ge­prie­sen mit teil­wei­se recht ma­gisch an­mu­ten­den Ver­pre­chun­gen. Die meis­ten da­von sind Free­mi­um An­ge­bo­te, mit ei­nem in Funk­ti­on oder Durch­satz stark ein­ge­schränk­ten kos­ten­lo­sen Tier und kos­ten­pflich­ti­gen An­ge­bo­ten, de­ren mo­nat­li­che Ge­büh­ren für klei­ne Blog­ger wie mich in kei­nem Ver­hält­nis zum Nut­zen ste­hen. Da muss man schon Pitch­fork sein, da­mit sich das lohnt.
Cheetao ist ei­ner der we­ni­gen An­bie­ter, die auch ei­nen be­zahl­ba­ren Vo­lu­men­ta­rif an­bie­ten (ein­mal fünf Dol­lar raus­rü­cken für 3000 Bil­der, das wür­de bei mir für 3-4 Jah­re aus­rei­chen) und des­halb hab ich der Bu­de mal 'ne Chan­ce ge­ge­ben, ne­ben­bei aber auch ein paar kos­ten­lo­se Krü­mel an­de­rer An­bie­ter auf­ge­pickt. Und tat­säch­lich wa­ren die meis­ten da­von in der La­ge mit gu­tem Aus­gangs­ma­te­ri­al dem End­ergeb­nis ein paar Ki­lo­bytes ab­zu­luch­sen. Bei sub­jek­tiv glei­cher Bild­qua­li­tät, ver­gli­chen mit den üb­li­chen, auf der sehr al­ten libj­peg ba­sie­ren­den Haus­mit­teln.
Ne­ben­her hab ich noch ein paar an­de­re Sa­chen ver­sucht und bin letzt­end­lich zum Schluss ge­kom­men, dass die On­line-Bild­schrump­fer auch nur mit Was­ser ko­chen und ih­re ach so bahn­bre­chen­den Ver­fah­ren gar nicht so geil sind. Mit et­was Gaf­fatape und ein paar In­fos ist es kein Pro­blem, auf dem hei­mi­schen Rech­ner und oh­ne wahn­sin­ni­gen Auf­wand bes­se­re Er­geb­nis­se zu er­zie­len. (Hier sei an­ge­merkt, dass auf mei­nem All­tags-Lap­top Ubun­tu läuft. Die an­ge­spro­che­nen Tools soll­te man auch auf nicht-*nix Sys­te­men ans Ka­cken krie­gen, das könn­te po­ten­zi­ell aber mit mehr Fri­cke­lei ver­bun­den sein.)

 

Stufe eins: Mozilla's MozJPEG und eine sehr langsame Alternative

Zwei Pro­jek­te ha­ben in den letz­ten Jah­ren klei­ne­re Wel­len ge­schla­gen mit dem Ver­such, ei­nen zeit­ge­mä­ße­ren JPEG-En­co­der zu bau­en. Im­mer­hin ist die fast über­all ein­ge­bun­de­ne libj­peg und de­ren Per­for­mance-op­ti­mier­ter Fork libj­peg-tur­bo schon ziem­lich in die Jah­re ge­kom­men.

Der jün­ge­re Ver­such kommt aus dem Hau­se Goog­le und nennt sich Guetz­li. Der über­wie­gen­de Teil al­ler JPEG-En­co­der ist auf die SSIM-Me­trik op­ti­miert, ei­nes von vie­len Wahr­neh­mungs­psy­cho­lo­gi­schen Mo­del­len mit dem Ziel, sich mit ma­the­ma­ti­schen Mit­teln der mensch­li­chen Wahr­neh­mung an­zu­nä­hern und so­mit ei­nen Wert zu er­mit­teln, wel­cher halb­wegs mit der von Men­schen emp­fun­de­nen, sub­jek­ti­ven Qua­li­tät ei­nes Bil­des kor­re­liert. SSIM ver­gleicht im­mer zwei Bil­der mit­ein­an­der, im Fall von JPEG die Quell- mit der Ziel­da­tei. Der SSIM-Wert be­sagt, wie groß der un­ter­schied zwi­schen bei­den ist. Kei­ne die­ser Me­tri­ken ist per­fekt, es wird auch noch flei­ßig dran ge­forscht und ent­wi­ckelt.

Goog­le hat ei­ne ei­ge­ne Me­trik ent­wi­ckelt. Sie hört auf den Na­men But­ter­aug­li und be­haup­tet von sich, neue­re, kon­kre­te­re wis­sen­schaft­li­che Er­kennt­nis­se über das mensch­li­che Seh­ver­mö­gen und -emp­fin­den ab­zu­bil­den. Guetz­li ist noch in ei­nem frü­hen Ent­wick­lungs­sta­di­um und in sei­ner Funk­ti­on et­was ein­ge­schränkt. Er lässt der­zeit nur re­la­tiv ho­he Qua­li­täts­stu­fen zu und kann in die­sem Be­reich auch durch­aus be­acht­li­che Er­geb­nis­se er­zie­len. Ich bin als Blog­ger al­ler­dings nicht an höchs­ter Qua­li­tät in­ter­es­siert, son­dern an ei­nem gu­ten Kom­pro­miss, bei dem die Bild­qua­li­tät nicht per­fekt sein muss. Im di­rek­ten Ver­gleich mit dem Quell­ma­te­ri­al dür­fen ru­hig Un­ter­schie­de fest­stell­bar sein, aber für sich ge­nom­men sol­len die Bil­der nicht ne­ga­tiv auf­fal­len. Das kann Guetz­li ein­fach nicht und fliegt so­mit aus mei­ner Aus­wahl.
Au­ßer­dem ist Guetz­li un­glaub­lich spei­cher­hung­rig (grö­ße­re Bil­der fres­sen auch mehr RAM) und ar­bei­tet da­bei im Schne­cken­tem­po; je nach Grö­ße kann die Ko­die­rung ei­nes Bil­des ei­ni­ge Mi­nu­ten dau­ern. Ein viel­ver­spre­chen­der pro­of of con­cept ist das, aber in der Pra­xis der­zeit nicht zu ge­brau­chen.

Ver­gleichs­wei­se ge­reift ist da­ge­gen schon das Mo­zil­la-Pro­jekt Moz­J­PEG, des­sen ers­te Ver­si­on An­fang 2014 er­schien. Es han­delt sich um ei­nen Fork der be­reits an­ge­spro­che­nen libj­peg-tur­bo. Ei­ner­seits macht sich der En­co­der ei­ni­ge schon län­ger be­kann­te, zum Teil ver­lust­freie Me­tho­den zur Op­ti­mie­rung zu­nut­ze, die in der nor­ma­len libj­peg ent­we­der nicht im­ple­men­tiert oder per de­fault de­ak­ti­viert sind. Au­ßer­dem kommt hier zum ers­ten mal bei ei­ner JPEG-li­bra­ry die so­ge­nann­te Trel­lis-Quan­ti­sie­rung zum Ein­satz, die man auch in mo­der­nen Vi­deo­co­decs wie­der­fin­det.

Das Kom­man­do­zei­len-Tool steht im Quell­code zur Ver­fü­gung, es gibt auch in­of­fi­zi­el­le Bi­na­ries für Li­nux und Win­dows. Ob letz­te­re mit den gän­gi­gen Dis­tros auch pro­blem­los fun­zen ha­be ich bis­her nicht aus­pro­biert.

Moz­J­PEG ist weit­ge­hend kom­pa­ti­bel mit der libj­peg-tur­bo, kann aber au­ßer JPEG kom­pri­mie­ren nicht viel. Al­so muss Image­ma­gick für Ska­lie­rung und Pre-Pro­ces­sing her­hal­ten. Das ah­nungs­los zu­sam­men­ge­klau­te Ba­sis-Skript sieht bei mir so aus:


for img in `ls *.jpg`
do
convert $img -resize 960 -filter lanczos -define filter:blur=1.2 pnm:- | /opt/mozjpeg/bin/cjpeg -quality 72 -progressive -smooth 10 -optimize > M$img
done

Die Qua­li­täts­stu­fen sind nicht eins zu eins von der nor­ma­len libj­peg über­trag­bar, da­her muss et­was ex­pe­ri­men­tiert wer­den, bis ein gu­ter Kom­pro­miss von Qua­li­tät und Kom­pres­si­on ge­fun­den ist.
Mit dem Zu­satz -define filter:blur=1.2 brin­ge ich dem an sich sehr cris­pen Lan­c­zos-Ska­lie­rer ein we­nig Un­schär­fe bei und las­se den JPEG-En­co­der mit -smooth 10 noch­mal et­was weich­zeich­nen. So tau­sche ich ein we­nig Bild­schär­fe für ei­ne bes­se­re Kom­pres­si­on ein, au­ßer­dem re­du­zie­ren sich so im Er­geb­nis sehr deut­lich die Rin­ging-Ar­te­fak­te, die be­son­ders an har­ten Kan­ten auf­tre­ten.

Da­mit las­sen sich bei brauch­ba­rer Qua­li­tät schon ei­ni­ge Pro­zent an Da­ten ein­spa­ren. In et­wa auf ei­ner Hö­he mit den er­wähn­ten On­line-Op­ti­mie­rern, die ver­mut­lich auch gar nichts an­de­res ma­chen.

 

Auf unnötige Bildgrößen verzichten

Um re­spon­si­ves Ver­hal­ten zu un­ter­stüt­zen, legt Word­Press au­to­ma­tisch Ko­pien al­ler Bil­der in un­ter­schied­li­chen Auf­lö­sun­gen an. Mit gro­ßem Er­stau­nen stell­te ich fest, dass das neue The­me sa­ge und schrei­be sechs neue Bild­grö­ßen in un­ter­schied­li­chen Sei­ten­ver­hält­nis­sen de­fi­niert. Kei­ne ein­zi­ge die­ser Ko­pien braucht man für ein re­gu­lä­res Blog, wenn man sich in der Ge­stal­tung der Posts auf die Word­Press-Bord­mit­tel be­schränkt. Was man so­wie­so tun soll­te, sonst macht man sich von Zu­satz­funk­tio­nen des The­mes ab­hän­gig und beim nächs­ten Re­launch hat man ein Pro­blem. Al­so weg mit dem Bal­last.
We­gen der hö­he­ren Auf­lö­sung wer­den jetzt auch von Word­Press vor­ge­ge­be­ne Ko­pien mit ei­ner Brei­te von 768 Pi­xeln an­ge­legt. Weil Word­Press ja nur auf die von mei­nem Hos­ter ver­füg­ba­re Ver­si­on der libj­peg zu­grei­fen kann, sind die­se Bil­der, wenn über­haupt, nur sehr ge­ring­fü­gig schlan­ker als das op­ti­mier­te Ori­gi­nal mit 960px. Da­her schlu­cken sie nur un­nö­tig Spei­cher­platz und hel­fen kein biss­chen bei La­de­zei­ten und Re­spon­si­ve-Klim­bim. Al­so auch weg da­mit. Das lässt sich mit ei­nem Plug­in be­werk­stel­li­gen oder von Hand, üb­li­cher­wei­se fin­det sich der Code da­zu in der functions.php. Üb­rig blei­ben dann die Grö­ßen "Me­di­um" mit 300px Brei­te und "Th­umb­nail" mit 150px. Bei­de er­ge­ben in mei­nen Au­gen Sinn und fal­len Spei­cher­mä­ßig kaum ins Ge­wicht.

So, das war der Stand in den letz­ten Wo­chen und so rich­tig zu­frie­den war ich da­mit nicht. Geht es noch bes­ser? Aber si­cher doch.

 

Stufe zwei: Konstante Qualität mit jpeg-recompress

Moz­J­PEG hat zwar ei­nen deut­li­chen Kom­pres­si­ons­ge­winn, schleppt aber auch ei­ne gro­ße Schwä­che der al­ten libj­peg mit sich her­um: Bei ei­ner ge­ge­be­nen Kom­pres­si­ons­stu­fe schwankt die er­ziel­te Qua­li­tät er­heb­lich. Man­che Bil­der könn­te man viel här­ter an­pa­cken oh­ne dass es groß auf­fält, an­de­re bräuch­ten ein­fach ein paar kB mehr um zu über­zeu­gen.
Er­in­nert ihr euch, was ich über SSIM ge­schrie­ben hab? Die Mo­zil­la-Ent­wick­ler be­nutz­ten auch SSIM um die Ef­fi­zi­enz von Moz­J­PEG zu tu­nen, aber die ein­ge­stell­te Qua­li­täts­stu­fe ver­än­dert nur di­ver­se Pa­ra­me­ter im En­co­der, be­stimmt da­mit letzt­end­lich nur die Stär­ke der Kom­pres­si­on. Und das Maß an Kom­pres­si­on ist nicht gleich­zu­set­zen mit sub­jek­ti­ver Qua­li­tät.
Des­halb muss­te ich in den ver­gan­ge­nen Wo­chen je­des Bild erst mal kon­trol­lie­ren und bei Be­darf ei­ne hö­he­re Qua­li­täts­stu­fe an­wen­den.

Hier setzt ein ge­nia­les Tool na­mens jpeg-re­com­press an. Ur­sprung­lich für den Ein­satz mit libj­peg-tur­bo ge­dacht, steht in­zwi­schen auch ei­ne Ver­si­on zur Ver­fü­gung, die mit Moz­J­PEG zu­sam­men­ar­bei­tet.
Jpeg-re­com­press hat es sich zum Ziel ge­setzt, nicht Bil­der von kon­stan­ter Kom­pres­si­on, son­dern von kon­stan­ter Qua­li­tät zu lie­fern. Des­halb will jpeg-reen­code auch nichts von Kom­pres­si­ons­stu­fen wis­sen, statt­des­sen wählt man ein Pre­set oder - in mei­nen Au­gen sinn­vol­ler - ei­nen Ziel-Wert in SSIM oder ei­ner an­de­ren vom Tool un­ter­stütz­ten Me­trik.

Al­so neh­me ich mir als ers­tes mal ei­ni­ge mit Moz­J­PEG er­zeug­te Bil­der vor und ma­che mich schlau, was für SSIM-Wer­te die denn er­rei­chen. Da­zu ist das mit­ge­lie­fer­te Tool jpeg-compa­re hilf­reich. Da­mit die­ser Test sinn­vol­le Er­geb­nis­se lie­fert, muss das Quell­ma­te­ri­al be­reits auf die Ziel­auf­lö­sung her­un­ter­ska­liert sein. Jetzt kann ich dar­aus mei­ne Schlüs­se zie­hen und mich lang­sam an den Wert her­an­tas­ten, der für mich durch­weg zu­frie­den­stel­len­de Er­geb­nis­se lie­fert.

Um die­sen zu er­rei­chen ruft jpeg-re­com­press wie­der­holt Moz­J­PEG auf und kom­pri­miert das Bild im ers­ten Durch­gang mit der Qua­li­täts­stu­fe 80. Dann checkt er den SSIM-Wert und ver­wirft das Bild. Ist der Wert hö­her als ge­wünscht (hö­her ist bes­ser), wird im nächs­ten Durch­gang die Kom­pres­si­on er­höht. Ist er nied­ri­ger als ge­wünscht, wird die kom­pres­si­on ver­rin­gert. Das macht er per de­fault acht mal und nä­hert sich so dem ge­wünsch­ten Wert an. Erst im letz­ten Durch­gang wird das Bild ge­spei­chert, das jetzt sehr nah an der ge­wünsch­ten Qua­li­tät ist.
In der Shell sieht das so aus:

Metadata size is 0kb
ms-ssim at q=80 (60 - 100): 0.967018
ms-ssim at q=69 (60 - 79): 0.955776
ms-ssim at q=74 (70 - 79): 0.963294
ms-ssim at q=71 (70 - 73): 0.954818
ms-ssim at q=72 (72 - 73): 0.954625
ms-ssim at q=73 (73 - 73): 0.956991
ms-ssim at q=74 (74 - 73): 0.963294
ms-ssim at q=74 (74 - 73): 0.963294
ms-ssim at q=74 (74 - 73): 0.963294
Final optimized ms-ssim at q=74: 0.963497
New size is 4% of original (saved 2588 kb)

Und das Skript da­zu sieht so aus:

for img in `ls *.jpg`
do
convert $img -resize 960 -filter lanczos ppm:- | jpeg-recompress --ppm --method ms-ssim --accurate --target 0.96000 --min 60 --max 100 --loops 10 - J$img
done

Das al­les funk­tio­niert ganz her­vor­ra­gend. Vie­le Bil­der wer­den jetzt stär­ker kom­pri­miert und se­hen trotz­dem ein­wand­frei aus. An­de­re wer­den deut­lich grö­ßer als bis­her und ein klei­ner Check mit dem nack­ten Moz­J­PEG be­stä­tigt, dass sie die zu­sätz­li­chen Bits auch brau­chen. Gro­ße Über­ra­schun­gen kom­men nicht mehr vor. Ins­ge­samt ist die Er­spar­nis so groß, dass ich kom­plett auf die Weich­zeich­ner ver­zich­ten kann. Mit ei­ner durch­schnitt­lich im­mer noch et­was ge­rin­ge­ren Da­tei­grö­ße.

Das kom­pri­mie­ren ei­nes Bil­des dau­ert mit den er­wähn­ten Ein­stel­lun­gen ein paar Se­kun­den, das fin­de ich ver­tret­bar. Aber mann kann den Vor­gang auch stark be­schleu­ni­gen, wenn man an­statt der re­chen­in­ten­si­ven MS-SSIM Me­trik die schnel­ler zu er­rech­nen­den, nor­ma­len SSIM-Wer­te be­nutzt. Auch der Ver­zicht auf den --accurate Switch hat kei­nen gro­ßen Ein­fluss auf das Er­geb­nis und be­schleu­nigt den Vor­gang sehr.

Den --min Switch darf man nicht zu nied­rig an­set­zen: Mit ei­nem zu nied­ri­gen Wert wird es bei ei­ni­gen Bil­dern häss­lich. Bes­ser bei der sehr sinn­vol­len Vor­ein­stel­lung von 60 blei­ben. Nach oben hin set­ze ich kei­ne Gren­ze, hier gilt: --max 100 .

Al­so, das Fa­zit fällt gut aus. Or­dent­li­che Qua­li? Check! Durch­schnitt­lich knapp un­ter 100 kB? Yupp.
So lässt es sich wie­der ar­bei­ten.

 

Up­date 11.8.2017

Smallfry vs. MS-SSIM

Ich hab in der Zwi­schen­zeit auch mal der eben­falls in Jpeg-Re­com­press im­ple­men­tier­ten Small­fry-Me­trik ei­ne Chan­ce ge­ge­ben, weil ei­ni­ge User gu­te Er­fah­run­gen da­mit be­rich­tet hat­ten. Ich kann die Be­geis­te­rung nicht wirk­lich tei­len. Viel­leicht per­formt die schön flott zu er­rech­nen­de Me­trik bes­ser für rei­ne Fo­tos oder bei ge­rin­ge­rer Kom­pres­si­on. Ich hat­te aber we­nig Glück mit dem doch sehr un­ter­schied­li­chen Bild­ma­te­ri­al für die­ses Blog.

Ein­mal den pas­sen­den Ziel­wert ge­fun­den, der bei ei­ner zu­fäl­li­gen Aus­wahl von 100 Bil­dern die glei­che durch­schnitt­li­che Da­tei­grö­ße er­reicht wie die bis­he­ri­gen Ein­stel­lun­gen (Me­trik: MS-SSIM, Ziel­wert: 0,95), zei­gen sich dann doch recht vie­le Qua­li­täts-Aus­rei­ßer im Ver­gleich mit MS-SSIM. Be­son­ders bei de­tail­lier­ten Ob­jek­ten vor ei­nem "sau­be­ren", uni­for­men Hin­ter­grund und be­son­ders bei far­bi­gem Bild­ma­te­ri­al scheint die Ge­wich­tung nicht so recht mit dem sub­jek­ti­ven Ein­druck zu kor­re­lie­ren; Small­fry scheint sich da­bei an für's mensch­li­che Au­ge sehr auf­fäl­li­ger Block­bil­dung nicht zu stö­ren. Von den ver­füg­ba­ren Me­tri­ken er­zielt MS-SSIM hier im­mer noch die zu­ver­läs­sigs­ten Er­geb­nis­se.

Es sei er­wähnt, dass der­zeit ei­ni­ge in­ter­es­san­te Ent­wick­lun­gen statt­fin­den. Ins­be­son­de­re bei neu­en Me­tri­ken, die spe­zi­ell dar­auf op­ti­miert sind, Ar­te­fak­te block­ba­sier­ter Kom­pres­si­on (Block­bil­dung, Rin­ging, Mos­qui­to-Noi­se) zu er­ken­nen und zu be­wer­ten. Un­ter an­de­rem er­scheint mir SSI­Mu­la­cra, sehr viel­ver­spre­chend. Da es lei­der (noch?) kei­ne ge­brauchs­fer­ti­ge Soft­ware-Im­ple­men­tie­rung gibt, konn­te ich den Krem­pel bis­her nicht aus­pro­bie­ren.

 

Farbe und Graustufen

Ich hab mich von An­fang an ge­wun­dert, dass JPEG-Re­com­press kei­nen greysca­le-Switch hat. Den be­nö­tigt Moz­J­PEG laut Do­ku­men­ta­ti­on, weil der En­co­der von sich aus (noch?) kein mo­no­chro­mes Ma­te­ri­al er­kennt.

Bei ge­naue­rer In­spek­ti­on der Er­geb­nis­se zeigt sich aber, dass eins von bei­den Tools de­fi­ni­tiv mit Grau­stu­fen um­ge­hen kann. Ent­we­der er­kennt JPEG-Re­com­press den nicht vor­han­de­nen Farb­ka­nal und setzt dann den --greyscale Switch, oder Moz­J­PEG geht sehr wohl von selbst in den Grau­stu­fen­mo­dus, wenn es "ech­tes" mo­no­chro­mes Ma­te­ri­al ge­füt­tert be­kommt.
Vor­aus­set­zung ist, dass im Quell­ma­te­ri­al auch wirk­lich kein Farb­ka­nal vor­han­den ist. In mei­ner Image­ma­gick-Pi­pe sorgt der Switch -colorspace gray für die in­ter­ne Farb­raum­kon­ver­tie­rung und -type grayscale stellt dann si­cher, dass auch der Out­put kei­nen Farb­ka­nal ver­passt be­kommt.

Es stellt sich her­aus, dass sich die er­ziel­ten MS-SSIM-Wer­te und da­mit die Kom­pres­si­ons­stu­fen und Da­tei­grö­ßen doch er­heb­lich un­ter­schei­den kön­nen zwi­schen ei­nem Grau­stu­fen-ko­dier­ten Jpeg und ei­nem aus der glei­chen mo­no­chro­men Quel­le stam­men­den, in Far­be ko­dier­ten Bild. Das fin­de ich be­son­ders des­halb in­ter­es­sant, weil nach mei­nem Wis­sen MS-SSIM so­wie­so nur mit mo­no­chro­mem Ma­te­ri­al ar­bei­tet, Farb­infor­ma­tio­nen vor der Ana­ly­se al­so ent­we­der ver­wor­fen oder kon­ver­tiert wer­den. Mög­li­che Er­klä­run­gen wä­ren das Chro­ma Sub­sam­pling des JPEG-For­ma­tes oder Un­ter­schie­de im Ver­hal­ten von Moz­J­PEG - viel­leicht in der Trel­lis-Quan­ti­sie­rung - die von der MS-SSIM Me­trik sehr un­ter­schied­lich be­wer­tet wer­den.

Au­ßer­dem stellt sich her­aus, dass mo­no­chrom ko­dier­te Bil­der et­was här­ter an­ge­packt wer­den kön­nen. Auch hier kann ich nur spe­ku­lie­ren war­um. Es er­scheint mir aber plau­si­bel, dass die ty­pi­schen JPEG-Ar­te­fak­te im nor­ma­ler­wei­se eh deut­lich stär­ker kom­pri­mier­ten Farb­ka­nal für die mensch­li­che Wahr­neh­mung auf­fäl­li­ger sind.

Wie dem auch sei, ich hab jetzt al­so zwei ge­trenn­te Skrip­te; eins für far­bi­ges und eins für mo­no­chro­mes Bild­ma­te­ri­al. Ne­ben den er­wähn­ten Image­ma­gick-Tweaks kann die mi­ni­ma­le Kom­pres­si­ons­stu­fe von mo­no­chro­men Bil­dern ru­hig von --min 60 auf --min 50 ver­rin­gert wer­den, oh­ne dass sich das bis­her in ne­ga­ti­ven Aus­rei­ßern be­merk­bar ge­macht hät­te.