Denn wenn es erstmal als Wavelet vorliegt, dann sind die Wavelets doch mathematische Beschreibungen wie z.B. Funktionen, Bezierkurven usw. und damit dürfte es doch völlig gleichgültig sein, bei welcher Auflösung und welcher Zoomeinstellung man so einen Film anschaut.

Ob auf einem 5 m² Bildschrim mit 50000*3xxxx Pixeln oder auf einem normalen HDTV Monitor mit 19xx*1xxx Bildpunkten, auf keinem wird das Video verpixeln.

Denn Pixelartefakte, wie man sie noch von h.263 (MPEG-4 ASP, also DivX, XVid) kennt, gibt es bei h.264 ja allein wegen der mathematischen Wavelet Beschreibung nicht, bzw. kann es diese nicht geben.

Ist dies richtig?

PS:
Natürlich ist mir klar, daß man durch eine Änderung der Zoomeinstellung keinen Informationsgewinn erhält, es geht nur um die Pixelbildung.

Eigentlich müßte so ein MPEG4 AVC Video doch stufenlos dank Waveletkomprimierung zoombar sein.

seit wann verwendet h.264 wavelets?

Denn wenn es erstmal als Wavelet vorliegt, dann sind die Wavelets doch mathematische Beschreibungen wie z.B. Funktionen, Bezierkurven usw. und damit dürfte es doch völlig gleichgültig sein, bei welcher Auflösung und welcher Zoomeinstellung man so einen Film anschaut.

ja, klar. das selbe kannst du aber mit jedem bild oder video machen, indem du es erstmal mittels wavelets zerlegst, und dann mit höhrer auslösung wieder zusammenbaust. und du kannst das ganze noch einfacher mit einem "ganz normalen" filter haben - du musst nur die passenden koeffizienten wählen.
das ergebnis sieht dann exakt gleich aus. keine hexerei.

Denn Pixelartefakte, wie man sie noch von h.263 (MPEG-4 ASP, also DivX, XVid) kennt, gibt es bei h.264 ja allein wegen der mathematischen Wavelet Beschreibung nicht, bzw. kann es diese nicht geben.

Ist dies richtig?

selbst wenn H.264 wavelets verwenden würde, wäre das alleine noch nicht ausreichend dafür, dass es keine "pixeligen" artefakte mehr gibt.
h.264 verwendet motion-compensation die auf quadratischen blöcken basiert. dabei können immer wieder mal kleine pixelige artefakte entstehen. wenn die bitrate nicht hoch genug ist, dass diese im selben frame dann noch wegkorrigiert werden können, dann hast du immer pixelhaufen - ob nun mit wavelets oder nicht.

natürlich könnte man von den scharf begrenzten quadratischen blöcken für motion-compensation weggehen, und stattdessen benachbarte motion-compensation bereiche sanft überblenden, oder etwas in der art. tut h.264 aber soweit ich weiss nicht. und ich vermute dass man sich dadurch andere nachteile einkaufen würde, die u.u. sogar zu einem insgesamt schlechteren ergebnis führen würden.

und wie gesagt: h.264 und wavelets? wäre mir neu.

Hmm, ist h.264 / mpeg4-avc denn überhaupt ein wavelet-codec?

Ja, genauso wie JPEG2000 auch.

geeky schrieb:

Hmm, ist h.264 / mpeg4-avc denn überhaupt ein wavelet-codec?

Ja, genauso wie JPEG2000 auch.

Kannst du das auch belegen?
Für H.264 natürlich, dass JPEG2K Wavelets verwendet weiss ich auch.

wikipedia schrieb:

H.264/AVC is the latest block-oriented motion-compensation-based codec standard developed by the ITU-T Video Coding Experts Group (VCEG) together with the ISO/IEC Moving Picture Experts Group (MPEG)

"block oriented" und "wavelet" widersprechen sich schonmal gänzlich.
und auch auf der ganzen wikipedia seite kein wort von wavelets.
tjo.
sowas.

hätte mich auch sehr gewundert.

"block oriented" und "wavelet" widersprechen sich schonmal gänzlich.

war's nicht so, dass 'ne DWT blöcke in der grösse von zweierpotenzen als input braucht?

wikipedia schrieb:

H.264/AVC is the latest block-oriented motion-compensation-based codec standard developed by the ITU-T Video Coding Experts Group (VCEG) together with the ISO/IEC Moving Picture Experts Group (MPEG)

"block oriented" und "wavelet" widersprechen sich schonmal gänzlich.

H.264 verwendet keine wavelets.
aber wavelets und block oriented widerspricht sich nicht. auch wavelet codecs haben eine block oriented motion-estimation (wie sonst? per pixel? ). wavelets kann man dann einsetzen um die key- und redisual frames zu komprimieren. auch hab ich schon nen wavelet basierten deblocking filter gesehen (ich weiss nichts genaues, mir wurde nur gesagt dass was ich sehe wavelet deblocking ist).
grundsaetzlich wuerde nichts technisches dagegensprechen wavelets auf bloecken anzuwenden.
aber blockweise zu komprimieren verursacht artefakte, das macht man bei jpg/mpeg aus praktischen gruenden, optimal waere es auch bei DCT fullscreen zu arbeiten.

