Das PCX-Format -------------- PCX drfte neben GIF das am hufigsten anzutreffende Bildformat sein. Im Gegensatz zu GIF ist das PCX-Format aber nicht auf 256 Farben beschrnkt sondern reicht bis zu TrueColor. Da es obendrein noch relativ einfach aufgebaut ist (gemessen an GIF), habe ich mich entschlossen, es auch Euch ein wenig nher zu bringen. PCX-Dateien sind in 2 oder 3 Abschnitte unterteilt. Der erste Abschnitt ist der 128 Byte groe Header, der verschiedene Infor- mationen ber das Bild enthlt. Weiter geht's mit dem eigent- lichen Datenblock. Der dritte Abschnitt ist nur dann vorhanden, wenn es sich um ein 256 (oder mehr) farbiges Bild handelt. Dabei enthlt dieser dann die Palettenangaben. Header: Wie schon gesagt, ist der Header genau 128 Byte gro. Zuerst einmal ein Tabelle, die als bersicht dienen soll: Offset Lnge Info Hex:Dez Hex:Dez 00h: 0 01h: 1 Identifikationsbyte: 0Ah = PCX-Ken- nung. 01h: 1 01h: 1 Version des PCX-Bildes. 02h: 2 01h: 1 Kennung, falls PCX komprimiert: 0 = uncodiert, 1 = komprimiert. 03h: 3 01h: 1 Verwendete Bits pro Pixel. 04h: 4 02h: 2 untere X-Koordinate des Bildes. 06h: 6 02h: 2 untere Y-Koordinate des Bildes. 08h: 8 02h: 2 obere X-Koordinate des Bildes. 0Ah: 10 02h: 2 obere Y-Koordinate des Bildes. 0Ch: 12 02h: 2 horizontale Auflsung in dpi. 0Eh: 14 02h: 2 vertikale Auflsung in dpi. 10h: 16 30h: 48 Paletteninformation: 3 aufeinander folgende Bytes sind RGB-Werte einer Farbe. 40h: 64 01h: 1 reserviert. 41h: 65 01h: 1 Anzahl der Farbebenen. 42h: 66 02h: 2 Bytes pro Bildzeile. 44h: 68 02h: 2 Paletteninfo: 1 = Farbpalette, 2 = Graustufen. 46h: 70 3Ah: 58 Leerbytes. Wie man sieht, beinhaltet der Header alle mglichen Infos, die man (bis auf wenige) eigentlich vergessen kann, wenn man wei, um was fr ein Bild es sich handelt. Will man allerdings eine Routine schreiben, die selbstndig erkennt, um was fr ein Bild (Auflsung, Farben) es sich handelt, dann wird man den Header auswerten mssen. Von Interesse wre dann zum Beispiel die Anzahl der Farbebenen und die Bytes pro Zeile. Doch dazu spter mehr. Bei meiner eigenen PCX-Routine (mit Centrox Marx) frage ich z.B. nicht einmal ab, ob das zu zeigende Bild ber- haupt ein PCX-Bild ist... nunja, sie ist vorerst natrlich auch nur fr den Eigengebrauch gedacht. Das, was wirklich wichtig am Header ist, ist die Paletteninfo, die man ab dem 17. Byte findet. Interessant wre auch noch zu erfahren, ob es sich bei dem Bild um ein gepacktes oder ungepacktes Bild handelt. Allerdings ist mir letzteres noch nie untergekommen und kann daher auch vergessen werden. Zum DatenBlock: Wie oben gesagt, ist mir noch nie ein ungepacktes Bild begeg- net, daher habe ich keinerlei Erfahrung mit solchen Bildern und werde sie hier einfach mal unter den Tisch fallen lassen. Das gepackte Format steht also im Mittelpunkt. Und da es ein- fach einfacher (schnes Wortspiel...) ist, ein 256-Farben- Bild zu erklren (jeweils ein Byte reprsentiert auch ein Pixel), tu ich das jetzt auch einfach mal: Das PCX-Format benutzt das sogenannte Run-Length-Encoding- Kompressionsverfahren (RLE). Dieses Verfahren sieht vor, gleichfarbige Punkte, die hintereinander stehen, zusammenzu- fassen, indem es ein Index vor die jeweilige Farbe setzt, der angibt, wieoft die Farbe gesetzt werden soll. Steht also z.B. acht mal hintereinander die Farbe '0' im Bild, so wrde die- ses nicht als 0, 0, 0, 0, 0, 0, 0, 0 erscheinen sondern als 8 * 0 bzw. C8 00, wobei das 'C' vor der Acht besagt, da es sich bei diesem Byte um ein Index (Zhlbyte) und nicht um eine Farbe handelt. Da ein Byte hchstens den Wert 255 anneh- men kann, und die Hex-Zahl 'C0' alleine schon 192 betrgt, bleiben nur noch 63 (255-192) als 'maximale Wiederholungs- rate' (max. Index) brig. Wrden also zum Beispiel 48 Pixel mit der Farbe 10h in einer Zeile hintereinander stehen, so wrde der Datenblock die Bytes F0 10 beinhalten, wobei sich F0 aus C0+30/192+48 zusammensetzt. Will man nun 70 Pixel mit der Farbe 10 zusammenfassen, dann findet man FF 10 C7 10 : FF fr 63 und C7 fr 7 = 70! Ein Problem ergibt sich, wenn ein einzelner Punkt mit einer Farbnummer grer als 191 auf- taucht, denn dann knnte dieses Byte als Index fehlinterpre- tiert werden. Um das zu verhindern, wird ein C1 davor gesetzt. So, ich glaube das reicht fr das 256-Farben-Bild. 16-Farben-Bilder sind ein wenig anders aufgebaut, doch um dieses zu verstehen, mu man sich schon mit der direkten Programmierung der VGA-Karte in diesen Modis auskennen. Damit diejenigen, die davon zur Zeit noch nichts verstehen, auch etwas mitbekommen, verschiebe ich diesen Teil in die nchste Ausgabe von STOD, wo ich alle ntige erklren werde. Bis dahin also noch ein wenig Geduld! Die Farbpalette: Bei einem 256-Farben Bild ist die Farbpalette an das Ende der Datei angehngt. Dabei stehen jeweils drei Bytes fr die Rot- Grn und Blau (RGB) Werte der einzelnen Farben. Allerdings mu man diese erst durch 4 teilen, um auf den richtigen Farb- anteil zu kommen. Steht da also zum Beispiel FF FF FF (reines Wei) so sind die Farbeanteil jeweils 3F (63) fr Rot, Grn und Blau. Dem 768 Byte groen Block (256 * 3) geht noch ein '0C' voraus. Damit soll gekennzeichnet werden, da die nach- folgenden Daten wirklich Palettenangaben sind. Allerdings ist mir erstens noch nie ein Bild untergekommen, bei dem diese Angabe gefehlt hat, und ich habe zweitens arge Probleme zu verstehen, welche Sicherheit einem dieses Erkennungsbyte ge- ben soll. Denn schlielich knnte ja auch rein zufllig an der 769. Stelle vor Ende ein 0C stehen, oder? Natrlich ist die Wahrscheinlichkeit nicht besonders gro, aber es ist im- merhin nicht ausgeschlossen, da es doch vorkommt! Zur Palettenangabe im 16-Farben-PCX nchstes mal... Und nun noch ein paar Anmerkungen: Wie anfangs gesagt, ist das PCX-Format auch fr TrueColor- Bilder geeignet. Dabei reprsentieren dann jeweils drei hintereinander liegende Bytes einen Pixel - jeweils eins fr die Rot, Grn und Blau Werte. Da die Farben (RGB-Werte) also schon im Datenblock festgelegt werden, kann auf eine Paletteninfo natrlich verzichtet werden (wre bei TrueColor auch uerst witzlos - wrde man sie sinnloser Weise trotzdem angeben, wrde sie in jedem Bild 48 MB einnehmen (16.7 Mil. Farben bestehend aus jeweils drei Byte)...!). Wei man nicht, um welche Auflsung es sich bei dem Bild handelt, bleibt einem nichts anderes brig, als den Header auszuwerten. Bei dem Byte mit dem Offset 12/Ch kann man die horizontale Auflsung und bei dem Byte 14/Eh die vertikale Auflsung ablesen. Das Byte an der Offset-Adresse 3 lt sich zur Bestimmung der Farb-Anzahl benutzen. Steht hier zum Bei- spiel 8, so handelt es sich um ein 256-Farben-Bild. Bei 24/18h ist es ein TrueColor-Bild. Ein Program, da solch ein Bild auf den Schirm bringt, mte etwa folgende Struktur haben: Man liest ein Byte aus der Datei. Sind die oberen beiden Bits gesetzt bzw. ist der Wert grer als 192 (BYTE AND $C0 = $C0), so handelt es sich um ein Index (Zhlbyte). Handelt es sich um ein Zhlbyte, so wird das nchste Byte ge- lesen und sooft hintereinander in den Videospeicher geschrie- ben, wie es der Index angibt. Ist es kein Zhlbyte, so wird dieses Byte einmal in den Vi- deospeicher geschrieben. Wieder von vorne, bis nur noch 769 Byte brig sind bzw. 64000 (320*200) Pixel gesetzt sind. Danach Palette setzen. So, ich hoffe, da reicht fr's erste als Theorie. Sollten ir- gendwelche Fragen offen geblieben sein, so lest den Text noch- einmal. Sollten die Fragen dann immer noch nicht geklrt sein, dann schreibt uns ganz einfach, wir werden uns der Fragen dann schon annehmen. Wie gesagt, geht es in der nchsten Ausgabe mit den 16-Farben-PCXs weiter! Wenn Ihr jetzt noch nicht genug habt und auch noch ein wenig Praxis vertragen knnt, dann schaut mal in der Pascal-Rubrik vorbei... Kemil.