Komprimieren, Packen, aus 4 mach 2 Byte??

rapso

CMatt schrieb:

- Speicher nur die jeweiligen änderungswerte vom vorigen pixel

*hehe* diese diefinition klingt sehr lau, weil es eigentlich die definition von videokompressionen ist.

äquivalent könnte man für bilder sagen: lass die unnötigen daten für die pixel weg und speicher nur das notwendige

und naja, im QCIF wären das noch 3KByte wenn man pro pixel 1bit als änderungsdaten speichert und das ließe sich dann auch noch schlecht komprimieren weil es zumeißt rauschdaten wären.

rapso->greeets();

CMatt

*hehe* diese diefinition klingt sehr lau, weil es eigentlich die definition von videokompressionen ist.

äquivalent könnte man für bilder sagen: lass die unnötigen daten für die pixel weg und speicher nur das notwendige

o_O
mit weg lassen hat das nichts zu tun. Die Methoden in der liste sind alle verlustfrei (bis auf die RGB-YUV unwandlung).
Der sinn von dem ist einfach: wenn ich nur die änderung speichere (zb: Y werte: 100,105,106,100 -> 100,5,6,-6), reduziere ich die anzahl der benötigen bits zum dastellen eines werte, was beteutet ich kann den RLE algo darauf trimmen und somit platz sparen.
bsp:
2bit count 8 bit data <- wird beim ersten wert zum einsatz kommen
2bit count 4 bit dara <- wird bei sehr vielen (nicht 1.) wert werten zum einsatz kommen (2 bits gespart)
4bit count 4 bit data <- kommt kleinen werten mit haufigem auftretem dran, gleiche länge wie 1. kann aber 14 sequenzielle werte mehr darstellen

aber wie schon geschagt.. ich bevorzuge immer noch ein schönes, schon fertiges codec SDK

rapso

CMatt schrieb:

o_O
mit weg lassen hat das nichts zu tun. Die Methoden in der liste sind alle verlustfrei (bis auf die RGB-YUV unwandlung).

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

CMatt schrieb:

Der sinn von dem ist einfach: wenn ich nur die änderung speichere (zb: Y werte: 100,105,106,100 -> 100,5,6,-6), reduziere ich die anzahl der benötigen bits zum dastellen eines werte, was beteutet ich kann den RLE algo darauf trimmen und somit platz sparen.

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.

CMatt schrieb:

2bit count 8 bit data <- wird beim ersten wert zum einsatz kommen
2bit count 4 bit dara <- wird bei sehr vielen (nicht 1.) wert werten zum einsatz kommen (2 bits gespart)
4bit count 4 bit data <- kommt kleinen werten mit haufigem auftretem dran, gleiche länge wie 1. kann aber 14 sequenzielle werte mehr darstellen

das problem von deinen ideen ist, dass er auf ca 0.6bit/pixel kommen muss. das ist nicht so einfach wenn man nur pixel für sich betrachtet.

CMatt schrieb:

aber wie schon geschagt.. ich bevorzuge immer noch ein schönes, schon fertiges codec SDK

man kann sehr vieles fertig nehmen, aber wieso dann nen fertigen codec und nicht gleich eines der unzähligen fertigen video-chat tools;)?

rapso->greets();

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();