.bmp I Algorytm Rle

[MeHow]

Witam.

 

Mam do napisania program w MIPSie. Jest to nieważne w jakim języku, poradzę sobie chyba jakoś. Mam tylko parę pytań.

 

Wiem już jak działa kodowanie RLE - tzn zastępuje ciąg znaków liczbą wystąpień danego znaku i potem tym znakiem. Proste: np. AAABBBBC zamieni na *3A*4BC . Ładnie i zabawkowo, mam jednak parę pytań odnośnie struktury .BMP .

 

Czy ja mam sobie przelecieć po prostu po całym pliku i pozamieniać go w taki radosny sposób, czy może mam ominąć jakiś nagłówek bitmapy? Czy możecie mnie jakoś pokierować?

 

 

----8<---------------8<----------EDYCJA-------------8<----------------8<------------------

 

Ok, znalazlem pare informacji.

 

Po pierwsze, projekt ma dotyczyć tylko BMP 8bitowego. No i tam takie info:

 

- Pierwsze 1078 bajtów zawiera:

- nagłówek 54 bajty, najważneijsze pola to:

- bajty 0x12 - 0x15 - szerokość obrazu w pikselach (little endian)

- bajty 0x16 - 0x19 - wysokość obrazu w pikselach (little endian)

- bajty 0x1c - 0x1d - liczba bitów na piksel (little endian)

- bajty 0x1e - 0x21 - typ kompresji (little endian), 0 - brak, 1 - RLE

- bajty 0x22 - 0x25 - rozmiar danych obrazu w bajtach

- paletę kolorów (1024 bajty dla obrazów 8 bitowych)

- dalej zapisane są dane obrazu w sposób wynikający z nagłówka (uwaga na wyrównanie linii do 4 bajtów).

 

 

 

Teraz seria moich pytań do szanownych tutaj zgromadzonych :)

1. rozumiem, że np liczba 0x12 to jest liczba szesnastkowa czyli 18 ?

2. rozumiem, że liczba bitów na piksel to w moim przypadku będzie po prostu 8 ?

3. o co chodzi z tym wyrównaniem linii do 4 bajtów i zapisa danych obrazu wynikający z nagłówka? Czy wystarczy, że kompresując do RLE przepiszę sobie ten śmieszny nagłówek, zamienię bajty 0x1e, 0x1f, 0x20, 0x21 po prostu wstawiając radośnie tam int = 1 (int ma 4 bajty z tego co wiem), a potem po przekroeczniu wszystkich bajtów nagłówka radośnie zastosuję algorytm RLE na reszcie pliku?

Edytowane 8 Listopada 2005 przez MeHow

[Gość]

1. rozumiem, że np liczba 0x12 to jest liczba szesnastkowa czyli 18 ?

Tak, wszystko co ma 0x z przodu to hex. Takie jest przyjete oznaczenie tego systemu.

2. rozumiem, że liczba bitów na piksel to w moim przypadku będzie po prostu 8 ?

To sa bity palety kolorow.. czyli jak dasz 8 bitow to jest 256 kolorow, jak chcesz wiecej to musisz tu wpisac odpowiednia wartosc. Nie znam formatu bitmapy, ale pewnie dopuszczalne jest tylko kilka predefiniowanych wartosci.

3. o co chodzi z tym wyrównaniem linii do 4 bajtów i zapisa danych obrazu wynikający z nagłówka?

Wyrownanie.. w zasadzie nazwalbym to raczej dopelnieniem, latwiej skojarzyc o co chodzi. Nie zaglebialem sie w bitmapy, ale moge domniemywac, ze chodzi o wyrownanie ostatniej "paczki" danych. Jesli ilosc bajtow "wlasciwych" bitmapy (wszystko poza naglowkiem) nie jest wielokrotnoscia czwórki to te ostatnie kilka bajtow dopelniasz do 4. Nie napisano czym, wiec pewnie zerami.

Zapis wynikajacy z naglowka - chodzi o to, ze bitmapa ma byc zapisana w sposob jaki podano w naglowku, czyli jesli podales w nim, ze jest kompresja RLE to nie mozesz sobie bitmapy nieskompresowanej trzasnac. Tak samo na postac danych wplywa tez ilosc kolorow, wiec chodzi o to, ze te dane maja byc zgodne z tym co podales w naglowku.

Czy wystarczy, że kompresując do RLE przepiszę sobie ten śmieszny nagłówek, zamienię bajty 0x1e, 0x1f, 0x20, 0x21 po prostu wstawiając radośnie tam int = 1 (int ma 4 bajty z tego co wiem), a potem po przekroeczniu wszystkich bajtów nagłówka radośnie zastosuję algorytm RLE na reszcie pliku?

