Ausgeleuchtet - Bildformate Teil 3: IMG und PAC

Das GEM-Bit-Image-Format IMG ist sehr kompliziert aufgebaut und das STAD-Format PAC ist sehr verbreitet: Im dritten Teil unserer Bildformat-Serie erklären wir beide Formate, und auf der TOS-Diskette finden Sie Listings, um die Formate in eigenen Programmen auszuwerten.

Fast jedes Grafikprogramm kocht sein eigenes Süppchen in Sachen Bildformat. Die Rettung für austauschfreudige Anwender heißt Standardformat; und da gibt es eine ganze Menge: IFF, TIFF (siehe Ausgabe 7/90) und eben IMG. Die ersten beiden stammen ursprünglich von anderen Computersystemen und enthalten viel Schnickschnack, der für die Verarbeitung auf dem ST nicht notwendig ist. Lediglich das IMG-Format beschränkt sich auf die wichtigen Angaben. IMG besitzt zudem einen leistungsfähigen Datenkomprimier-Algorithmus, der die Datenmenge nach vier Methoden schrumpfen läßt.

Wie jedes Grafikformat beginnt auch IMG mit einem Dateikopf (Fileheader), der wichtige Angaben (Anzahl Bitplanes, Ausmaße etc.) über das gespeicherte Bild enthält (Listing 1). Das erste Wort »version« enthält die Versionsnummer (meistens 1) der Bilddatei. Das zweite Wort »headlen« gibt die Anzahl der Worte (meistens acht) im Dateikopf an. Das dritte Wort »nplanes« legt die Anzahl der Bitplanes fest. Ein monochromes Bild besitzt eine Bitplane, ein Bild der mittleren Auflösung zwei und ein Bild der niedrigen Auflösung vier Bitplanes. Das vierte Wort »patlen« enthält die Länge eines Datenmusters in Byte. Was Datenmuster sind, erfahren Sie später. Das fünfte Wort »pixel w«besagt, wie breit ein Pixel ist. Diese Angabe bezieht sich auf die Einheit »microns« (1/1000 mm). 25400 micron entsprechen einem Inch. Die Höhe eines Pixels in microns ist im sechsten Wort »pixelh« abgelegt. Wort 7 »linew« enthält die Bildbreite in Pixels und Wort 8 »nlines« schließlich die Bildhöhe.

Leider läßt sich nach dem IMG-Standard keine Farbpalette speichern. Viele Programme behelfen sich, indem sie die Palette in eine separate Datei schreiben. Einige Programme erweitern den Datei kopf der IMG-Datei um die Farbpalette. Aus diesem Grund sollten Sie nicht davon ausgehen, daß der Dateikopf acht Wörter umfasst, sondern die Headergröße aus dem zweiten Wort »headlen« lesen.

