> I dlatego dostałeś już radę, żeby użyć naprostszej kompresji:
> http://www.binaryessence.com/dct/en000057.htm
>
> Chmura, czy słońce z jednolitym tłem powinny się ładnie kompresować.

Właśnie ukończyłem obsługę GLCD 480x272.
Wnioski mam takie:
1) Użyłem 32 bitowego procesora z pamięcią 0,5MB i 128kB RAM
2) Wyświetlałem 3 rodzaje grafiki:
a) 480x272 24 bity na pixel
b) 240x136 24 bpp
c) 240x136 1 bpp monochromatyczna i tylko czarno-biała.

Najbardziej czasochłonne okazało się wyświetlanie grafiki monochromatycznej,
ale obraz zajmował najmniej miejsca. W jednym słowie 32-bitowym są 32
pixele.

Kolory 24bpp kodowałem tak, że w trzech słowach 32-bitowych mam 4 pixele.
Podczas wyświetlania mogę nawet coś jeszcze wcisnąć w NOPy.

Przy wyswietlaniu 1 bpp nie moge nic już wcisnąć, bo wyłuskanie bitu, jego
przesunięcie i odpowiednie wystawienie 24 bitów na dwóch portach zajmuje
czas na max.

Piszę w asm.
Linia trwa od 40 do 80 us

Gdybym zastosował kompresję 1 Bit RLE czas byłby silnie uzależniony od
zawartości.
Niektóre grafiki są specjalnie tak kodowane, aby "1" i "0" były w miarę
równomiernie rozłożone.
W związku z powyższym długości trwania poszczególnych linii dość znacznie by
się różniły
w ramach jednego obrazu.
Nie sądzę, że byłby to duży problem, ale nie sprawdzałem w praktyce.
Myślałem o tym kodowaniu, ale właśnie miałem wyświetlać kody QR, gdzie ta
metoda kompresji nic nie da, a one akurat dużo pamięci nie zabierały.
Dekodowanie to kilka instrukcji tcy=12,5 ns więcej na pixel.


--
-- .
pozdrawiam
Sylwester Łazar
http://www.alpro.pl Systemy elektroniczne.
http://www.rimu.pl -oprogramowanie do edycji schematów
i projektowania PCB.