Komprimieren, Packen, aus 4 mach 2 Byte??

CMatt

verlustfrei kommst du aber nur schwer auf die 2kb/bild von vorher, vielleicht QCIF,75kb/bild kommen.

Brauchst du nicht. So codiert sind nur die intra blocks, rest kommt doch nur alle x frames mal (mit jedem I frame).

aufgrund des rauschens, lässt die entrophie RLE so gut wie nicht zu.
beim speichern der differenzwerte hat man zudem öfter mal das problem, dass werte von -256 bis +256 aus ursprünglich 256 werten auftauchen können, das vergrößert die datenmenge dann sogar. natürlich kannst du diese pixel gesondert verwalten, aber verwalten = mehr daten.

Ich glaube das überschätz du etwas. Habs eben getestet (war auch neugierig *g*): Bild mit 2 leuten auf ner wiese -> RGB24 nach YUV420 ->
59% der pixel RLE comprimierbar.
Diese goßen Unterschiede sind eher selten. Falls es auftritt muss damit leben das man ein bit oder zwei mehr für den wert braucht, aber der großteil der änderungen in nem normalen bild liegt im bereich den man in 4 bits packen kann.

Wenn ich michts zu tun habe werde ich da zu dem ding mal ein test prog bauen, denn ausm bauch raus habe ich das gefühl das dürfte reichen.

Ich will euch hier aber sicher nicht davon abhalten wavlet oder ne DCT einzusetzten. Mit frequenz-werten stehen natrülich nochmal x möglichkeiten mehr offen und vor allem kann man das ding quantisieren was euch von allen 'zu viele daten-ängsten' erlösen dürfte Ich glaube halt nur das sich der aufwand nicht lohnt

rapso

CMatt schrieb:

Brauchst du nicht.

hoe? was braucht man nicht?

meine berechnung war simpel:
QCIF bild hat ~25000pixel, wenn du von bild zu bild die differenz pro pixel berechnest, hast du at least 3kbyte die dabei resultieren (bei 1bit/pixel). somit sind die interpolierten bilder schon zu groß für seine belangen, er muss ja 8bilder/10kbyte übertragen.

oder schlägst du vor für die 16pixel abzuspeichern welchen zeit-farb-verlauf sie haben?

CMatt schrieb:

Ich glaube das überschätz du etwas.

ich schätze nicht, ich hab's programmiert ;), um mehr redundanz zu haben hab ich es sogar auf 256color indices runterkonvertiert. bei 160*120 bin ich auf ca 3-7kb/bild gekommen beim T3 trailer.

rapso->greets();

CMatt

hoe? was braucht man nicht?

meine berechnung war simpel:
QCIF bild hat ~25000pixel, wenn du von bild zu bild die differenz pro pixel berechnest, hast du at least 3kbyte die dabei resultieren (bei 1bit/pixel). somit sind die interpolierten bilder schon zu groß für seine belangen, er muss ja 8bilder/10kbyte übertragen.

ich glaube wir reden an aneinder vorbei
Ich rede nicht von der pixel-für-pixel differenz zweier bilder, sondern von den pixeln in einer reihe.
Das intra frame wird so gecoded wie beschrieben, die danachfolgenen bestehen aus motion vectoren & einzelen intra blocks, da natürlich block-weise nicht pixel weise

ich schätze nicht, ich hab's programmiert , um mehr redundanz zu haben hab ich es sogar auf 256color indices runterkonvertiert. bei 160*120 bin ich auf ca 3-7kb/bild gekommen beim T3 trailer.

hmm... sehr interessant. Kann das bei mir was mit der RGB-YUV convertierung zu tun haben (das bild durch die convertierung deutlich 'weicher'). Habs eben noch mit ein paar anderen bildern versucht: ich bekomme da immer so zwichen 55-75% an RLE comprimierbaren pixelfolgen raus.

Hat einer von euch beiden mal den Code um RGB nach YCbCr und zurück zu Konventieren?
ala:

Y  =  0,2990*R + 0,5870*G + 0,1140*B
Cb = -0,1687*R - 0,3313*G + 0,5000*B
Cr =  0,5000*R - 0,4187*G - 0,0813*B

Entweder bin ich mitlerweile zu doof geworden um simple dinge zu proggen, durch das ganze, oder die Quellen sind Fehlerhaft.
(Ja, ich prüfe auf - zu 0 und >255 = 255)

rapso

DerPacker schrieb:

Entweder bin ich mitlerweile zu doof geworden um simple dinge zu proggen

... oder zu faul für mr google, aber nun gut, mach ich das mal für dich

http://www02.so-net.ne.jp/~koujin/jpeg/RGB2YCbCr.html

DerPacker schrieb:

durch das ganze, oder die Quellen sind Fehlerhaft. (Ja, ich prüfe auf - zu 0 und >255 = 255)

es ist auch möglich *0.95+0.25 zu rechnen (für werte von 0-1). was das bringt? bei konvertieren zu YCbCr udn zurück zu RGB ersparrst du dir, auf kosten von ein bisschen kontrast bzw sättigung, so einiges an konditional jumps, das kann ein wenig performance bringen ;)... (falls du es nicht gerade mit sse oder mmx machst.

rapso->greets();

rapso schrieb:

... oder zu faul für mr google, aber nun gut, mach ich das mal für dich

http://www02.so-net.ne.jp/~koujin/jpeg/RGB2YCbCr.html

Ich habe gegoogled, aber mich interessieren nur D und E Seiten, Japanisch kann ich nicht

Dann stimmten ja die Werte von mir einigermassen.

rapso

du mußt nur algebra können.

an sich ist das ne 3*3 matrix und wenn du das invertieren möchtest kannst du die matrix invertieren, aber die seite gibt ja die lösung schon vor.

rapso->greets();