GLCD'lerde RLE kodlama ile resim sıkıştırma

[picusta]

Forumda okudugum kadarı ile PIC'lerle GLCD uygulama yapılırken sorun hafızaya az resim yüklenmesi imis.
Benim aklima neden bu resmi sıkıştırmıyoruz, oldugu gibi bitmap seklinde PIC'in hafizasina yüklüyoruz sorusu geldi.
Resim sıkıştırmadaki en basit algoritmayı kullanabiliriz:
Run Lenght Encoding algoritması veya karsılıgı :"Dizi uzunlugu kodlaması".
Mantıgı basit : Ne zaman birbirini izleyen ayni degerde bilgi varsa onu <deger>,<dizi uzunlugu> seklinde kodluyoruz.
GLCD'de 1(karanlik) veya 0 degerleri olduguna göre bu 1 bit bilgiye esdeger.  
Byte 'in geri kalan bitlerini (7 bit) uzunluk bilgisi için kullanabiliriz. örnegin birbirini izleyen 70 siyah nokta varsa : <1>, <70>  
70'i ikili sistemde ifade edersek, byte'imiz : 1 1000101  oluyor.
Bu demektir ki bir byte'a 70 pixelin bilgisi saklaniyor, eger kodlamasaydik, 70/8 = 8,75 byte'a ihtiyaç duyardik. 8 misli sıkıştırmış olduk böylece!!

8 bit üzerinden kodlama ile dizi uzunlugu 128'e kadar çikabilir(bu durumda sıkıştırma oranı 1/16 !!! ) Diger taraftan, dizi kisa olur ise (8 pixelden kısa) kodlama sıkıştırma yapmıyor aksine büyütüyor.
Ayni mantikla 4 bitlik kodlama seçebiliriz, 4 pixelden uzun diziler sıkıştırılır.
Kisaca resimde görünen dizi uzunluklarinin olasiligina göre en uygun kodlama seçilmeli. 8 bitlik, 4bitlik RLE veya sıkıştırmasız en uygun olabilir, resime göre degisir.
önerecegim format (PIC'in FLASH'ina yazilacak olan). söyle olabilir mesela:
Her resime o resmin kodlamasini isaret eden bir deger atanir. Bir resim için en az boyut ile kodlama seçilmeli (amaç bu).
Bu deger sunlar olabilir:

1 : Resim sıkıştırılmamış, normal bitmap olarak okumak gerekir.

2 : Resim 8bitlik (1deger+7uzunluk biti) RLE olarak kodlanmis, bu yöntemle çözmek gerekir.

3 :  Resim 4bitlik (1deger+3uzunluk biti) RLE olarak kodlanmis, bu yöntemle çözmek gerekir.

4:  Resimin her satiri ayri ayri kodlanmis. Bu durumda her satir için sıkıştırılmamış, 8bitlik veya 4 bitlik RLE bilgileri gerekir. Bunlari da 2 bit halinde kodlayabiliriz.

4. durum bence en çok kullanilacak olan, çogu resimi en az boyut kaplayacak sekilde kodlanmasini saglayabilir.

Her satir için 2 bit kafadan gidecek. 64 satirli LCD'de 128 bit oluyor (2*64). ama diger taraftan her satir için en uygun kodlamaya sahip olacagiz, tıpkı MPEG-4'lerdeki (DiVx) degisken sıkıştırma oranı gibi birsey ve böylece oradan bit kazanacagiz.

Yapmak istedigim ufak bir GLCDtool. Resimi uygun sekilde bitmap olarak alip o resim için sıkıştırmaları yapmak, degisik sıkıştırma yöntemlerinin oranlarını karsılastıracak ve en uygununu seçecek. Sonra elde ettigimiz dosyayi PIC'e atabilecegiz.
PIC tarafinda ufak bir kod çözüye ihtiyaç olacak, sıkıştırılmış veriyi çözüp GLCD'ye bitmap olarak göndermeli (bu kısım kolay).

Sonuçta elde edecegimiz sey PIC FLASH'inda büyük bir yer kazancı.
En kötü ihtimal hiç sıkıştırılmamış resim olacak (olabilecek tek durum :  bir siyah, bir beyaz, bir siyah, bir beyaz...... pixel).

