Run-length kódolás bit- vagy bájt-szintű megvalósítása hatékonyabb? (bővebben lent)

"miért nem azt használják?"

Azt használják.

"mindegyik karaktert érték szerint felbontjuk bitekre és így hajtjuk végre a kódolást"

Ezt kifejtenéd? Az azonos bitek sorozatára gondolsz?

Szia.

Szerintem ez nem ilyen egyszerű. Pl. a Te példádnál maradva a 1000000 db "b" betű elvileg 4 bájton letárolható lenne (3 bájt kell az 1000000 letárolásához, 1 bájt pediglen kell a "b" betű letárolásához), de ez a módszer szinte semmilyen más esetben nem gazdaságos mivel ha olyan sorozat van ahol csak egymás után más és más bájtok jönnek, akkor a fenti módszerrel egy bájt letárolásához is 4 bájtnyi hely kell.

Ha a bájtokat felbontod bitekre, akkor is valami ilyesmi a helyzet.

Először is meg kell határozni, hogy hány biten tárolod a darabszámot (és ebből következik, hogy a fennmaradó biteken tárolhatod az értéket), és az is látszik, hogy nem nagyon érdemes a darabszámot 7 bitnél nagyobbra venni, mert akkor mindjárt bejön plusz egy bált. Ha ezt pl 4-4-re veszed, akkor egy bájton tudsz tárolni 15 db 15-ös variációt (a 15-ös variációk viszonylag könnyen kiszűrhetőek a bitfolyamból mivel ez még nem olyan nagy). De ha elcsúsztatod a biteket pl. 7-1-re, akkor 128 darab 1-es vagy 0-ás bitet tárolhatsz le 1 bájton.

Tehát sok minden függ a fájltól és annak tartalmától, tehát először analizálni kellene a fájlt és az analizálás eredményétől függően meghatározni a tárolási metódust, de ez pl nagyon sok időd is elvihet (mármint az analizálás), ezért inkább, meghatározzák a tárolási metódust pl (maradnak a 4-4 bitnél (ezt a módszer a 16 szinű pcx képeknél használják) vagy a 7-1 bitnél) és ezt használják, mindenütt. Ennek az a hátránya, hogy nem biztos hogy számottevő lesz a fájl méretcsökkenése a kódolás után.

Sok sikert. Üdv.

Az RLE enkódolás egy nagyon szimpla tömörítési algoritmus, ami azt írja le szekvenciálisan, hogy miből mennyi, azaz hány darab van.

Az enkódolást, azaz a tárolás formátumát meghatározza az enkódolandó adat tartalma. Ha az byte-okból áll, akkor természetesen a byte-os formát érdemes eltárolni, ha bitekből, akkor pedig a bitek számát és milyenségét (nulla vagy egy). Utóbbi lehet például egy két színösszetevőből álló kép. Ennek képpontjai mondjuk feketék és fehérek. Ezekhez a képpontokhoz hozzá lehet rendelni egy-egy bitet, azok szinétől függően.

Byte-os adatot nem érdemes bitszinten kompresszálni.

Egy RLE tömörített file tartalma valami ilyesmi lehet:

A13B3E4

Az első byte az amit tömörítünk, a második pedig ennek darabszáma és így tovább.

Ugyanez kicsomagolt formában:

AAAAAAAAAAAAABBBEEEE

Itt 20 byte (13 db "A", 3 db "B" és 4 db "E") van tömörítve 6 byte-nyi helyre.

Látható, hogy a kompresszió hatásfoka a tartalomtól függ.

Ezért a tömörítésnél érdemes megnézni, hogy mi is a tömörítendő adattartalom, mert ez fogja meghatározni a számláló méretét.

Byte-os tömörítésnél ismert, hogy csak 3 vagy annál több egymás után következő azonos byte-ot érdemes tömöríteni, mert 2 byte helyet foglal egy byte-nyi tömörítetlen adat is.

Hogy a tömörített és a tömörítetlen adat blokkokat meg lehessen egymástól különböztetni, azt úgy lehet a legegyszerűbben elérni, hogy az első helyen van a leíró byte, a másodikon pedig annak darabszáma. A második byte legmagasabb helyiértékű bitjét 1-re állítjuk ha tömörített és nullára, ha tömörítetlen adat következik. Így a számláló alsó 7 bitjét használhatjuk a darabszám leírására. Ez byte esetén értelemszerűen maximum 127 lesz.

Viszont, ha tudjuk, hogy csak 3 darab, vagy ennél több azonos értéket fogunk tömöríteni, akkor a 127 kitolódik 130-ra, mivel a három darabot 0-val, a négyet eggyel, az ötöt kettővel fogjuk leírni.

Kicsomagolásnál pedig a darabszám értékhez hozzáadunk 3-at. Így ha 1 lesz az érték, akkor 4 db azonos byte-ot írunk le, ha 0 akkor pedig csak hármat.