hab mal meinen alten dct encoder ausgepackt
http://img44.imageshack.us/img44/7476/test128.png
512x512 bild mit blocksize 256x256, mit 512x512 als blocksize sieht man natuerlich keine blocking artefakte mehr aber andere. (sieht man schon ansatzweise bei diesen bloecken z.b. dass das violet im linken unteren quadranten praegnant ist.

wavelet und dct erzeugen also eigentlich die selben artefakte bei gleicher reduktionsrate, nur ist wavelet trivialer zu implementieren, sowohl verlustbehaftet als auch verlustfrei. sogar simple embeded systeme ohne jegliche float faehigkeiten koennen das effektiv.

wavelet und dct erzeugen also eigentlich die selben artefakte bei gleicher reduktionsrate, nur ist wavelet trivialer zu implementieren, sowohl verlustbehaftet als auch verlustfrei. sogar simple embeded systeme ohne jegliche float faehigkeiten koennen das effektiv.

Wenn wavelet soviel einfacher ist, wieso braucht dann eine JPEG2000 Datei beim Öffnen so viel länger, als eine normale JPEG Datei die noch das gute alte DCT verwendet?

rapso schrieb:

wavelet und dct erzeugen also eigentlich die selben artefakte bei gleicher reduktionsrate, nur ist wavelet trivialer zu implementieren, sowohl verlustbehaftet als auch verlustfrei. sogar simple embeded systeme ohne jegliche float faehigkeiten koennen das effektiv.

Wenn wavelet soviel einfacher ist, wieso braucht dann eine JPEG2000 Datei beim Öffnen so viel länger, als eine normale JPEG Datei die noch das gute alte DCT verwendet?

ich habe mal das wort markiert was du so geschickt ueberlesen hast.

dennoch beantworte ich deine frage gerne
1.die meiste software die ich bisher sah mit jpeg2000 basiert auf der referenz implementierung. die ist auch bei jpeg langsam. z.b. konnte man auf nem PentiumMMX166 mit so ca 20fps JPegs entpacken waehrend die selben JPegs mit der referenz lib sekunden brauchten. kann also sein dass jpeg2000 noch sehr beschleunigt wird wenn z.b. intel seine haende dran legt.
2.wie ich schon sagte, man muss bei DCT bloecke verwenden damit die implementierung relativ simpel ist. damit ist die laufzeitskomplexitaet O(n), weil jeder block gleich aufwendig ist und mit steigender aufloesung linear mehr bloecke aufkommen.
wuerdest du das fuer full screen machen, wuerde es entsprechend auch ein wenig laenger dauern, besonders weil man dann weit mehr speicher bewegt als in den cache passt. DCT mit FFT waere vom laufzeit aufwand O(n log n) bei 1D, wavelets sollten O(n) haben, weil bei einer verdoppelung der aufloesung ein pass extra dazu kommt, der soviele pixel bewegt wie alle darunterliegenden passes akkumuliert (auch in 1D gemeint).
dazu kommt dass wavelet konstante kosten hat die in etwa (a+b)/2 und (b-a)/2 sind. DCT hingegen eine sinusfunktion aufruft oder wenigstens eine LUT ausliest und multipliziert. die konstanten kosten sind also nicht guenstiger.
3. ich kenne mich zwar mit wavelets aus, aber nicht im detail mit jpeg2000, daher kann ich dir nicht 100% genau den aufwand der einzelnen teile abschaetzen. jedoch hab ich im kopf dass jpeg2000 einen arithmetic coder benutzt, diese sind sehr aufwendig. das ist ein grund weshalb z.B. H.264 verschiedene entrophy coder in der spezifikation erlaubt. Moblie chips wuerden schon beim adaptiven arithmetic decoder sterben. Jpeg hat hingegen simples RLE+huff (obwohl der standard auch AC erlaubt, nur verwendet das niemand).

wavelet und dct erzeugen also eigentlich die selben artefakte bei gleicher reduktionsrate, nur ist wavelet trivialer zu implementieren, sowohl verlustbehaftet als auch verlustfrei. sogar simple embeded systeme ohne jegliche float faehigkeiten koennen das effektiv.

DCT blocking-artefakte und wavelet artefakte sehen gänzlich anders aus.
und klar kann man wavelets auch mit blöcken verwenden, aber ich denke das macht grad wenig sinn. das schöne an wavelets ist ja, dass man ohne blöcke arbeiten kann.

rapso schrieb:

wavelet und dct erzeugen also eigentlich die selben artefakte bei gleicher reduktionsrate, nur ist wavelet trivialer zu implementieren, sowohl verlustbehaftet als auch verlustfrei. sogar simple embeded systeme ohne jegliche float faehigkeiten koennen das effektiv.

DCT blocking-artefakte und wavelet artefakte sehen gänzlich anders aus.
und klar kann man wavelets auch mit blöcken verwenden, aber ich denke das macht grad wenig sinn. das schöne an wavelets ist ja, dass man ohne blöcke arbeiten kann.

1. es gibt blocking artefakte, sie sind nur viel unscheinbarer, sie entstehen durch motion compensation (edit: also bei gaengigen movie codecs die auf 2d-wavelet basieren, 3d wavelets haben natuerlich theoretisch keinen und praktisch nur in der zeitachse, aber das auch nicht schlimmer als sonstige codecs die keyframes haben).
2. die zusaetzlichen blocking artefakte bei mpeg usw. entstehen rein durch die entscheidung dct in kleinen bloecken zu berechnen, es liegt nicht an dct. die selbe entscheidung haette man auch bei wavelet treffen koennen. bzw kann man dct(wie mein bild zeigt) auch auf groessere bereiche anwenden bis full screen. es ist ne reine performance entscheidung. (wavelet hat entsprechend auch performance nachteile weil viel cashtrashing stattfindet).
3. ja, du hast recht, wavelet is trivialer zu implementieren und deswegen verzichtet man aufs blocking, aber ich glaube das hatte ich schon gesagt.