Acaba PC programlama ile arasi iyi olan birisi bu projede bana yardim edebilir mi? Benim compiler Borland 97 ve çalistirmadigim epey oluyor.
Ben PIC tarafindaki kod çözücü kismi hallederim.
Amaç projeyi burda yayinlamak böylece Picproje yapimi GLCD tool olur, üstelik digerlerinin aksine veriyi daha "akilli" bir sekilde depolayarak (birçok seçenek arasında en iyi sıkıştırma yöntemini seçecek) FLASH'ta yer kazanci saglayacak.

Bu yöntemin daha önce GLCD'lerde uygulanip uygulanmadigini bilmiyorum. Onun için her türlü yorumunuzu bekliyorum.

[Logan]

Merhaba @picusta,
320x240 grafik lcd kullandığım için bu yer problemi ile başım ciddi biçimde dertte.Hatta bi aralar eprom yerine MMC kart kullanmayı bile düşünmüştüm.Bahsettiğin kodlama mantığı, sağlam temeller üzerine oturtulursa gayet sağlıklı çalışır. PC programı konusunda çok iyi değilim fakat mutlaka yardımcı olabileceğim bir konu olacaktır.

[bleach]

Selam
Bahsettiğiniz konu ilginç ve doğru olmakla birlikte bazı eksikler içermekte sanırım. Öncelikle sadece mono grafik ekran düşünmüşsünüzi renklilerde aslında durum daha da vahim. Birde kodlanmış görüntünün açılması sırasında kullanılacak işlemci gücü ve zaman kısıtı var. Yani işlemci işi gücü bırakıp görüntüyü açıp ekrana mı verecek?

Bende son 1-2 haftadır eskiden 18f452 ile kullandığım PCF8833 (7110LCDsi) ile dsPIC30F6014 ikilisi üzerinde kütüphane geliştiriyordum. Malum mimari 16bit olunca kodlarda epey bir değişiyor. Artık o kadar sıkıldım ki bundan sonra sadece bir DSC (DigitalSignalController)yi grafik kartı olarak kullanmaya karar verdim. Çünkü çok zaman alan işlemler.

Grafik kartı olarak kullanılacak dsc'nin mesela 3-5 katman görüntü işleme kabiliyeti olsa, sıkıştırılmış görüntü açma özelliği olsa, hatta basit seviyede 2-3 boyutlu görüntü işleme kabiliyeti olsa...

Böylece sizin düşündüğünüzden 1 adım ileri gidip, daha karışık görüntü sıkıştırma teknikleri eklenebilir. Mi acaba?

Saygılar

[picusta]

Öncelikle sadece mono grafik ekran düşünmüşsünüzi renklilerde aslında durum daha da vahim

Aslinda bu yöntem renklilerde daha iyi sonuç verebilir, siyah ve beyaz ile sinirli değil.
Yaptigimiz kodlama <deger>,<dizi uzunlugu> seklinde, biz siyah beyaz durumunda <deger> bilgisini 1 bit uzunlugunda seçtik (siyah, beyaz).
Renkli LCD'lerde bu deger 8 bit, 12 bit, 16 bit, 24bit veya istediginiz uzunluk olabilir.
Aslinda Monochrome GLCD'de gri tonlari yapmayi düsünüyordum, örnegin 4 gri tonu olabilir (<deger> bu sefer 2 bit uzunlugunda). Gri tonlarini ekranda çikartmak için PWM mantigina benzer bir yaklasim seçebiliriz (hesap makineleri böyle yapiyor (TI-89)).

Birde kodlanmış görüntünün açılması sırasında kullanılacak işlemci gücü ve zaman kısıtı var

Bunun için endiselenmiyorum. çünkü birçok LCD ile iletisim için birçok bekleme komutu gerekiyor bu yüzden zaman yeterli diye düsünüyorum. Zaten çözecegimiz "kod" çok karmasik bir algoritma gerektirmiyor, 3-5 ASM komutu ile çözülebilmesi gerekir. Normalde nasil LCD'ye veri gönderiliyorsa ayni kod olacak, sadece 3-5 asm kodu fazladan olacak. Kodu interrupt seklinde yazmak'ta bir fikir.
Logan, o zaman PIC tarafini yazmaya baslayabiliriz, kabaca yazayim,
resimin asagida verdigim format ile oldugunu varsayarsak:

