GLCD screen array compression

General discussion on mikroPascal.
Post Reply
Author
Message
janni
Posts: 5373
Joined: 18 Feb 2006 13:17
Contact:

GLCD screen array compression

#1 Post by janni » 12 Mar 2008 16:45

I always regarded the way GLCD screens are stored as a waste of ROM. Working on my own GLCD lib I've decided to somehow compress the array and devised a simple way to do it.

If anyone's interested, here's the procedure used to display such 'packed' screen array on KS107/8 based GLCD:

Code: Select all

procedure GLCD_Image_Packed(const ptrImage: ^byte);
 var page,xpoz,side,count,byt,cb:byte;
 begin
  page:=0; count:=0;
  cb:=ptrImage^;
  inc(ptrImage);
  while page<8 do
   begin
    side:=63;
    while side<65 do
     begin
      GLCD_Set_Side(side);
      GLCD_Set_Page(page);
      GLCD_Set_X(0);
      xpoz:=0;
      while xpoz<64 do
       begin
        if count=0 then
         begin
          byt:=ptrImage^;
          inc(ptrImage);
          if byt=cb then
           begin
            count:=ptrImage^;
            inc(ptrImage);
            if count>0 then
             begin
              byt:=ptrImage^;
              inc(ptrImage);
              dec(count);
             end;
           end;
         end else dec(count);
        GLCD_Write_Data(byt);
        inc(xpoz);
       end;
      inc(side);
     end;
    inc(page);
   end;
 end;{GLCD_Image_Packed}
and a program producing compressed arrays from bitmaps may be found here: http://www.cobir.com/Bitmap2Array.rar. (Resulting array is moved to clipboard so one may paste it directly to one's code.)

The procedure works with standard mE's GLCD library, like

Code: Select all

  Glcd_Init(PORTB, 2, 3, 4, 5, 7, 6, PORTD);
  Glcd_Image_Packed(Screen_bmp_packed);
The compression method is simple. Program finds least used byte value in a bitmap and assings it a special meaning - let's call it a control byte. Next, repetitive values are searched for and coded as cb n byte, where cb denotes the control byte, n is the number of bytes (n>0). Bytes of value equal cb are coded as cb 0. Easy to pack and unpack, but produces much smaller arrays. Hope you'll like it.

xor
Posts: 5465
Joined: 18 May 2005 00:59
Location: NYC
Contact:

#2 Post by xor » 15 Mar 2008 02:01

Great idea. Have you tested the timing difference between direct access to a bitmap in ROM and the decompression process to output. Just wondering.
[color=darkred][b]xor[/b][/color]
[url=http://circuit-ed.com]CircuitED -[/url]

janni
Posts: 5373
Joined: 18 Feb 2006 13:17
Contact:

#3 Post by janni » 15 Mar 2008 02:58

Even with decompression, the timing is better on average thanks to less calls to ROM (checked on the truck bitmap from mE images - the 'packing' leads to 544 bytes array instead of the nominal 1024).

And the procedure can be optimized (did it with assembly inserts) leading to further reduction in execution time.

The method is so efficient with less complicated bitmaps that I stoped drawing lines and circles and use whole screens. Saved several kb of ROM this way not to mention the execution time.

xor
Posts: 5465
Joined: 18 May 2005 00:59
Location: NYC
Contact:

#4 Post by xor » 15 Mar 2008 03:30

Makes perfect sense. Certainly has my interest. Thanks for the info.
[color=darkred][b]xor[/b][/color]
[url=http://circuit-ed.com]CircuitED -[/url]

rainer
Posts: 320
Joined: 07 Dec 2006 11:00
Location: Vienna, Austria
Contact:

#5 Post by rainer » 24 Mar 2008 11:09

Hello, janni!

I just tested your little program Bitmap2Array.exe with a 128x64 bmp. It is really astonishing what it sais, not to say unbelievable.

I used a bmp with a picture converted from color into b&w. All shades of gray are therefore randomly spread pixels in it. If I store it "normal", your program says 1024 bytes, while it says 16 bytes when I choose "packed array". So I took another picture. And - I wonder - I get again exactly 16 Bytes, due to a totally different content? Something is not working correctly, I guess. 8)

Because I could not find any option in your program for writing the generated array to a file, I am actually not able to verify if it is working. If it really compresses data such heavily, it is really a great idea, but you mentioned an ~50% compression at the truck picture, which is almost the same to my photo. But I would like to verify that.

Do you perhaps have an extended version which can write or at least display the generated pascal source, please?

rainer

janni
Posts: 5373
Joined: 18 Feb 2006 13:17
Contact:

#6 Post by janni » 24 Mar 2008 13:41

Yes, that would be too good to be true. The conversion program moves the resulting Pascal array to clipboard. You may paste it (using Ctrl-V, for example) into any text file.

------ Added

16 bytes is the size of packed 'empty' (filled with identical bytes) bitmap. Your bitmaps are apparently treated as such. Are they displayed properly by my program on screen?
All shades of gray are therefore randomly spread pixels in it.
The conversion program works only with B&W pictures, coding white pixels as 0s, all the rest as 1s. (I've checked it only with bitmaps produced by Paint, though.)

janni
Posts: 5373
Joined: 18 Feb 2006 13:17
Contact:

#7 Post by janni » 25 Mar 2008 18:01

I've added an option to save the array to a text file. New version is available at the same address (see first post).

It probably will not solve Rainer's problem, as he uses Windows emulator under Linux, but maybe somebody also will need this option.

Post Reply

Return to “mikroPascal General”