JPEG - warum 8x8 Bloecke?
-
Warum wird das Bild bei der verlustbehafteten JPEG-Kompression fuer die DCT ausgerechnet in 8x8 Pixel grosse Bloecke unterteilt? Warum nicht 16x16, 10x10 oder was ganz anderes?
Mir geht es nicht um die Frage, warum ueberhaupt eine Blockung stattfindet, sondern nur darum, warum diese Aufloesung gewaehlt wurde. Bisher habe ich nur einige Infos, die ich bestenfalls als unbelegt und ungenau bezeichnen kann, gefunden. Sowas wie dass es sich um einen Kompromiss zwischen guter Kompression und noch zu verschmerzendem Rechenaufwand handelt... Selbst in dem itu t.81 habe ich beim Ueberfliegen nichts dazu gefunden.Falls hier also zufaellig mal ein jpeg-Experte vorbei schaut ... bin ich ganz Auge.
-
Ich gucke auf http://en.wikipedia.org/wiki/Discrete_cosine_transform und lese
"Although the direct application of these formulas would require O(N2) operations, it is possible to compute the same thing with only O(N log N) complexity by factorizing the computation similarly to the fast Fourier transform (FFT)."
Aha. Also nehmen wir mal Zweierpotenzen. 10x10 dürfte kacke sein, weil 16x16 schätzungsweise genaususchnell geht (liege ich da richtig?).
Klar ist 8x8 ein wenig klein. 16x16 wäre cooler. 32x32 noch ein ganz wenig cooler. Aber viel mehr bringt dann keinen nennenswerten Gewinn mehr. Naja, hängt halt von den Ansprüchen ab. Aber damals war 8x8 noch ausreichend schnell, daß man meistens nur ein Sekündchen warten mußte, um das Bild zu sehen. 16x16 hat man sich nicht getraut. Würde ich mal vermuten.
http://www.fh-meschede.de/public/ries/skriptdatkomp_1.pdf
sagt, es sei allein die Rechenzeit.
-
Ich denke dass noch eine weitere Sache dazukommt: Je grösser die Blöcke, desto schlechter lassen sich hohe Frequenzen handhaben.
Bei kleiner Block-Grösse kann das sog. "Mosquito-Rauschen", das entsteht, wenn man die hochfrequenten Anteile stark quantisiert, auch nur jeweils kleine Blöcke "stören". Wenn hochfrequenten Bildanteile nur ein wenig "gestört" werden, ist das für das Auge wesentlich weniger störend, als wenn sie auf einmal an Stellen auftauchen, wo weit und breit keine hochfrequenten Bildanteile sein sollten.
-
Ohje, an die FFT habe ich da echt nicht gedacht. Das ist natuerlich mal ein starkes Argument.
Dieses Skript hatte ich auch schon gefunden.
Mir ist nur noch nicht ganz klar, warum es ab 64x64 keinen nennenswerten "Gewinn" (meint das Kompression?) mehr geben sollte... Naja, ist irgendwo auch ein anderes Thema.
Den Begriff "Mosquito-Rauschen" hatte ich auch nicht praesent, aber immerhin diese Probleme mit hohen Frequenzen bei all zu grossen Bloecken.
Danke euch.
-
Muss mich hier selbst korrigieren: "Mosquito Rauschen" ist ein gänzlich unüblicher Begriff, wie ich gerade selbst mit einiger Überrschaung feststellen musste. Wird fast nur im Englischen verwendet, also "mosquito noise".
-
JPEG wird ganz gut von Herr Sack erklärt, dazu gibt's mehrere Podcasts.
Video 3-4 dürfte relevant sein.
http://users.minet.uni-jena.de/~sack/SS08/RNIT08-materialien.htm#multimedia
-
damit der wertebereich gut handhabbar ist. als jpeg "erfunden" wurde, da hatten die meisten rechner keine fpu und embeded systeme schon garnicht, meistens gab es nur 16bit (also bei highen embededs) und afaik reicht 16bit-genauigkeit aus fuer gute qualitaet, auch der speicher den man zum dekodieren braucht ist tragbar (spezialhardware kann wohl seit anbeginn einen block in registern halten ) und die LUT die du brauchst passt auch gut.
groessere bloecke haetten nicht viel gebracht, denn es ist eine verlustbehaftete kompression, wenn jemand es besser gepackt haben will, dann quantitiziert er mehr.
-
Ich glaube, embedded systems waren für jpeg völlig irrelevant.
