Unterformate: Version 2.5, 2.8 und 3.0 (Viele Programme zeigen nicht diese Versionen, sondern die im Header gespeicherten Bytewerte 0, 2 und 5.)
Farbtiefe: Bei Version 2.5 sind lediglich Schwarz/Weiß-Bilder mit 1 Bit pro Pixel zugelassen. Bei Version 2.8 sind bis zu 4 Bit (16 Farben) möglich. Die heute benutzte Version 3.0 beherrscht außerdem 256 und 16 Millionen Farben.
Maximale Bildgröße: 65.536 x 65.536 Pixel
Kompression: Mittelmäßig bis gut. Beim PCX-Format wird jede Zeile des Bildes getrennt komprimiert. Dabei werden nebeneinander liegende, gleichfarbige Punkte zusammengefaßt. Wenn das Bild z.B. viele einfarbige Flächen und nur wenige Farben besitzt, dann läßt es sich mit PCX sehr gut verkleinern. Wenn jedoch eingescannte, verrauschte Bilder als PCX gespeichert werden, können durchaus Dateien mit über 100% Größe entstehen!
Qualitätsverlust: Es gehen keinerlei Bildinformationen verloren. Auch sehr geringe Farbunterschiede werden 100-prozentig abgespeichert.
Geschichte: Das PCX-Format wurde ursprünglich für das Grafikprogramm PC-Paintbrush der Firma ZSoft entwickelt. Durch die Komprimierung, die leicht programmiert werden kann, ist es schnell sehr beliebt geworden. Heute kann praktisch jedes Programm dieses Format lesen. Häufig wird gerätselt, was die Abkürzung PCX bedeutet. Vermutlich steht sie für 'Picture Exchange', was etwa Bilderaustausch bedeutet.
Praktische Anwendung: Es gibt nur noch wenige Gründe, weshalb das Grafikformat PCX benutzt werden sollte. Das relativ neue PNG bietet mehr Optionen bei einer wesentlich besseren Komprimierung. Wenn es allerdings um Fragen der Kompatibilität geht, ist das PCX-Format unangefochtener Spitzenreiter. Weil die einfache Kompression keinen Lizenzrechten unterliegt und sie sich sehr leicht programmieren läßt, beherrschen selbst sehr alte Programme dieses Format. Eine weitere Anwendung ergibt sich aus den gleichen Gründen: In selbst geschriebenen Programmen ist PCX ideal.
Typische Software: PC-Paintbrush, NeoPaint, Publisher
Interner Aufbau: Jede PCX-Datei besitzt einen einheitlich aufgebauten Header von 128 Bytes Länge. (alle Zahlen in dezimaler Schreibweise)
| Offset | Bytes | Beschreibung |
|---|---|---|
| 0 | 1 | Identifikationsbyte 0AH |
| 1 | 1 | Dateiversion (0=Version 2.5, 2=Version 2.8 mit Palette, 3=Version 2.8 ohne Palette, 5=Version 3.0) |
| 2 | 1 | Flag für Komprimierung (0=unkodiert, 1=RLE-Kodierung) |
| 3 | 1 | Bits pro Ebene (1, 2 oder 8) |
| 4 | 8 | Koordinaten des Bildes als Worte (Xmin, Ymin, Xmax, Ymax) |
| 12 | 2 | horizontale Auflösung in dpi |
| 14 | 2 | vertikale Auflösung in dpi |
| 16 | 48 | Farbpalette für 16 Farben (jeweils Rot, Grün und Blau) |
| 64 | 1 | reserviert |
| 65 | 1 | Zahl der Farbebenen (1, 3 oder 4) |
| 66 | 2 | Bytes pro Bildzeile (gerade Zahl) |
| 68 | 2 | Palettendaten (1=s/w oder Farbe, 2=Graustufen) |
| 70 | 58 | Leerbytes zum Auffüllen des Headers |
Das erste Byte dient zur Identifikation einer gültigen PCX-Datei und sollte immer den Wert 10 (0AH) besitzen. Das Flag für die Komprimierung ist immer auf 1 gesetzt, denn unkomprimierte PCX-Datei hätten wenig Sinn. Besonders wichtig sind die Koordinaten bei Offset 4. Obwohl die dort gespeicherten Werte Xmin und Ymin praktisch immer auf Null gesetzt sind, sollten sie zur Berechnung der Bildgröße herangezogen werden.
Bei Offset 66 wird die Anzahl der Bytes pro Bildzeile gespeichert. Diese Zahl muß immer gerade sein - notfalls müssen überschüssige Bits mit Null aufgefüllt werden. Das Gleiche gilt für die Zeilenzahl des Bildes - diese sollte durch 8 teilbar sein. Bei Öffnen der Datei müssen diese Füllbits dann wieder abgeschnitten werden.
Farbpalette: Aus den Werten bei Offset 3 (Bits pro Ebene) und Offset 65 (Ebenen) kann die Farbtiefe des Bildes berechnet werden. Mögliche Kombinationen sind:
| Bits pro Ebene | Farbebenen | Beschreibung |
|---|---|---|
| 1 | 1 | Monochromes Bild mit 2 Farben |
| 2 | 1 | CGA-Bild mit 4 Farben |
| 1 | 3 | EGA-Bild mit 8 Farben (kaum benutzt) |
| 1 | 4 | EGA/VGA-Bild mit 16 Farben |
| 8 | 1 | VGA-Bild mit 256 Farben |
| 8 | 3 | TrueColor Bild mit 16 Millionen Farben |
In der Palette bei Offset 16 können maximal 16 Farben gespeichert werden. Jede Palettenfarbe wird mit ihren Farbanteilen Rot, Grün und Blau definiert. Die Zahlen können Werte von 0 bis 255 annehmen.
Für Bilder mit 256 Farben ist diese Palette nicht ausreichend. Darum wurde ab der Version 3.0 eine neue Möglichkeit geschaffen: Die Palettendaten werden zusammen mit einem Signaturbyte an das Ende der Datei angehängt. Dieser 769 Byte große Block enthält die Signatur 0CH und 256 Einträge zu je 3 Byte. Auch hier können die Farbanteile Rot, Grün und Blau Werte von 0 bis 255 annehmen.
Kodierung der Bilddaten: An den Header schließen sich die Bilddaten an. Jedes Bild wird zeilenweise abgetastet und in seine Farbebenen (Rot, Grün, Blau und Intensität) zerlegt. Dann werden alle Bits in der ersten Zeile der roten Farbebene wortweise zusammengefaßt und gespeichert. Unbelegte Bits im letzten Wort werden mit 0 aufgefüllt. Anschließend folgt die Abspeicherung der ersten Zeile der grünen Farbebene, der blauen Ebene und der Intensitätsinformation. Erst danach kann die zweite Zeile der roten Ebene gespeichert werden.
RLE-Komprimierung: Jede Farbebene wird getrennt komprimiert. Die Bytes darin sind wie folgt zu lesen: Sind die beiden oberen Bits (6 und 7) eines Bytes gesetzt, liegt eine komprimierte Information vor. Die Bits 0 bis 5 werden dann als Zähler interpretiert, die den Wiederholungsfaktor für das im folgenden Byte gespeicherte Muster angeben. Sind die beiden oberen Bits eines Bytes nicht gesetzt, liegt ein reines Datenbyte vor. Die Bits 0 bis 7 lassen sich dann direkt als Bilddaten verarbeiten.
Das heißt: Bei der Speicherung unkomprimierter Bytes ist darauf zu achten, dass die beiden oberen Bits der Pixelfolge auf 0 gesetzt sind. Datenbytes, bei denen diese Bits nicht auf 0 gesetzt sind, müssen wie komprimierte Bytes behandelt werden.
Beispiele: Die Bytefolge 'C4 FE' gibt eine komprimierte Zeile an und wird als 'FE FE FE FE' dekodiert. Die '13' bleibt als unkomprimiertes Byte bestehen, da die Bits 6 und 7 nicht gesetzt sind. Die Bytefolge 'C1 C9' ist wiederum als komprimierte Pixelzeile zu lesen. Hier wird jedoch nur das einzelne Bitmuster 'C9' verschlüsselt, da Zahlen ab 64 nicht unkomprimiert gespeichert werden dürfen. (denn dort sind die Bits 6 und/oder 7 gesetzt)