Warum Online-Bildoptimierer für'n Arsch sind... (und wie man's selbst besser hinkriegt) [Update]

Das Kunst­werk heißt „Shit Flag“.

Sorry Leute, heute wird es tech­nisch. Also igno­riert das hier ein­fach, wenn’s nicht euer Ding ist.

Die Geschichte geht so: Vor einer Weile hab ich dem Blog ja äußer­lich eine neue Gestalt und unter der Haube ein tech­nisch etwas zeit­ge­mä­ße­res Theme spen­diert. Davor war es ganz ein­fach mit den Bil­dern: In vol­ler Auf­lö­sung hoch­ge­la­den, hat Imsa­nity das Zeug dann von selbst auf die dama­lige Breite von 604 Pixeln ska­liert. Mit der Wor­d­Press-Vor­ein­stel­lung für die JPEG-Kom­pres­sion (am Anfang „-qua­lity 90“, dann in neue­ren Ver­sio­nen auf „-qua­lity 82“ redu­ziert), sah das übli­cher­weise auch halb­wegs ansehn­lich aus, die Datei­grö­ßen hiel­ten sich mit durch­schnitt­lich weni­ger als 100 kB im Rah­men.

Mit dem moder­ne­ren Theme hiel­ten dann nicht nur etwas groß­zü­gi­gere Abmes­sun­gen son­dern natür­lich auch ein gewis­ses Maß an Respon­si­veness Ein­zug. Den Bil­dern ledig­lich ein paar zusätz­li­che Pixel spen­die­ren und „One size fits all“ für jedes Dis­play reicht da nicht mehr. Also lie­ber mal die neuen Bil­der mit aktu­ell 960 Pixeln etwas groß­zü­gi­ger dimen­sio­nie­ren als nötig, viel­leicht zahlt sich das ja bei der nächs­ten gro­ßen Umstel­lung noch mal aus; außer­dem sieht’s dann mit etwas Glück auch auf hoch­auf­lö­sen­den Dis­plays etwas weni­ger Scheiße aus (wobei man­che Retina-Dis­plays wohl­be­merkt ein viel­fa­ches davon ver­tra­gen könn­ten).

Jetzt muss ich also mit ziem­lich genau zwei­ein­halb mal so vie­len Pixeln pro Bild han­tie­ren. Das macht sich selbst­ver­ständ­lich in der Datei­größe bemerk­bar und so kommt der Wunsch auf, das Bytes/​Pixel-​Verhältnis etwas zu opti­mie­ren. Schließ­lich will ich wenn’s geht noch ein paar Jahre so wei­ter­blog­gen, ohne mei­nem (noch) ver­gleichs­weise güns­ti­gen Hos­ter mehr Geld abdrü­cken oder eine neue Hei­mat suchen zu müs­sen. (Auch wenn mich die Limi­tie­run­gen eines 08/​15 sha­red Webs­pace lang­sam ner­ven und ich zumin­dest mit ’nem ordent­li­chen VSer­ver lieb­äugle, bin ich doch gerade nicht wirk­lich in der Stim­mung für einen Ser­ver­um­zug.)
Außer­dem mag Google flott ladende Sei­ten und effi­zi­ent kom­pri­mierte Bil­der sind da ein gro­ßer Fak­tor (und denke ich dann an SEO und die ganze damit ein­her­ge­hende Bau­ern­fän­ge­rei, kommt mir gleich das Kot­zen… aber das ist noch­mal ein ganz ande­res Thema). Zu guter letzt muss ich dann noch ordent­lich Spei­cher­platz frei­hal­ten, etwa zum zwi­schen­spei­chern von Back­ups, die dann auto­ma­tisch per FTP auf einen Raspberry Pi bei mir Zuhause gescho­ben wer­den. Alles gute Gründe, ein wenig spar­sam mit dem Daten­auf­kom­men zu sein.

Meine Ziel­set­zung: Akzeb­ta­bles Bild­ma­te­rial mit einer durch­schnitt­li­chen Datei­größe von grob 100 kB pro Bild.

 

Man kann’s ja mal versuchen: Online-Bildoptimierer