Prawie.. 0x1e-0x21 to jest 4 bajtowy int i to on ma miec wartosc 1, a nie kazdy bajt z osobna (wtedy otrzymal bys "troche" wyzsza liczbe). Dodatkowo musisz pamietac, ze to jest little-endian. Nigdy tego nie moge spamietac, ale chyba "maly-indianin" ;] ma najmniej znaczace bajty najpierw, wiec liczba 1 w tym zapisie przedstawia sie tak: [0x01,0x00,0x00,0x00], a nie odwrotnie.

 

PS. looknij sobie na www.wotsit.org, tamtejsze rozpiski czesto zawieraja jakies przykladowe kody, moze to Ci cos pomoze :)

Edytowane 8 Listopada 2005 przez FiDO

[PelzaK]

1. tak

2. tak

3. tutaj najprosciej jest stworzyc plik BMP w paincie nawet, o rozmiarze 2x2 pixele, ablo 8x8 pixeli... zapisac jako BMP noncompresaed, potem zapisac jako bmp z kompresja RLE... i za pomocą hex editora przesledzic róznice w obu plikach... kiedyś sie w to bawiłem i to jest troche pouczające... . Zrób sobie obrazek np szachwonice, albo połowe czarną a połowe białą 8 bit dla uproszczenia.. bedą prste wartosci 00h i FFh

 

Bo jesli juz zaznaczasz w nagówku ze plik jest skompresowany metodą RLE to powinno to byc skompresowane wg standardu. Bo po swojemu zawsze mozna sobei skompresowac zapisac i odcyztać :D

[MeHow]

O! PelzaK, dobrze mówisz. Chciałem otwierać te bitmapy, ale durnie w notatniku albo mcedicie próbowałem. Zaraz poszukam jakiegoś kalkulatora hexow, żeby zobaczyć jak to wygląda. :)

 

Oj kurcze, durne to jest niemożliwie... zrobiłem sobie bitmapę 2x2 , szachownicę czarno biała i za nic nie umiem odczytać gdzie te kolory siedzą. Zapisałem to w 256kolorach, więc jest 8 bitowe. Czyli w hex editorze 2 sąsiednie komórki to jeden kolor. Tak więc otwieram sobie, patrzę ... ostatnia komórka to 43D, więc w sumie mamy 1088 komórek, czyli 1088 bajtów. 1078 bajtów to nagłówek, tak więc ostatnie10 komórek to kolory mojej szachownicy i pewnie zakończenie pliku albo jakieś niezrozumiałe dla mnie uzupełnienie. Oto one:

FF 00 00 00 00 FF 00 00 00 00

Szachownica wyglada tak, że w lewym górnym i prawym dolnym ma czarne pola, a w lewym dolnym i prawym górnym ma białe pola.

 

Wytłumaczcie proszę co tu odpowiada za co, bo już gorączki dostaję :/

 

 

--- EDIT ---

 

zrozumiałem

 

FF - biały

00 - czarny

00 00 - uzupełnienie do 4 bajtów

00 - czarny

FF - biały

00 00 - uzupełnienie do 4 bajtów

 

Jak będę miał jeszcze dalsze problemy, to napiszę ;)

Edytowane 8 Listopada 2005 przez MeHow

[Haquim]

Opis BMP

tu jestopis formatu RLE8 po angielsku (szczegółowy)

http://atlc.sourceforge.net/bmp.html

i po polsku ( ogólny)

http://sprocket.ict.pwr.wroc.pl/~pawel/dyd...ormat%20BMP.pdf

[MeHow]

Kurcze, jakoś nie umiem zrozumieć jak działa to RLE :/ . O co w tym do cholery chodzi?

 

W ogole nie umiem skonwertowac niczego do tego RLE nawet jak patrze na tego manuala :/ :/ :/ . Jest juz 22, a ja ciagle siedze nad tym durnym problemem. Zrozumialem jak sie zachowuje normalna bitmapa, ale jak konwertowac, tego nie wiem :/ . Ten sam obrazek zapisalem uncompressed i z RLE, oto kody:

 

uncompressed:

00 00 00 00 00 00 FF 00 00 FF 00 00 00 00 00 00 00 00

RLE:

00 02 02 01 01 FF 00 00 01 00 01 FF 00 01

Prosze, niech ktoś mi wyjaśnie dlaczego to się tak zmienia :( już nie mam siły :( :( :(

[PelzaK]

hehe.. wiesz ze nawet zrobiłem tez 2x bmp i zacząłem porównywać.. ale czas mnie naglił.. a i teraz tez nie mam czasu... Trezba znalesc porządną specyfikacje, najlepiej z kodem do robieamie RLE.. poszukaj na google@ programsersheaven...

[MeHow]

guglalem... oj guglalem az do bolu i niestety kodu w C ew C++ do kompresji RLE nie ma :/ . Na grupach polecaja pare bibliotek, ktorych wybebeszenie konczy sie tylko moim zawrotem glowy - po prostu nie rozumiem kodu :( . Chyba zabiore sie do stworzenia wlasnego algorytmu.