typedef IMGHEADER struct { 
unsigned version;
/* Versionsnummer der Image-Datei [1] */ 
unsigned headlen;
/* Länge des Dateikopfs in Worten [usually 8] */ 
unsigned nplanes;
/* Anzahl der Bitplanes [1 für monochrom] */ 
unsigned patlen;
/* Datenmuster länge in Byte [1-8, gewöhnlich 2 für Bildschirmobjekte] */
unsigned pixelw; /* Pixelbreite in microns */ 
unsigned pixelh; /* Pixelhöhe in microns */ 
unsigned linew; /* Bildbreite in Pixel */ 
unsigned nlines; /* Bildhöhe in Zeilen */

Listing 1. Die Dateikopf-Struktur des IMG-Formats

Datenkompression im IMG-Format

Direkt auf den Dateikopf folgen die komprimierten Bilddaten. Ist das Bild farbig (Bitplanes größer 1), so sind die (komprimierten) Bitplanes - im Gegensatz zum Bitplane-Aufbau des ST (Bild 1) - hintereinander abgelegt; zuerst Bitplane 1, dann Bitplane 2 usw. Deswegen müssen Sie nach dem Einlesen und Entkomprimieren der einzelnen Bitplanes das Bild zusammenfügen. In Monochrom entfällt diese Aufgabe. Der Dateikopf enthält im siebten Wort »linew« die Zeilenbreite in Pixels. Beachten Sie, das die Bilddaten Byte-weise gespeichert sind, so daß eine Zeile ein bis sieben Pixel breiter als die Angabe im Dateikopf sein kann.

Um die Bilddaten zu entkomprimieren, lesen Sie ein Datenbyte x und werten es mit folgender Vorgehensweise aus:

In der niedrigen Auflösung gibt es vier Bitplanes. Diese sind auf dem ST verzahnt: jeweils vier Speicherworte enthalten Informationen über 16 Pixel, wobei das erste Wort das jeweils niedrigste Bit der 16 Pixel enthält.

Beim Komprimieren eines Bildes in das IMG-Format legen Sie zunächst getrennte Bitmaps an. Im monochromen Modus ist dies unnötig, denn da gibt es nur eine Bitmap. In der mittleren Auflösung legen Sie zwei Bitplanes mit jeweils 16 KByte und in der niedrigen Auflösung vier Bitplanes mit jeweils 8 KByte an. Beginnen Sie nun das Komprimieren der Daten mit der ersten Zeile der ersten Bitplane. Prüfen Sie, ob sich die aktuelle Zeile wiederholt. In diesem Fall leiten Sie einen »Scanline Run« ein. Um die aktuelle Zeile zu komprimieren, gibt es zwei Methoden: das Erkennen von Datenmuster und leere bzw. gefüllte Pixelfolgen. Datenmuster haben im IMG-Format stets die gleiche Länge, die im Dateikopf (»patlen«) zu finden ist.

Beachten Sie beim Komprimieren, daß Sie zeilenorientiert arbeiten. So sollte beispielsweise ein »Scanline Run« zu Beginn einer neuen Zeile erscheinen und nicht mitten in der Zeile. Der Wiederholungsfaktor ist immer 1 Byte, so daß Sie maximal 255 gleiche Zeilen (»Scanline Run«), Datenmuster (»Pattern Run«), unkomprimierte Byts oder $0/$ff-Byte (»Solid Run«) zusammenfassen.

Das STAD-Format PAC

STAD war eines der ersten anspruchsvollen Malprogramme auf dem ST. Da sein Bildformat leistungsfähig und gleichzeitig unkompliziert ist, haben sich bis heute nahezu alle anderen Malprogramme dieses PAC-Formats angenommen. Im Gegensatz zum IMG-Format ist es allerdings auf monochrome Bilder mit den Ausmaßen 640x400 beschränkt.

Die ersten 4 Byte einer PAC-Datei stellen die Identifikationskennung »fileid« dar. Diese ist entweder MpM85" oder „PM86". Die Kennung „pM85" weist daraufhin, daß die Bilddaten horizontal (zeilenweise) gepackt sind. Die zweite Kennung „pM86" besagt, daß das Bild vertikal (spaltenweise) gepackt ist. Dieses Verfahren faßt zunächst von den 400 Zeilen das jeweils erste Byte zusammen, dann folgen das jeweils zweite Byte usw. Die Erfahrung zeigt, daß die vertikale Komprimiermethode besser als die horizontale ist. Dies liegt daran, daß in einem normalen Bild durchschnittlich mehr Spalten als Zeilen frei sind. Um das Bild immer bestmöglich zu packen, probiert STAD beim Speichern beide Methoden aus.

Die letzten drei Angaben »idbyte«, »packbyte« und »spbyte« im Dateikopf sind zum Entpacken der Bilddaten notwendig. Damit Sie verstehen, was die Angaben bedeuten, erklären wir den Komprimier-Algorithmus: STAD bestimmt vor dem Komprimieren das am häufigsten vorkommende (»packbyte«) Byte und die beiden am seltensten vorkommenden (»idbyte«und »spbyte«) Bytes im Bild. Anschließend sucht es Folgen von packbyte, die es zu einem Zwei-Byte-Code zusammenfaßt: einem ID-Byte (»idbyt«) und der Folgenlänge-1.

typedef PACHEADER
struct {
char fileid[4];
/* „pM85" (zeilenweise) oder „pM86" (spaltenweise) */ 
char idbyte; /* ID-Byte */
char packbyte; /* Packbyte (kommt am häufigsten) */ 
char spbyte; /* Spezialbyte */

Listing 2. Der Dateikopf des STAD-Formats (PAC)

Um zu vermeiden, daß der Entpacker ein im Bild vorkommendes Byte, das gleich »idbyte« ist, fälschlicherweise als Zwei-Byte-Code interpretiert, markiert er sie. Dazu benutzt STAD einen Drei-Byte-Code. Das erste Byte ist das »spbyte«-Bvte und dient wie »idbyte« zur Einleitung des Byte-Codes. Das zweite Byte gibt an, wie oft das dritte Byte in den Bildspeicher zu schreiben ist. Gilt beispielsweise idbyte=$8d und spbyte=$90, und trifft der Packer auf ein Datenbyte 8d, so erzeugt er den Drei-Byte-Code $90,$00,$8d. Trifft der Packer auf das Datenbyte $90, das in diesem Fall mit »spbyte« zu verwechseln wäre, so erzeugt er den Drei-Bytecode $90,$00,$90.

Durch den Drei-Byte-Code lassen sich auch Folgen von gleichen Byte zusammenfassen. Treffen Sie beispielsweise auf die Bytefolge $ 11 ,$ 11 ,$ 11 ,$ 11 ,$ 11 ,$ 11, so fassen Sie diese zu $90,$05$11 zusammen. Die Wiederholungsangabe ist ein Byte und erlaubt somit, maximal 256 Byte lange Folgen zusammenzufassen - das entspricht etwa drei Zeilen bzw. einer halben Spalte. Zum Entpacken lesen Sie ein Datenbyte x und werten es folgendermaßen aus:

Listings auf Diskette

Damit Sie das Rad nicht zweimal entwickeln, haben wir für Sie alle nötigen Listings zum Einbinden der besprochenen beiden Bildformate auf Diskette vorbereitet. DerC-Quelltext »IMG.C« stellt Ihnen drei Routinen zur Verfügung, um einen Bildausschnitt als IMG-Datei zu sichern (»savejmg«), zu laden (»load img«) und auf dem Bildschirm anzuzeigen (»showimg«). Die drei Funktionen greifen wiederum auf Assemblerroutinen zu. Diese beachten die drei Standardauflösungen 320 x 320, 640 x 200 und 640 x 400. Die Farbpalette wird im Dateikopf mitgespeichert. Genauere Informationen zu den Routinen finden Sie im Listing. Peter Melzer - der Autor von STAD - stellte uns freundlicherweise drei Listings für GFA-Basic und Assembler zur Verfügung, um PAC-Bilder zu speichern und zu laden. Weitere Informationen darüber finden Sie in den Listings. (ba)


Martin Backschat
Aus: TOS 08 / 1990, Seite 78
Links
Copyright-Bestimmungen: siehe Über diese Seite