Diese Dienste wer­den der­zeit an allen Ecken und Enden ange­prie­sen mit teil­weise recht magisch anmu­ten­den Ver­pre­chun­gen. Die meis­ten davon sind Fre­e­mium Ange­bote, mit einem in Funk­tion oder Durch­satz stark ein­ge­schränk­ten kos­ten­lo­sen Tier und kos­ten­pflich­ti­gen Ange­bo­ten, deren monat­li­che Gebüh­ren für kleine Blog­ger wie mich in kei­nem Ver­hält­nis zum Nut­zen ste­hen. Da muss man schon Pitch­fork sein, damit sich das lohnt.
Che­etao ist einer der weni­gen Anbie­ter, die auch einen bezahl­ba­ren Volu­men­ta­rif anbie­ten (ein­mal fünf Dol­lar raus­rü­cken für 3000 Bil­der, das würde bei mir für 3-4 Jahre aus­rei­chen) und des­halb hab ich der Bude mal ’ne Chance gege­ben, neben­bei aber auch ein paar kos­ten­lose Krü­mel ande­rer Anbie­ter auf­ge­pickt. Und tat­säch­lich waren die meis­ten davon in der Lage mit gutem Aus­gangs­ma­te­rial dem End­ergeb­nis ein paar Kilo­bytes abzu­luch­sen. Bei sub­jek­tiv glei­cher Bild­qua­li­tät, ver­gli­chen mit den übli­chen, auf der sehr alten libj­peg basie­ren­den Haus­mit­teln.
Neben­her hab ich noch ein paar andere Sachen ver­sucht und bin letzt­end­lich zum Schluss gekom­men, dass die Online-Bild­schrump­fer auch nur mit Was­ser kochen und ihre ach so bahn­bre­chen­den Ver­fah­ren gar nicht so geil sind. Mit etwas Gaf­fa­tape und ein paar Infos ist es kein Pro­blem, auf dem hei­mi­schen Rech­ner und ohne wahn­sin­ni­gen Auf­wand bes­sere Ergeb­nisse zu erzie­len. (Hier sei ange­merkt, dass auf mei­nem All­tags-Lap­top Ubuntu läuft. Die ange­spro­che­nen Tools sollte man auch auf nicht-*nix Sys­te­men ans Kacken krie­gen, das könnte poten­zi­ell aber mit mehr Fri­cke­lei ver­bun­den sein.)

 

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

Zwei Pro­jekte haben in den letz­ten Jah­ren klei­nere Wel­len geschla­gen mit dem Ver­such, einen zeit­ge­mä­ße­ren JPEG-Encoder zu bauen. Immer­hin ist die fast über­all ein­ge­bun­dene libj­peg und deren Per­for­mance-opti­mier­ter Fork libj­peg-turbo schon ziem­lich in die Jahre gekom­men.

Der jün­gere Ver­such kommt aus dem Hause Google und nennt sich Guetzli. Der über­wie­gende Teil aller JPEG-Encoder ist auf die SSIM-Metrik opti­miert, eines von vie­len Wahr­neh­mungs­psy­cho­lo­gi­schen Model­len mit dem Ziel, sich mit mathe­ma­ti­schen Mit­teln der mensch­li­chen Wahr­neh­mung anzu­nä­hern und somit einen Wert zu ermit­teln, wel­cher halb­wegs mit der von Men­schen emp­fun­de­nen, sub­jek­ti­ven Qua­li­tät eines Bil­des kor­re­liert. SSIM ver­gleicht immer zwei Bil­der mit­ein­an­der, im Fall von JPEG die Quell- mit der Ziel­da­tei. Der SSIM-Wert besagt, wie groß der unter­schied zwi­schen bei­den ist. Keine die­ser Metri­ken ist per­fekt, es wird auch noch flei­ßig dran geforscht und ent­wi­ckelt.