void GLCDye_data_gonder (void) {
uchar baslik;
uchar FLASHTAN_okunan_veri;
uchar GLCDye_ham_veri;

baslik = FLASHTAN_resim_verisini_oku()

swithc (baslik) {

case SIKISTIRILMAMIS_RESIM:
      while (RESIM_SONU)
              GLCDye_veri_gönder (FLASHTAN_resim_verisini_oku());
break;


case 8bitRLE_SIKISTIRILMIS_RESIM:
       while(!RESIM_SON) {
            
           FLASHTAN_okunan_veri = FLASHTAN_resim_verisini_oku();    //RLE olarak <deger> ve uzunluk bilgilerini aliyoruz
           deger =  FLASHTAN_okunan_veri & DEGER_MASKESI;
           uzunluk = FLASHTAN_okunan_veri & UZUNLUK_MASKESI;
                      
           for (uzunluk){    //GLCD'ye gönderilecek bilgi hazirlaniyor, degerleri birlestirip byte olarak gönderilmesi gerekir, böyle olmamali. 
           GLCDye_veri_gönder (deger); 
            
                      
           Satir_bilgilerini_güncelle(); //simdiye kadar kaç pixel yazdik, Satir bitti mi, resim bitti mi, karar verilecek burda.
                      

       } 
break;



case 4bitRLE_SIKISTIRILMIS_RESIM:
            
           // Yukaridaki kodun neredeyse aynisi, fakat FLASH'tan okunani 8 bitlik veriyi 2 tane 4 bitlik bilgi olarak yorumlamak gerekir.

break;


case Karisik_kodlama:

       for (HER_SATIR) { // Her satir için ayri kodlama var, her satir için hangi kodlama kullanilmis ona bakip çözmek gerekir.
             
             kodlama_turu = Satir_kodlama_turu_oku(); //FLASHTAN satira ait 2 bitlik veri okunur.
             switch (kodlama_turu)

                  case SIKISTIRILMAMIS_SATIR:
                            // Yukaridaki ayni durumdaki resim için yazilan ayni kod 

                  case 8bitRLE_SIKISTIRILMIS_RESIM:              
                            // Yukaridaki ayni durumdaki resim için yazilan ayni kod 

                  case 4bitRLE_SIKISTIRILMIS_RESIM:              
                            // Yukaridaki ayni durumdaki resim için yazilan ayni kod 
                           
      } 
break;

}

}

Bunun gibi bir kod olabilir. burda sadece iskelet verdim, bazi döngüler tam değil, gelistirmek lazim. Kodlamanin temel mantigini umarim anlamissinizdir.
PC programi olsa simdiden belli test resimleri sıkıştırabiliriz ve hangi resimde hangi oranda yer kazanacagimizi kestirebiliriz.

[picusta]

Tekrardan merhaba,
örnek bir resim için  sıkıştırma işlemini yaptim:

Resim 128*64 :


Böyle bir resmi hafizada tutmak için normalde 128*64 bit gerekir, 8192 bit = 1kBayt
ilk dört satır için sıkıştırılmamış veriler (bitmap) bunu veriyor :

FF FF FF FF FF FF 00 3F FF FF FF FF FF FF FF FF
FF FF FF FF FF F0 FF C3 FF FF FF FF FF FF FF FF
FF FF FF FF FF 8F FF FF D8 FF FF FF FF FF FF FF
FF FF FF FF FE FF FF FF FB FF FF FF FF FF FF FF

===> 512 bit
Simdi bir de sıkıştırılmış deneyelim:

8bit RLE kodlama

B0 0A C6
AC 04 8A 04 C2
A8 03 93 03 B8
A7 01 99 01 B7

===>> 144 bit

ikisinin arasindaki oran:  512 / 144 = 3,555
bu resimi hafizada tutmak için 1024 bayt değil ,  288 bayt gerekli sadece.

Amaç :
Projenin amaci uygulamalarda GLCD resimlerinin tutugu yeri azaltmak, böylece ayni ROM kapasitesi ile daha fazla resim saklanabilir veya ayni miktar resimi daha düsük ROM'da saklanabilir.
Dolayli olarak: GLCD uygulamalarinin kalitesi artar (daha çok resim) ayni zamanda (yurtdisindaki) entegre üreticilerine daha az para gider gibi sonuçlar çikartabiliriz.
Bu projeyi Open-Source olarak yürütmek istiyorum. Bu demektir ki kod yazmak isteyen katilimcilar hosgelmistir hatta onlarsiz bu bu proje yürümez:
Fakat karsilik beklememelidirler, projeye bagis yapilabilir tabii.
Yazilan bütün kodlar (PC ve PIC) açik olarak, herkesin erisebilecegi bir sekilde yayinlanacaktir.
Programlama zorlugu univ. 1. sinif seviyesindedir (MYO'lar tabii kat kat iyisini yaparlar).  (dosya okuma, yazma, döngü, ve kullanici arayüzü programlama bilgisi gerekli)

En aktif katilimcilara ENC28J60, DSPIC33F128MC708 veya PIC18F2550 (her yerde kolay kolay bulunmayan) entegrelerinden birini yollarim.

_______________________

Uzun vadedeki amaci :
kodlama teknigini renkli ekranlar için de uygulamak. Asil hedef ise, animasyon'lara da sıkıştırma yapmak, böylece eskiden 2 resim konan yere 100 animasyon karesi sıkıştırmak.

Daha fazla yorum ve katilim dilegi ile.

[YARGICH]

@picusta
 
Gecenin 5'inde yazılım yazarken yoruldum bi picprojeye bakayım dedim. Yarına yetiştirmem gereken bir iş olmasına rağmen, bu iş için bir PC program yazayımda kafam dağılsın dedim. Sanki farklı bir şey yapıyormuşum gibi

Bu program ile en azından hangi resimin ne kadar yer kaplayacağı öğrenilebilir.

Ben yazılımı yazdıktan sonra yeni bir mesaj eklemişsiniz. Sizin gülen yüz resmi için hesapladığınız 288 byte benim yazılımda 330 byte çıktı. Sizin resmi hesaplamadım ama benim yazılımdaki birkaç basit resimde doğru sonuç verdiğini gördüm.

Hocam yazdığım yazılımın açık kodu, kapalı kodu, resimleri ıvır zıvır ne varsa zipledim buraya ekledim.

Birkaç örnek ben yaptım. Sıkıştırma mantığına göre en fazla 8192 Byte yer kaplıyor, en az ise 64 Byte yer kaplıyor. Bence sıkıştırmak her zaman için mantıklı. Bu zamanda kadar BMP si JPG den büyük olan bir resim daha görmedim. Ama bilmiyorum yinede iyi analiz etmekte fayda var.

Herkese iyi çalışmalar.


Piksel diziliminden dolayı karışık bir resim




Yarısı dolu olan ve piksel dağılımı olarak basit bir resim




Piksel diziliminden dolayı en çok yer kaplayan resim




Piksel diziliminden en az yer kaplayan resim




Her iyinin içinde bir kötülük, her kötünün içinde bir iyilik




Bu da gülen yüz. Yalnız hocam sizin 288 byte hesapladığınız resim bende 330 byte çıktı.

[Analyzer]

Selam,

Vaktim olsa isteyerek ilgileneceğim bir konu. RLE yerine LZW tavsiye edeyim o zaman.Implement etmek aslında hiç zor değil :

http://www.data-compression.com/lempelziv.html

Analyzer

[picusta]

Ellerine Saglik YARGICH, çok sahane olmuş. Ilk adimi attin, isin büyük kismini yaptin. Kullanici arayüzü + 8bit RLE kodlamasi.

Sizin gülen yüz resmi için hesapladığınız 288 byte benim yazılımda 330 byte çıktı.

Sadece ilk 4 satirdaki sıkıştırma oranına bakarak bütün resim için tahminde bulundum (oranladım) tabii ki dogru sonuç resmin tümü kodlandiginda çıkan sonuç.

Birkaç örnek ben yaptım. Sıkıştırma mantığına göre en fazla 8192 Byte yer kaplıyor, en az ise 64 Byte yer kaplıyor.

Bu versyonda sadece 8bit RLE kodlamasi yapilmis.
Basta düsündügüm formatta ise, bastaki 1 bayti header olarak tanimlamak. böylece hangi sıkıştırma yöntemi kullanildigi bulunacak.
Header Bayt degerine göre sıkıştırmamış, RLE8, RLE4, karisik(satir temelli kodlama), LZW veya 256 yöntemden biri seçilebilir. Her resim için "en uygun" sıkıştırma yöntemini kullanacagiz tabii.
RLE 8bit'e kodlanmis resim 8192 Bayt ise ve sıkıştırılmamış resim 1024 bayt eder ise, o zaman header'a 1 degerini koyacagiz ve FLASH'a resmi bitmap olarak kaydecegiz.
Header sayesinde Analyzer'in dedigi gibi baska sıkıştırma yöntemleri de kullanabilecegiz. Anlayacaginiz FLASH'a kaydedilmis resimlerin hepsi ayni yöntemle sıkıştırılmamış olacak, header buna karar verecek (PC programi en uygun yöntemi seçecek.)

Vaktim olsa isteyerek ilgileneceğim bir konu

Open-Source'un amaci da bu, herkes bir kismini gelistirse (örnegin bir sıkıştırma yöntemini yazmak 1-2 saat alabilir) sonunda damlaya damlaya göl olacak. Bunun yaninda yazilimi koordine bir sekilde insaa etmek de sart tabii.
Kazanacak olan tabii ki yazilimi kullananlar olacak (GLCD'leri uygulamalarina katanlar), yazilimi gelistirenler için ise bir tecrübe (hele ögrenciler için önemli bence).

Projeyi mümkün olabildigince genis ve modüler tutmaya çalisabiliriz. Birçok kodlama yöntemi deneyebiliriz (header'imiz 1 bayt oldugu için 256 yöntem deneyebiliriz.), ne kadar çok kodlama yöntemi olursa ROM'da o kadar az yer kaplayan bir resmimiz olma ihtimali var.
Bir de zannedersem GLCD'nin kontrolcülerine göre dosyaya sekil vermeliyiz.örnegin yanlis hatirlamiyorsam, KS 108 (numarasi tam bu değil) 128*64 resimi 90° döndürülmüs bir sekilde ve iki tane 64*64 parça olarak sakliyor.
Yazilim birçok GLCD kontrolcüsünü ve çözünürlügü desteklemeli bence. Bunu için PIC için bir include dosyasi olusturabiliriz. (GLCD_EN, GLCD_UZUNLUK gibi degerleri tanimlamak için, daha sonra PIC kod çözücü programinin kullanacagi degerler.)

Bu yazilim gelistirme projesini SourceForge'da nasil host edebiliriz? Sitenin sundugu CVS tarzi hizmetlerden yararlanmak fena olmaz.
Bu versyonu 0.9 Beta olarak adlandirabilirmiyiz?
Bu versyona yapilmasi gereken eklentiler sirasi ile bence :
1. RLE8 ve sıkıştırılmamış boyutlari karsilastirmak ve çikis dosyasina header bilgisini koymak (en az yer kaplayan seçilecek).
2. 128*64 ekranlarin kontrolcülerine göre verilerin düzenini degistirmek (ikiye bölmek, 90 derece döndürmek gibi seyler)
3. Diger sıkıştırma yöntemlerini de koymak : RLE4, satir temelli kodlama (anlaşılmayan yer varsa daha açabilirim ), veya baska üyerlerin önerdigi yöntemler LZW gibi.

PC tarafinda bu kadar gelisme varken PIC tarafinin bos durmamasi gerekir.
Kisaca PIC programi söyle olacak : header bilgisini okuyacak, ona göre hangi çözme algoritmasina dallanacagi belli olacak.
Verileri çözüp GLCD'ye yollacak.
Header okuyup, 8bit RLE çözen ve GLCD'ye gönderen bir program yazarak ise baslayabiliriz. Böylece PC tarafina yetismis oluruz ve ilk "kodlama-kod" çözme isini basarabiliriz.

Herkese iyi günler dilerim.

[picusta]

Source forge sitesine baktim, yeni bir proje baslamak için 15 karakterlik proje ismi istiyorlar. Ne olsun? picprojeglcd?
Birileri projeyi inceleyip sonra onay veriliyormus (2 is günü sürebilirmis).
Ne dersiniz? yazilimi oraya koyalim mi?

[YARGICH]

->PicUsta ZIPP v0.9 BETA ÇIKTI !!!


PicUsta ZIPP v0.9 Beta da neler YENİ !
- GLCD seçmek için yeni bir combobox eklendi.
- Sıkıştırma yöntemi için veya standart BitMap seçmek için ikinci bir combobox eklendi.
- Türkçe/İngilizce seçeneği eklendi.
- ZIPP metodunden "En iyi ZIPP" seçilirse program bütün yöntemlerde deneyerek analiz ediyor ve sol tarafta bulduğu sonuçları yazarak hangisinin daha az yer kapladığına karar veriyor ve sağ taraftaki listboxta Header ekleyerek sıkıştırılmış yeni resim bilgilerini veriyor.

PicUsta ZIPP v0.9 Beta da neler DEMO !
- RLE4 ve LZW metodları şimdilik bu versiyonda hesaplamalara katılmıyor.
- RLE8 metodu sadece KS0108 seçildiğinde hesaplamaya katılmıyor, bir sonraki versiyonda olacak.


@picusta, hocam şimdilik GLCD olarak sadece KS0108 ekledim. Yalnız bu LCD için sadece standart bitmap çevirisi yapıyor. RLE8 metodunu uyarlayamadım. KS0108 de 1 byte yukardan aşağıya ( altda MSB) doğru duruyor. Yani en iyi ihtimalle KS0108 için yukarıdan aşağıya RLE8 metodunu kullanarak yaptırabiliriz. Bunu yazarken aklıma geldi :oops: KS0108 için RLE8 sıkıştırma metodunuda bir sonraki versiyonda eklerim.

Ne dersiniz? yazilimi oraya koyalim mi?

Siz bilirsiniz hocam. Çoğunluk ne derse o olsun. Benim için fark etmez. Madem orayakoyulma ihtimali var birde ingilizce seçeneği olsun istedim.

Bu başlığı takip eden arkadaşlar, programın versiyonlarını indirip test ederlerse sevinirim. Varsa hataları düzeltelim.

İyi Çalışmalar



Bazı denemeler.....

Bu karışık resimde program en iyi ZIPP metodunun BitMap olması gerektiğine karar veriyor ve sonucu header dahil olacak şekilde ona göre düzenliyor.


Bu basit resimde program en iyi ZIPP metodunun RLE8 olması gerektiğine karar veriyor ve sonucu header dahil olacak şekilde ona göre düzenliyor.

[Logan]

@yargıch, çok başarılı bir çalışma olmuş.Ellerine sağlık.Bu PicUsta ZIPP V0.9 BETA programının 240x160-240x128 ve 320x240 pixel grafik lcd ler için kullanılabilecek versiyonlarınıda ekleyebilirsen çok iyi olur.Çalışmalarında başarılar.

[picusta]

@yargıch, çok başarılı bir çalışma olmuş.Ellerine sağlık.Bu PicUsta ZIPP V0.9 BETA programının 240x160-240x128 ve 320x240 pixel grafik lcd ler için kullanılabilecek versiyonlarınıda ekleyebilirsen çok iyi olur.Çalışmalarında başarılar.

Bir de PIC için asagidaki kodlama algoritmasinin tersi yazilsa o zaman tam kodlama-kod çözme çalisiyor mu görecegiz.
Gerçi denemeleri yapmak için PC'nin parallel portuna takilmis GLCD kullanabiliriz.

repeat
repeat
    if image1.Canvas.Pixels[x,y]=clBlack then
    begin
     Byte1:=128;
     repeat
       x:=x+1;
       if image1.Canvas.Pixels[x,y]=clBlack then Byte1:=Byte1+1
       else color:=100;
     until (Byte1>255) or (color>0) or (x>127);
     color:=0;
     Listbox2.Items.Add(inttostr(Byte1));
    end
    else
    begin
     Byte1:=0;
     repeat
       x:=x+1;
       if image1.Canvas.Pixels[x,y]=clwhite then Byte1:=Byte1+1
       else color:=100;
     until (Byte1>127) or (color>0) or (x>127);
     Listbox2.Items.Add(inttostr(Byte1));
     color:=0;
    end;
until (x>127);
x:=0;
y:=y+1;
until (y>63);