Wysłany: 07 Lip 2005 00:33 Jak są zapisane bitmapy we flashu? Wszystkie DCT-3
Witam
Opiszę krótko jak są zapisane bitmapy w MCU, może ktoś będzie chciał napisać program, wiem... ktoś teraz spyta po co pisać program do odczytu grafik skoro jest ich "osiemnaście" albo i więcej i po co to w ogóle opisywać?
Ja tak czy owak to opiszę bo może ktoś jest ciekaw a nie wie jak są zapisane bitmapy we flashu.
Najpierw jak to wygląda we wszystkich DCT-3 oprócz 3410, 6210, 6250, 7110.
Sposób zapisu jest bardzo prosty, jak wiadomo 1 Bajt to 8 bitów więc można powiedzieć że 1 Bajt to 8 pikseli.
W załaczniku widać jak to mniej więcej wygląda, czerwoną ramką zaznaczyłem poszczególne Bajty. Bitów jest w tym przypadku 7 ponieważ grafika jest 7x16.
Bit najmłodszy jest na górze, bit najstarszy na dole.
Jeśli grafika była by większych rozmiarów (np. 84x48) to bajt 49 przejdzie do nowej linii i będzie pod bajtem 1. Przy odczycie ważne jest żeby zachować prawidłową szerokość bo inaczej grafika będzie przesunięta co 8 pikseli.
Dane tej bitmapy z załącznika jak widać mają długość 16 Bajtów i wyglądają tak:
00 3E 3E 0A 00 3C 3E 12 3C 00 36 3E 08 36 00 00
To teraz opiszę mniej więcej jak to wygląda w 3410, 6210, 6250, 7110
Wygląda to trochę inaczej, dla porównania dane grafiki z załącznika wyglądają tak:
12 00 3E 11 0A 00 11 3C 3E 11 12 3C 11 00 36 11 3E 08 12 36 00
Na tym akurat przykładzie bajtów jest o 5 więcej niż w normalnym zapisie ale chcę powiedzieć że przy dużych grafikach gdzie jest dużo bajtów tej samej wartości obok siebie to w efekcie bajtów będzie mniej niż w normalnym zapisie.
Teraz objaśnienie:
12003E110A00113C3E11123C110036113E08123600
ABCCDDABCCDDABCCDDABCCDDABCCDDABCCDDABCCDD
A - ilość linii CC, linia to 8 pikseli w pionie tak samo ustawionych jak w normalnym zapisie
B - ilość lini DD, linia to 8 pikseli w pionie tak samo ustawionych jak w normalnym zapisie
CC - wartość linii - 8 bitów/pikseli w pionie, ilość tych linii podana w A DD - wartość linii - 8 bitów/pikseli w pionie, ilość tych linii podana w B
Czyli pierwsze wartości 12 00 3E oznaczają że jest jedna linia o watości 00 i dwie linie o wartości 3E czyli:
0 0 0
0 1 1
0 1 1
0 1 1
0 1 1
0 1 1
0 0 0
i tak dalej.
Pozdrawiam
P.S. Czemu załącznik nie jest wyświetlany Przecież to *.gif
Telefon: NHM-5
Dołączył: 23 Mar 2004 Posty: 93 Skąd: Essen/Niemcy
Wysłany: 09 Lip 2005 15:46
To ja opisze kompresje grafik wprowadzana przez NokiX'a. Podobnie jak ta przy niektorych danych potrafi nawet je wydluzyc (w takim wypadku NokiX to rozpoznaje i nie uzywa kompresji), ale dlugie dane z powtarzajacymi sie bajtami beda sie pakowac dosc dobrze.
Kompresja ta pochodzi z formatu plikow graficznych IFF-ILBM, uzywanego dosc powszechnie na komputerach Amiga (ktore ciagle istnieja, sa uzywane i rozwijaja sie jakby ktos nie wiedzial ). Nazywa sie ona ByteRun1 i jej dzialanie najlepiej zobrazuje ten pseudo-kod procedury rozpakowujacej:
Kod:
UnPacker:
LOOP until produced the desired number of bytes
Read the next source byte into n
SELECT n FROM
[0..127] => copy the next n+1 bytes literally
[-1..-127] => replicate the next byte -n+1 times
-128 => noop
ENDCASE;
ENDLOOP;
Dziala to mniej wiecej tak, ze dane wejsciowe podzielone sa nastepujaco:
<bajt_informacyjny><dane><bajt_informacyjny><dane>...
jesli bajt_informacyjny = -128 (0x80) to nie ma za nim danych (w NokiXie oznacza on koniec danych wogole, czyli koniec rozpakowywania)
jesli bajt_informacyjny >= 0 to znaczy, ze za nim znajduje sie bajt_informacyjny+1 bajtow danych ktore musza byc po prostu skopiowane do bufora wyjsciowego
jesli bajt_informacyjny < 0 to znaczy, ze za nim znajduje sie tylko jeden bajt, ktory musi byc powtorzony -bajt_informacyjny+1 razy w buforze wyjsciowym, wlasnie takie dane sie pakuja
i to sie kreci w kolko dopoki bajt_informacyjny nie jest rowny 0x80 (-128). po tym w buforze wyjsciowym znajduja sie juz normalne dane, ktore trafiaja do draw_bitmap() i sa rysowane na ekranie.
jesli chodzi o kompresowanie normalnych danych (czyli operacje odwrotna) to polecam zajrzec do skryptu byterun1.rx z mojego pakietu skryptow NokiX'a.
Pelen opis formatu IFF-ILBM (po ang.) znajduje sie tutaj.
Format ten zostal opracowany w 1986 roku przez firme Electronic Arts (FIFA ). Powiecie, czemu on uzyl takiego archaicznego algorytmu. Ano dlatego, ze jest on dosc prosty a co za tym idzie szybki a ze w Nokiach nie ma Pentiumow to jest to dosc wazny aspekt. Poza tym ma inne zalety jak male wymagania pamieciowe itp., a poza tym po prostu go dobrze znalem.
Nie możesz pisać nowych tematów Nie możesz odpowiadać w tematach Nie możesz zmieniać swoich postów Nie możesz usuwać swoich postów Nie możesz głosować w ankietach Nie możesz załączać plików na tym forum Nie możesz ściągać załączników na tym forum
Przecież to *.gif
). Nazywa sie ona ByteRun1 i jej dzialanie najlepiej zobrazuje ten pseudo-kod procedury rozpakowujacej:
). Powiecie, czemu on uzyl takiego archaicznego algorytmu. Ano dlatego, ze jest on dosc prosty a co za tym idzie szybki a ze w Nokiach nie ma Pentiumow to jest to dosc wazny aspekt. Poza tym ma inne zalety jak male wymagania pamieciowe itp., a poza tym po prostu go dobrze znalem.