Google hat eine eigene Metrik ent­wi­ckelt. Sie hört auf den Namen But­terau­gli und behaup­tet von sich, neuere, kon­kre­tere wis­sen­schaft­li­che Erkennt­nisse über das mensch­li­che Seh­ver­mö­gen und -emp­fin­den abzu­bil­den. Guetzli ist noch in einem frü­hen Ent­wick­lungs­sta­dium und in sei­ner Funk­tion etwas ein­ge­schränkt. Er lässt der­zeit nur rela­tiv hohe Qua­li­täts­stu­fen zu und kann in die­sem Bereich auch durch­aus beacht­li­che Ergeb­nisse erzie­len. Ich bin als Blog­ger aller­dings nicht an höchs­ter Qua­li­tät inter­es­siert, son­dern an einem guten Kom­pro­miss, bei dem die Bild­qua­li­tät nicht per­fekt sein muss. Im direk­ten Ver­gleich mit dem Quell­ma­te­rial dür­fen ruhig Unter­schiede fest­stell­bar sein, aber für sich genom­men sol­len die Bil­der nicht nega­tiv auf­fal­len. Das kann Guetzli ein­fach nicht und fliegt somit aus mei­ner Aus­wahl.
Außer­dem ist Guetzli unglaub­lich spei­cher­hung­rig (grö­ßere Bil­der fres­sen auch mehr RAM) und arbei­tet dabei im Schne­cken­tempo; je nach Größe kann die Kodie­rung eines Bil­des einige Minu­ten dau­ern. Ein viel­ver­spre­chen­der proof of con­cept ist das, aber in der Pra­xis der­zeit nicht zu gebrau­chen.

Ver­gleichs­weise gereift ist dage­gen schon das Mozilla-Pro­jekt MozJ­PEG, des­sen erste Ver­sion Anfang 2014 erschien. Es han­delt sich um einen Fork der bereits ange­spro­che­nen libj­peg-turbo. Einer­seits macht sich der Encoder einige schon län­ger bekannte, zum Teil ver­lust­freie Metho­den zur Opti­mie­rung zunutze, die in der nor­ma­len libj­peg ent­we­der nicht imple­men­tiert oder per default deak­ti­viert sind. Außer­dem kommt hier zum ers­ten mal bei einer JPEG-library die soge­nannte Trel­lis-Quan­ti­sie­rung zum Ein­satz, die man auch in moder­nen Video­co­decs wie­der­fin­det.

Das Kom­man­do­zei­len-Tool steht im Quell­code zur Ver­fü­gung, es gibt auch inof­fi­zi­elle Bina­ries für Linux und Win­dows. Ob letz­tere mit den gän­gi­gen Dis­tros auch pro­blem­los fun­zen habe ich bis­her nicht aus­pro­biert.

MozJ­PEG ist weit­ge­hend kom­pa­ti­bel mit der libj­peg-turbo, kann aber außer JPEG kom­pri­mie­ren nicht viel. Also muss Image­ma­gick für Ska­lie­rung und Pre-Pro­ces­sing her­hal­ten. Das ahnungs­los zusam­men­ge­klaute Basis-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, daher muss etwas expe­ri­men­tiert wer­den, bis ein guter Kom­pro­miss von Qua­li­tät und Kom­pres­sion gefun­den ist.
Mit dem Zusatz -define filter:blur=1.2 bringe ich dem an sich sehr cris­pen Lan­c­zos-Ska­lie­rer ein wenig Unschärfe bei und lasse den JPEG-Encoder mit -smooth 10 noch­mal etwas weich­zeich­nen. So tau­sche ich ein wenig Bild­schärfe für eine bes­sere Kom­pres­sion ein, außer­dem redu­zie­ren sich so im Ergeb­nis sehr deut­lich die Rin­ging-Arte­fakte, die beson­ders an har­ten Kan­ten auf­tre­ten.

Damit las­sen sich bei brauch­ba­rer Qua­li­tät schon einige Pro­zent an Daten ein­spa­ren. In etwa auf einer Höhe mit den erwähn­ten Online-Opti­mie­rern, die ver­mut­lich auch gar nichts ande­res machen.

 

Auf unnötige Bildgrößen verzichten

