RLE lahtipakkimise algoritm koos Huffman'i (?) tabeliga ?

[felch]

Pulgestun Siemens S65 LCDle asmis libi kirjutamisega. Jooned jms sain tehtud, teksti ka mingil määral. Aga on kange soov kasutada juba siin algselt AVRi libis toodud fontide impordi konverterit. Paraku kasutab autor RLE pakkimist koos miski (enamasti 3 baidise) tabeliga. Mainitakse midagi mini-Huffmani algoritmist. Netis järgi vaadates on asi pagana keeruline ja nagu poleks sellist tabelit kasutusel. Kas keegi on asjaga lähemalt kursis või ehk oskab AVRi assembleri koodist lugeda, kuidas asi lahendet?
Zip-failis on fail nimega glcd_intfont.asm ja seal alates märgendist glcdDrawChar20 hakataksegi fondi daatat konvertima. Paraku pole mnemoonika mulle niisama peale vaadates mõistetav et ise flowcharti joonistada

See fondikonverter on liiga ilus, et teda mitte kasutada.
Tähh!
/Felch

[raivo]

Vs: RLE lahtipakkimise algoritm koos Huffman'i (?) tabeliga ?

mu mälu järgi ei ole RLE-l Huffmanniga küll miskit pistmist. RLE peaks see kõige primitiivsem samade järjestikuste sümbolite pakkija olema.
mõned lingid:
http://www.arturocampos.com/ac_rle.html
http://www.geocities.com/m99datacomp...s/rle/rle.html
kõik vähegi "arukamad" pakkijad tahavad look up tabelite jaoks kõvasti RAMi , >32KB, mida ei PICis ei AVRis ole. tegelt see nõutav RAMi maht sõltub maksimaalsest elementide arvust tabelis , aga kui valid selle liiga väikese siis saab tabel kohe täis ja võitu kompresseerimisest ei tule.

ps. aga seal on ju fondid .h failidena olemas.
neid pole mingi kunst asmi .inc failideks ümber teha.
siis pole RLEga vaja vaeva näha .

[andreie]

Vs: RLE lahtipakkimise algoritm koos Huffman'i (?) tabeliga ?

Mõningase nuputamise järel tundub, et asi käib nii:

count = RLE_Table[read 2 bits]
color_index = read N bits              /* N=2 in sample file "nums.h". */
loop count times:
    putpixel color_index

Bitte loetakse baidis paremalt vasakule. Faili struktuur on lahti seletatud päisefailis (näiteks nums.h).

P.S. Huffmani kodeering on tõesti kasutusel. Nimelt on Huffmani kodeeringu väljundiks optimeeritud lookup-tabelid.

[felch]

Vs: RLE lahtipakkimise algoritm koos Huffman'i (?) tabeliga ?

Mitte et ma oleks sellest lõpuni aru saanud kuid uurin uuesti. Aga tõepoolest - enamik näidisfontidest on tõesti pakkimatta ja mulle kasutatavad.
Arturo jm seletajad ei maini midagi tolle RLE_table otstarve kohta.
Fondi struktuur on muidugi huvitav. Oma väljamõeldu sisaldas samuti charwidth'i kuid see number oli iga sümboli daata alguses.
Saan aru nii, et fondi data piceli väärtuse 1 puhul tehakse PutPixel Foreground värviga ning 0 puhul BackGround värviga.
Pixelite eneste kujutamine jäi segaseks. 8*8 fondi puhul on arusaadav aga kui võtta 12*12? Ei mätci nagu...pusin edasi. Pakitud fondi puhul...sinnamaani on aega...
Tänks kaasa mõtlemast!

[andreie]

Vs: RLE lahtipakkimise algoritm koos Huffman'i (?) tabeliga ?

Värvitabel on failis "Font.ini".

Pakkimisalgoritm erinevus standardsest RLE-st piirdub ainult RLE_Table kasutamisega.

[raivo]

Vs: RLE lahtipakkimise algoritm koos Huffman'i (?) tabeliga ?

natuke offtop aga neid fontcreatoreid jms leidub netis üsnagi palju. piiratud resoga ( 5x7 ....15x10) fonte tasub valmiskujul otsida. suurema resoga fontide jaoks kasuta ttf2pcx programmi, teeb windooza fontidest pcx-i. lõpptlemuse saab pcx2inc programmiga. ainus puudus on et mälu raiskab. aga kui süsteemis on mälukaart või väline flashmälu, ei oma see rolli.

[felch]

Vs: RLE lahtipakkimise algoritm koos Huffman'i (?) tabeliga ?

OK aga mismoodi RLE_tabelit kasutatakse? Sellest ei saa kuidagi aru...loll nagu ma olen. Pakkimata fondid on juba implementeeritud (oh mis lahe sõna ).

[andreie]

Vs: RLE lahtipakkimise algoritm koos Huffman'i (?) tabeliga ?

Keeles "C" tähistavad kantsulud massiivi (tabeli) indekseerimist. Indekseerimine algab nullist. Näiteks massiiv[2] tähendab massiivi kolmanda liikme kasutamist.

Püüan selgitada, nagu assembleris programmeerija, vaatepunktist.

Tuleb kasutada RLE dekodeerimise algoritmi parameetritega 2 bitti korduste arvu, N bitti värvi. Lisaks on väike muudatus: failist loetud pikkuse ei lähe mitte tsükliregistrisse, vaid indeksregistrisse. Tsükliregistrisse salvestada indeksregistri abil RLE_Table'st loetud väärtus.

RLE pakkimine on väga lihtne: iga piksliga koos on salvestatud korduste arv. Failist loetud "4,Roheline" tähendab nelja järjestikuse piksli roheliseks värvimist.

[raivo]

Vs: RLE lahtipakkimise algoritm koos Huffman'i (?) tabeliga ?

et täpselt aru saad, võta lahti nums.h fail ja font editoris sama font.
font editor salvestab piksleid ülalt alla tulpadena.
loed andmeid "0" kohta ( rida 5 massiivist ):
0x13,0x37,0x03 jne.
baite tuleb lugeda nooremast niblast, seega jada : 3,1,7,3,3,0 jne
desifreerime bittidena 3 (dec) = 0011
2 vanemat annab värvi "0" , 2 nooremat = 3 , nüüd vaatame tabelist ( rida 3 massiivis) et sellele vastab nr 7.
see tähendab kokku et vaja värv "0" panna järjest 7 pikslisse.
järgmised nr-d :
- 1 desifreerimise tulemus : värv 0 2 pikslisse
- 7 värv 1 7pikslisse,
- 3 värv 0 7 pikslisse,
- 3 värv 0 7 pikslit
- 0 värv 0 1 pikslit
jne.
tulba ülekande signaali pole, seda pead ise järgima.

[felch]

Vs: RLE lahtipakkimise algoritm koos Huffman'i (?) tabeliga ?

Tänud selgituste eest!