Um respon­si­ves Ver­hal­ten zu unter­stüt­zen, legt Wor­d­Press auto­ma­tisch Kopien aller Bil­der in unter­schied­li­chen Auf­lö­sun­gen an. Mit gro­ßem Erstau­nen stellte ich fest, dass das neue Theme sage und schreibe sechs neue Bild­grö­ßen in unter­schied­li­chen Sei­ten­ver­hält­nis­sen defi­niert. Keine ein­zige die­ser Kopien braucht man für ein regu­lä­res Blog, wenn man sich in der Gestal­tung der Posts auf die Wor­d­Press-Bord­mit­tel beschränkt. Was man sowieso tun sollte, sonst macht man sich von Zusatz­funk­tio­nen des The­mes abhän­gig und beim nächs­ten Relaunch hat man ein Pro­blem. Also weg mit dem Bal­last.
Wegen der höhe­ren Auf­lö­sung wer­den jetzt auch von Wor­d­Press vor­ge­ge­bene Kopien mit einer Breite von 768 Pixeln ange­legt. Weil Wor­d­Press ja nur auf die von mei­nem Hos­ter ver­füg­bare Ver­sion der libj­peg zugrei­fen kann, sind diese Bil­der, wenn über­haupt, nur sehr gering­fü­gig schlan­ker als das opti­mierte Ori­gi­nal mit 960px. Daher schlu­cken sie nur unnö­tig Spei­cher­platz und hel­fen kein biss­chen bei Lade­zei­ten und Respon­sive-Klim­bim. Also auch weg damit. Das lässt sich mit einem Plugin bewerk­stel­li­gen oder von Hand, übli­cher­weise fin­det sich der Code dazu in der functions.php. Übrig blei­ben dann die Grö­ßen „Medium“ mit 300px Breite und „Thumb­nail“ mit 150px. Beide erge­ben in mei­nen Augen Sinn und fal­len Spei­cher­mä­ßig kaum ins Gewicht.

So, das war der Stand in den letz­ten Wochen und so rich­tig zufrie­den war ich damit nicht. Geht es noch bes­ser? Aber sicher doch.

 

Stufe zwei: Konstante Qualität mit jpeg-recompress

MozJ­PEG hat zwar einen deut­li­chen Kom­pres­si­ons­ge­winn, schleppt aber auch eine große Schwä­che der alten libj­peg mit sich herum: Bei einer gege­be­nen Kom­pres­si­ons­stufe schwankt die erzielte Qua­li­tät erheb­lich. Man­che Bil­der könnte man viel här­ter anpa­cken ohne dass es groß auf­fält, andere bräuch­ten ein­fach ein paar kB mehr um zu über­zeu­gen.
Erin­nert ihr euch, was ich über SSIM geschrie­ben hab? Die Mozilla-Ent­wick­ler benutz­ten auch SSIM um die Effi­zi­enz von MozJ­PEG zu tunen, aber die ein­ge­stellte Qua­li­täts­stufe ver­än­dert nur diverse Para­me­ter im Encoder, bestimmt damit letzt­end­lich nur die Stärke der Kom­pres­sion. Und das Maß an Kom­pres­sion ist nicht gleich­zu­set­zen mit sub­jek­ti­ver Qua­li­tät.
Des­halb musste ich in den ver­gan­ge­nen Wochen jedes Bild erst mal kon­trol­lie­ren und bei Bedarf eine höhere Qua­li­täts­stufe anwen­den.

Hier setzt ein genia­les Tool namens jpeg-recom­press an. Ursprung­lich für den Ein­satz mit libj­peg-turbo gedacht, steht inzwi­schen auch eine Ver­sion zur Ver­fü­gung, die mit MozJ­PEG zusam­men­ar­bei­tet.
Jpeg-recom­press hat es sich zum Ziel gesetzt, nicht Bil­der von kon­stan­ter Kom­pres­sion, 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 Augen sinn­vol­ler – einen Ziel-Wert in SSIM oder einer ande­ren vom Tool unter­stütz­ten Metrik.

Also nehme ich mir als ers­tes mal einige mit MozJ­PEG erzeugte Bil­der vor und mache mich schlau, was für SSIM-Werte die denn errei­chen. Dazu ist das mit­ge­lie­ferte Tool jpeg-com­pare hilf­reich. Damit die­ser Test sinn­volle Ergeb­nisse lie­fert, muss das Quell­ma­te­rial bereits auf die Ziel­auf­lö­sung her­un­ter­ska­liert sein. Jetzt kann ich dar­aus meine Schlüsse zie­hen und mich lang­sam an den Wert her­an­tas­ten, der für mich durch­weg zufrie­den­stel­lende Ergeb­nisse lie­fert.

Um die­sen zu errei­chen ruft jpeg-recom­press wie­der­holt MozJ­PEG auf und kom­pri­miert das Bild im ers­ten Durch­gang mit der Qua­li­täts­stufe 80. Dann checkt er den SSIM-Wert und ver­wirft das Bild. Ist der Wert höher als gewünscht (höher ist bes­ser), wird im nächs­ten Durch­gang die Kom­pres­sion erhöht. Ist er nied­ri­ger als gewünscht, wird die kom­pres­sion ver­rin­gert. Das macht er per default acht mal und nähert sich so dem gewünsch­ten Wert an. Erst im letz­ten Durch­gang wird das Bild gespei­chert, das jetzt sehr nah an der gewü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 dazu 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 alles funk­tio­niert ganz her­vor­ra­gend. Viele Bil­der wer­den jetzt stär­ker kom­pri­miert und sehen trotz­dem ein­wand­frei aus. Andere wer­den deut­lich grö­ßer als bis­her und ein klei­ner Check mit dem nack­ten MozJ­PEG bestä­tigt, dass sie die zusätz­li­chen Bits auch brau­chen. Große Über­ra­schun­gen kom­men nicht mehr vor. Ins­ge­samt ist die Erspar­nis so groß, dass ich kom­plett auf die Weich­zeich­ner ver­zich­ten kann. Mit einer durch­schnitt­lich immer noch etwas gerin­ge­ren Datei­größe.

Das kom­pri­mie­ren eines Bil­des dau­ert mit den erwähn­ten Ein­stel­lun­gen ein paar Sekun­den, das finde ich ver­tret­bar. Aber mann kann den Vor­gang auch stark beschleu­ni­gen, wenn man anstatt der rechen­in­ten­si­ven MS-SSIM Metrik die schnel­ler zu errech­nen­den, nor­ma­len SSIM-Werte benutzt. Auch der Ver­zicht auf den --accurate Switch hat kei­nen gro­ßen Ein­fluss auf das Ergeb­nis und beschleu­nigt den Vor­gang sehr.

Den --min Switch darf man nicht zu nied­rig anset­zen: Mit einem zu nied­ri­gen Wert wird es bei eini­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 setze ich keine Grenze, hier gilt: --max 100 .

Also, das Fazit fällt gut aus. Ordent­li­che Quali? Check! Durch­schnitt­lich knapp unter 100 kB? Yupp.
So lässt es sich wie­der arbei­ten.

 

Update 11.8.2017

Smallfry vs. MS-SSIM

Ich hab in der Zwi­schen­zeit auch mal der eben­falls in Jpeg-Recom­press imple­men­tier­ten Small­fry-Metrik eine Chance gege­ben, weil einige User gute Erfah­run­gen damit berich­tet hat­ten. Ich kann die Begeis­te­rung nicht wirk­lich tei­len. Viel­leicht per­formt die schön flott zu errech­nende Metrik bes­ser für reine Fotos oder bei gerin­ge­rer Kom­pres­sion. Ich hatte aber wenig Glück mit dem doch sehr unter­schied­li­chen Bild­ma­te­rial für die­ses Blog.

Ein­mal den pas­sen­den Ziel­wert gefun­den, der bei einer zufäl­li­gen Aus­wahl von 100 Bil­dern die glei­che durch­schnitt­li­che Datei­größe erreicht wie die bis­he­ri­gen Ein­stel­lun­gen (Metrik: MS-SSIM, Ziel­wert: 0,95), zei­gen sich dann doch recht viele Qua­li­täts-Aus­rei­ßer im Ver­gleich mit MS-SSIM. Beson­ders bei detail­lier­ten Objek­ten vor einem „sau­be­ren“, uni­for­men Hin­ter­grund und beson­ders bei far­bi­gem Bild­ma­te­rial scheint die Gewich­tung nicht so recht mit dem sub­jek­ti­ven Ein­druck zu kor­re­lie­ren; Small­fry scheint sich dabei an für’s mensch­li­che Auge sehr auf­fäl­li­ger Block­bil­dung nicht zu stö­ren. Von den ver­füg­ba­ren Metri­ken erzielt MS-SSIM hier immer noch die zuver­läs­sigs­ten Ergeb­nisse.

Es sei erwähnt, dass der­zeit einige inter­es­sante Ent­wick­lun­gen statt­fin­den. Ins­be­son­dere bei neuen Metri­ken, die spe­zi­ell dar­auf opti­miert sind, Arte­fakte block­ba­sier­ter Kom­pres­sion (Block­bil­dung, Rin­ging, Mos­quito-Noise) zu erken­nen und zu bewer­ten. Unter ande­rem erscheint mir SSI­Mu­la­cra, sehr viel­ver­spre­chend. Da es lei­der (noch?) keine gebrauchs­fer­tige Soft­ware-Imple­men­tie­rung gibt, konnte ich den Krem­pel bis­her nicht aus­pro­bie­ren.

 

Farbe und Graustufen

Ich hab mich von Anfang an gewun­dert, dass JPEG-Recom­press kei­nen greyscale-Switch hat. Den benö­tigt MozJ­PEG laut Doku­men­ta­tion, weil der Encoder von sich aus (noch?) kein mono­chro­mes Mate­rial erkennt.

Bei genaue­rer Inspek­tion der Ergeb­nisse zeigt sich aber, dass eins von bei­den Tools defi­ni­tiv mit Grau­stu­fen umge­hen kann. Ent­we­der erkennt JPEG-Recom­press den nicht vor­han­de­nen Farb­ka­nal und setzt dann den --greyscale Switch, oder MozJ­PEG geht sehr wohl von selbst in den Grau­stu­fen­mo­dus, wenn es „ech­tes“ mono­chro­mes Mate­rial gefüt­tert bekommt.
Vor­aus­set­zung ist, dass im Quell­ma­te­rial auch wirk­lich kein Farb­ka­nal vor­han­den ist. In mei­ner Image­ma­gick-Pipe sorgt der Switch -colorspace gray für die interne Farb­raum­kon­ver­tie­rung und -type grayscale stellt dann sicher, dass auch der Out­put kei­nen Farb­ka­nal ver­passt bekommt.

Es stellt sich her­aus, dass sich die erziel­ten MS-SSIM-Werte und damit die Kom­pres­si­ons­stu­fen und Datei­grö­ßen doch erheb­lich unter­schei­den kön­nen zwi­schen einem Grau­stu­fen-kodier­ten Jpeg und einem aus der glei­chen mono­chro­men Quelle stam­men­den, in Farbe kodier­ten Bild. Das finde ich beson­ders des­halb inter­es­sant, weil nach mei­nem Wis­sen MS-SSIM sowieso nur mit mono­chro­mem Mate­rial arbei­tet, Farb­in­for­ma­tio­nen vor der Ana­lyse also ent­we­der ver­wor­fen oder kon­ver­tiert wer­den. Mög­li­che Erklä­run­gen wären das Chroma Sub­sam­pling des JPEG-For­ma­tes oder Unter­schiede im Ver­hal­ten von MozJ­PEG – viel­leicht in der Trel­lis-Quan­ti­sie­rung – die von der MS-SSIM Metrik sehr unter­schied­lich bewer­tet wer­den.

Außer­dem stellt sich her­aus, dass mono­chrom kodierte Bil­der etwas här­ter ange­packt wer­den kön­nen. Auch hier kann ich nur spe­ku­lie­ren warum. Es erscheint mir aber plau­si­bel, dass die typi­schen JPEG-Arte­fakte im nor­ma­ler­weise 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 also zwei getrennte Skripte; eins für far­bi­ges und eins für mono­chro­mes Bild­ma­te­rial. Neben den erwähn­ten Image­ma­gick-Tweaks kann die mini­male Kom­pres­si­ons­stufe von mono­chro­men Bil­dern ruhig von --min 60 auf --min 50 ver­rin­gert wer­den, ohne dass sich das bis­her in nega­ti­ven Aus­rei­ßern bemerk­bar gemacht hätte.