Grafikformate, Teil 3

von Olaf Piesche und Christian Eyrich

Formatieren - 80 Spuren, 18 Tracks

Nein, das ist es nicht. Es geht hier doch um Bilder und keine Disketten.

Nachdem in den beiden vorangehenden Folgen Theoretisches und Grundlegendes über Grafiken und Grafikformate beschrieben wurde, gehen wir nun auf die Formate an sich ein. Zunächst folgt allgemeines über verschiedene Formen, Bilder zu speichern. Vier Formate werden näher behandelt und dann folgen noch kurze Infos zu ein paar bekannten.

Übersicht:
  Klassifizierung
  Photo-CD
  TGA
  GEM-IMG
  Spectrum 512 - Buntibunti...
  Diverse Formate
  Abschied?

Klassifizierung

Grafikformate lassen sich nur schwer so aufteilen, daß man sagen könnte, die Guten stehen dort und die Bösen da drüben.

Ein Versuch ist die Unterteilung einerseits in solche, die einfach hintereinander weggeschrieben werden und einen starren Aufbau besitzen Und andererseits in die flexiblen, die aus einem beliebig erweiterbaren Grundgerüst bestehen. Wie Module können einzelne Erweiterungen später noch angefügt und das Format ohne Probleme erweiterten Anforderungen gerecht werden. Manche sind sogar so flexibel, daß sie interpretiert werden müssen wie Programme.

Das starre Format

Die meisten Formate zählen zu erster Gattung. Diese bescheren meistens einen recht einfachen Importer, der geradlinig das Bild einliest. Ausnahmen bestätigen allerdings die Regel (Bilder im Q8 - Japan Image Format z.B. werden in vier Dateien gespeichert, eine Headerdatei und die drei Farbteile R, G, B).

Die flexiblen Formate

Wegen ihrer Flexibilität erfordern die Formate der zweiten Gattung auch komplexere Importer. Unbekannte Informationsmodule in der Datei müssen übersprungen werden oder aber über vom Exporter weggelassene Informationen müssen Annahmen gemacht werden.

Das klassische Beispiel hier ist TIFF (Tagged Image File Format) in welchem auch 3,5 Bit pro Farbe prinzipiell nicht unmöglich sind. Allerdings ist das TIF-Format gut dokumentiert und zahlreiche Codebeispiele sind verfügbar (deren Nutzen sich allerdings wieder sehr in Grenzen hält, denn dabei müssen nicht nur das Format, sondern auch die Gedankengänge des Programmierers verstanden werden). Dem entgegen steht ein Format wie Apples PICT. Hier nennen sich die Informationsmodule nicht Tags, sondern Opcodes. In diesem Format jagt eine Designschwäche die andere, das Format muß nicht gelesen, sondern interpretiert werden. Mac-Programmierer werden allerdings nur selten ein Wort über das Format verlieren (ob gut oder schlecht), dort macht das Betriebssystem die Hauptarbeit.

Eine weitere Aufteilung läßt sich zum Beispiel dadurch erzielen, in dem die unkomprimierenden Formate in die eine Ecke und die komprimierenden Format in die andere Ecke gestellt (und erschossen) werden. Verhältnismäßig wenige Formate unterstützen die Speicherung sowohl mit, als auch ohne Komprimierung.

Formate, die entwickelt wurden, um eine Grundlage für den Bilderaustausch zwischen Programmen und insbesondere zwischen Betriebssystemen zu schaffen:
Dies wären GIF, TIFF und JFIF, EPS für den allgemeinen und so Dinger wie GOES, IBG oder HDR für die Übermittlung und Speicherung von Wetter- und Satellitenbildern als Standard für solche Institutionen.

Dann gibt es noch die kleine Gruppe der Formate, die zum Abspeichern eines Bildschirms, also Snapshots entwickelt wurden, das sind meistens nur Rohdaten, wie sie im Speicher stehen, vielleicht noch mit einem Header für Breite und Höhe.
Beispiele hierfür sind das XBM, XPM Format für X, DOO sozusagen als ST-High Screendump und ein namenloses für das BeOS.

Formate, die als Standard innerhalb einer Betriebssystemplattforma gedacht waren: GEM-IMG, PICT, SGI, Sun Raster und IFF.

Jeder kocht sein eigenes Süppchen

Die weitaus größte Gruppe der Formate bildet sich aus jenen, die sich Programmierer eine Grafikprogrammes ausgedacht haben um die gemalten oder berechneten Bilder auf die Platte zu bringen. dazu gehören z.B. PSD Photoshop Format, Spectrum, Fontasy Grafik, Edsun Labs, First Publisher, Tiny, QRT Raytracer, Cubicomb Picturemaker, Dr. Halo Picture, Vivid Raytracer, Targa, Turbo Pascal Image usw.

Das interne Format

Und dann fiele mir noch eine vierte Unterscheidung ein, nämlich wie die Daten selbst vorliegen. Es gibt zwei grundsätzliche Datenformate: Motorola und Intel, benannt nach den Herstellern, deren Prozessoren das eine oder andere Format benutzen.

Intel hat den ersten Mikroprozessor gebaut, und dabei schon gleich den ersten Fehler gemacht. Das Wort Fehler nehme ich mir jetzt einfach heraus, immerhin haben wir ja wohl alle was gegen Intel und zweitens widerspricht deren Format dem, was man als normaler Mensch implementieren würde ;-)

Das Byte, bestehend aus acht Bits, wie wir es schon in der Schule lernen:

       7 6 5 4 3 2 1 0

Hier bleiben sich Intel und Motorola gleich.

Und wie würde der gesunde Verstand das fortsetzen, wenn man einen 16 Bit-Wert, einen Integerwert schreiben soll? Ich vermute, etwa so:

       15  14  13  12  11  10  9 8 7 6 5 4 3 2 1 0

Tja, Intel jedoch meinte, zwei Bytes folgendermaßen zu einem 16 Bit-Wert zu verbinden, wäre einem gesunden Verstand eher entsprechend:

       7 6 5 4 3 2 1 0 15  14  13  12  11  10  9 8

Kopfschmerzen? Genau, deshalb wird das Intelformat auch als verdreht bezeichnet. Die Bezeichnungen, auf die man beim Programmieren immer wieder stößt sind big-endian bzw. most-significant byte (MSB)und little-endian bzw. least-significant byte (LSB - nicht zu verwechseln mit irgendwelchen Psychopharmaka!). Diese Bezeichnung bezieht sich darauf, ob das Byte mit der geringeren oder der höheren Wertigkeit vorne steht. Bei Motorolas Format trifft ersteres zu, bei Intel das andere.

Diese Unterscheidung trifft im Header und sonstigen Angaben zu, sobald 16 Bit-Werte vorkommen oder wenn 16 Bit-Werte in den Bilddaten stehen.
Aber auch wenn 24 Bit Werte in den Bilddaten stehen, kommt es zu Unterschieden. So ist dort mit Motorolaformat die Reihenfolge RGB gemeint, wohingegen bei Intel die Farben in der Reihenfolge BGR im Bild stehen.

Photo-CD

Das Photo-CD-Format (siehe auch Artikel in ATOS 2/97) wurde von Eastmen-Kodak entwickelt. Ursprünglich war es dafür gedacht, daß sich die Leute keine Dias mehr ansehen müssen, sondern ihre Urlaubsfotos auf CD bekommen. Daheim haben sie dann einen sog. Photo-CD-Player, mit dem die Bilder auf dem Fernseher dargestellt werden. Von diesem Standpunkt aus war die Entwicklung aber nicht so der Durchbruch, denn der Player ist leider auch zu teuer. Am Computer hat sich das Ding jedoch ganz gut durchgesetzt (was aber auch nur möglich wurde, weil CD-Laufwerke sowieso so verbreitet sind) und so sind recht viele Bildersammlungen auf CD erhältlich.

Eine normale PCD-Datei enthält jeweils ein Bild, aber in verschiedenen Auflösungen. Ausgegangen wird von 768*512, welche als Base bezeichnet wird. Runter geht es dann über Base/4 (384*256) bis Base/16 (192*128). Über Base gibt es Base*4 (1536*1024), Base*16 mit 3072*2048 und Base*64 mit 6144*4096. Anscheinend recht beliebt ist das Ding auch in der Medizin, die speichern allerdings keine Landschafts- oder Bikini-Photos darauf, sondern Röntgenbilder und Ultraschallaufnahmen. Und dann noch dazu so groß, daß Kodak hierfür Base*256 mit der Wahnsinnsauflösung von 12288*8192 definiert hat. Allzuviele Bilder passen dann aber selbst auf eine CD nicht mehr drauf, die unkomprimierte Datenmenge beträgt immerhin 288 MB.

Grundsätzlich werden die Bilder erstmal kleiner gemacht, indem die Hälfte der Informationen einfach weggelassen werden. Das hört sich etwas brutal an, was es aber nicht in dem Maße ist. Das Bild wird ins YCbCr-Farbsystem umgerechnet und weggelassen wird nur ein Teil des unter Ausnutzung der Eigenschaft des menschlichen Gehirns, Farbintensitätsunterschieden gegenüber nicht so empfindlich wie für Helligkeitsunterschiede zu sein, unwichtigeren CbCr-Teiles, welcher die Farbinformationen trägt. Der Y-Teil bleibt vorhanden und der weggefallene CbCr-Teil wird bei der Darstellung interpoliert.
Bis inklusive der Base-Auflösung ist dies alles, was mit dem Bild angestellt wird. Die darüber liegenden Auflösungen sind jedoch auch recht trickreich realisiert. Es ist schade, daß ich hier etwas nebulös von irgendwie schreiben muß, aber Kodak hat dafür gesorgt, daß keine Informationen über das PCD-Format zu erhalten sind, bevor man nicht ein paar Tausender abdrückt.(!nl) Die Bilder in den hohen Auflösungen sind auf jeden Fall nicht mal zur Hälfte enthalten, sondern errechnen sich teilweise irgendwie aus den darunter liegenden Auflösungen. Darüberhinaus sind die Informationen dann auch noch per Huffmann codiert.

TGA

TGA ist ein Beispiel für ein ganz normales Bildformat. Das TGA-Format ist eines jener, die eigentlich für einen speziellen Zweck und ein Produkt entwickelt wurden. Allerdings hat es sich inzwischen zu einem der am weitesten verbreiteten gemausert.

Die weite Verbreitung hat mehrere Gründe. TGA war das erste 24-Bit-Truecolorformat (1987), ist genau beschrieben und die Beschreibung ist leicht zugänglich (sogar mit Diskette und Beispielsourcen!), was man beides nicht von allen Formaten sagen kann. Zwar fehlt eine ordentliche Komprimierung (nur RLE), aber gerade der einfache Aufbau macht die Implementierung in das eigene Programm recht einfach.

Das Format stammt von der Firma Truevision, die Hersteller der Grafikkartenfamilien Targa, Vista und NuVista für PC und Mac ist. Diese Karten können Videosignale verarbeiten und Snapshots von Videobildern machen. Und für die Speicherung dieser Snapshots entwickelte Truevision das Format TGA (nicht Targa!).

Schon 1984 fing die Firma noch als Teil von AT&T und unter dem Namen EPICenter an, Grafikkarten zu bauen. 87 wurde EPICenter dann von Angestellten AT&T abgekauft und in Truevision umbenannt. EPICenters erstes Produkt schon konnte 256x200 mit 16,78 Millionen Farben darstellen. Mit der zweiten Karte (das Image Capture Board) begann dann die Ära der Videobearbeitung.

Ein gekauftes Grafikprogramm, später bekannt unter Truevision Image Paint System, versetzte die User der beiden Karten (und später der Targa und TrueVista) in die Lage, Videobilder zu capturen, Grafiken zu erstellen und in ein Video einzufügen, sowie Bilder zu manipulieren. Damals vergab das Programm verschiedene Dateiextender, .VDA, .ICB, .TGA und .VST, für jede Grafikkarte einen. Aber es sind alles Grafiken im TGA-Format, die heute TGA oder TPIC als Extension haben.

1989 wurde das Format überarbeitet und seitdem gibt es das ursprüngliche TGA-Format unter der Bezeichnung original TGA format und new TGA format. Das neue TGA-Format ist voll kompatibel zum Originalen, enthält aber hinter den Bilddaten noch Angaben zu Gamma- und Farbkorrekturinformationen, Pixelgrößenverhältnis und Bereiche, in denen Programme für sie relevante Daten beliebig unterbringen können.

Das Format an sich ist unspektakulär. Der 18 Byte große Header enthält die normalen Angaben wie Magic, Farbtabellentyp, Farbtabellenanfang, Farbtiefe, Bildgröße und X-/Y-Offsets. Ein eher seltenes Feature ist das bis zu 255 Bytes große Textfeld, in dem der User oder das speichernde Programm ein paar Worte unterbringen kann.

Mögliche Farbtiefen sind 32 Bit, 24 Bit, 16 Bit, 15 Bit im High- bzw. Truecolorbereich und 8 Bit sowie 1 Bit als Palettenbilder.

Da das Format PC-Karten entstammt, liegen leider alle Angaben im Intelformat vor und müssen vor der Benutzung auf Maschinen mit Motorolaprozessor erst entwirrt werden - irgendeinen Nachteil gibt es leider immer.

GEM-IMG

Das ist unser Format. Also nicht Olafs und meines, sondern des Atarianers Hausformat. 1984 entwickelte Digital Research das GEM-System und für die Speicherung von Bitmapdateien das IMG-Format. Obwohl es GEM für PC als auch eingebaut für STs gibt/gab, liegen Daten in einem IMG immer im Motorolaformat vor (im Gegensatz zum GEM-Metafile, welches immer im Intelformat speichert) - Glück gehabt.

Es gibt sogar einen VDI-Befehl, der Grafiken im IMG-Format auf einen Drucker ausgibt. Trotzdem hat es einige Zeit gedauert, bevor sich z.B. Wordplus dieses Formats bedient hat, um Grafiken mit anderen Programmen auszutauschen. Heute ist es, auch wenn von vielen totgesagt, tagtäglich öfter im Einsatz, als Sie vielleicht denken. Denn alle Bilder, die über das GEM-Clipboard ausgetauscht werden (SCRAP.IMG) liegen in diesem Format vor!

Das originale IMG-Format von DR ist an sich recht einfach; was es etwas schwierig zu lesen macht, ist die Kompression. Die im zeilenweise interleavten Bitmapformat vorliegenden Bilddaten können nämlich auf viererlei Arten komprimiert sein.

Die erste mit Namen Bit String entspricht dem Literal Run aus anderen Formaten, unkomprimiert also. Der Pattern Run entspricht dem Compressed Run (aus der RLE), ist aber um die Tatsache erweitert, daß nicht nur gleiche Bytes zusammengefaßt werden können, sondern ganze Gruppen von ein bis acht Bytes, Muster also.

Der Solid Run dann macht die außerordentlich gute Kompressionsrate bei monochromen Bildern aus. Mit ihm können nämlich bis zu 127 schwarze, bzw. weiße Pixel in nur ein Byte zusammengefaßt werden. Er ist allerdings auch der Grund, weshalb die Kompressionsrate des Formats denen anderer RLEs etwas hinterherhinkt, wenn die Bilder nicht einfach nur schwarzweiß sind. Um die beiden ersten nämlich vom Solid Run zu unterscheiden, müssen die vor jeden Run noch ein Kennungsbyte stellen. Und das vergrößert das File wieder etwas. Und noch eine weitere Besonderheit, die sich allerdings fast nie ausspielen läßt, weist das IMG-Format auf. Nämlich eine Art vertikalen RLE, den Vertical Replication Count. Mit ihm können Folgen gleicher Zeilen zusammgefaßt werden.

Der Header selbst weist nur die Kopflänge in Words, die Anzahl Planes im Bild, die Größe und Angaben zur Pixelgeometrie auf.

1990 haben sich dann die Gebrüder Geiß in ihrem Buch Vom Anfänger zum GEM-Profi daran gemacht, das ursprüngliche GEM-IMG zu erweitern und haben im den Namen XIMG für eXtended IMG gegeben.

Ihnen ging es um die Lösung des Problems, daß man bei einem IMG nie wußte, wie die Farbeinstellungen waren, als das Bild erzeugt wurde. Wie es sich für Palettenformate nämlich gehörte, waren in den Bilddaten nämlich nur Palettenindizes angegeben. Allerdings in diesem Fall keine Indizes zu einer mitgelieferten Palette, sondern VDI-Indizes. Diese VDI-Indizes zeigen nach einer kleinen Umrechnung auf Farben in der momentan beim Laden aktiven Systempalette und die kann ganz entscheidend von der beim Speichern aktiven abweichen.

Also gingen die Geißens daher und definierten, daß im XIMG eine Farbpalette mit abgespeichert werden kann. Gekennzeichnet wird das Format mittels den vier Buchstaben XIMG im Header. Die Palette liegt dabei im VDI-Format, also mit Promillewerten, vor. Auch sind vier verschiedene Farbsysteme für die Palette möglich, nämlich RGB, CMY, HLS und sogar Pantone - allerdings sind mir noch keine anderen als RGB untergekommen.

Noch ein Wort zu GEM-Images in Truecolor. An dieses Format haben sich nämlich parallel zwei Programmierer gemacht und so existieren leider zwei verschiedene, zueinander inkompatible (und leider für ein Programm auch nicht unterscheidbare) TC-IMGs. Das eine stammt vom Programm PixArt und ist vom Format her kompatibel zu den niedrigeren Farbtiefen, d.h. die 3 Bytes der Bilddaten sind auf 24 Planes verteilt. Das ist zwar konsequent, für ein TC-Format aber recht umständlich zu handlen.

Das wird sich auch Dieter Fiebelkorn gedacht haben und läßt sein Programm GEM-View TrueColor-IMGs pixelpacked abspeichern.

Spectrum 512 - Buntibunti...

So. Nachdem Christian jetzt die wichtigen Grafikformate behandelt hat, will ich jetzt mal auf eins eingehen, das einfach nur interessant ist ;-)

Das Grafikformat ist Programm: Spectrum 512 ist ein Zeichenprogramm, das auf den STs für Aufsehen gesorgt hat, da es in der Lage war, durch findige Programmierung auf jedem ST bis zu 512 Farben gleichzeitig darzustellen - in einer Zeit, zu der auf den PCs die Hercules-Grafik noch Standard war, und da STs aus rein hardwaretechnischen Gründen eigentlich nur 16 aus 512 Farben gleichzeitig auf den Screen zaubern können, eine Revolution.

Die Darstellung dieser ungeahnten Farbenvielfalt wurde über einen kleinen aber wirksamen Trick geregelt: Der ST bietet mittels seines MFP-Chips die Möglichkeit, bei bestimmten Ereignissen Interrupts (Programmunterbrechungen, bei denen an eine andere Stelle im Programm gesprungen werden kann) auslösen zu lassen, so zum Beispiel bei einem horizontalen Zeilenrücklauf des Rasterstrahls der Bildröhre.

Wenn so ein Interrupt ausgelöst wurde, wartet man noch ein bißchen (je nach Zeilenfrequenz des Monitors, da auf den STs mit RGB-Monitoren gearbeitet wurde, beträgt diese um die 15 kHz), bis der Rasterstrahl anfängt, die nächste Zeile aufzubauen, und dann passiert folgendes:

Wenn Ihr aufgepaßt habt, wißt Ihr aus dem ersten Teil noch, daß sich bei Palettenverarbeitung die Farben auf dem Bildschirm ändern, wenn die Palette verändert wird, da jeder Pixelwert im Bild nur einen Verweis auf eine Farbe in der Palette darstellt (Palettenbilder). Und genau das wird hier gemacht, um die 512 Farben zu erreichen. Die Farbpalette des ST-Grafikprozessors enthält 16 Farben, deren RGB-Komponenten aus jeweils drei Bit zusammengesetzt werden. Das heißt, daß die 16 Palettenfarben aus bis zu 512 Farben eingestellt werden konnten.

Während auf dem Bildschirm dessen Rasterstrahl noch eine Bildzeile aufbaut, wird mittels eines Rasterinterrupts die aktuelle Farbpalette, die 16 Farben beinhaltet, umgeschaltet. Während einer Bildschirmzeile passiert dies 3 mal, so daß sich für jede Zeile 48 Farben ergeben, die aus den 512 Palettenfarben des ST frei gewählt werden können. Für 199 Bildschirmzeilen (die oberste Zeile wird in Spectrum nicht dargestellt) würden sich also 199*48=9552 Farben ergeben. Da diese mit den Standardpaletten des ST dargestellt werden, bleibt es jedoch bei 512 verschiedenen Farben. Die Interpretation eines so spezialisierten Grafikformates ist natürlich nicht so ganz einfach. Es gibt außerdem noch 4 verschiedene Spectrum-512-Formate: SPU (uncompressed), SPC (compressed), SPX (Spectrum Extended) und SPS (smooshed). Ich beschränke mich hier auf SPC-Files, das sind auch die, die einem am häufigsten unter die Finger kommen.

Ein komprimiertes Spectrum 512 - File ist folgendermaßen aufgebaut:

Tabelle 1: SPC - Format einer komprimierten Spectrum-512-Datei

1 Word	Kennung ($5350 oder "SP")
1 Word	für Zukünftige Erweiterung reserviert (bisher immer 0)
1 Long	Länge der Bilddaten
1 Long	Länge der Palettendaten
<=32092	Bytes komprimierte Bilddaten
<=17910	Bytes komprimierte Palettendaten

Die Kennung eines SPC-Bildes befindet sich also in den ersten 2 Bytes der Datei. Diese sind "SP" - das macht eine Identifikation natürlich nicht ganz einfach, da genau diese Bytes u.U. auch in anderen Bildformaten vorkommen könnten. Bei der Interpretation von Bildformaten mit einer so kleinen Kennung ist es deshalb besser, noch die eine oder andere "Plausibilitätsprüfung" vorzunehmen, z.B. kann die Länge eines SPC-Bildes nicht über 50014 Bytes steigen.

Die Grafikdaten, die sich ab Byte 12 in der Datei befinden, sind mit einer einfachen RLE (Run Length Encoding) komprimiert. Bei diesem Komprimierungsverfahren, wir erinnern uns, werden sich wiederholende Bytes komprimiert, indem sie durch eine Kennung, die Anzahl der Wiederholungen, und einmal das zu wiederholende Byte ersetzt werden.

Die dekomprimierten Bilddaten liegen im Standardformat vor, das heißt, in vier Bitplanes, die im Speicher hintereinander liegen. Der eigentliche Wert eines Pixels ergibt sich aus den vier Bits der einzelnen Bitplanes, wobei das niederwertigste Bit im Pixelwert der im Speicher zuerst liegenden Bitplane zugeordnet ist - aber das hat Christian ja schon behandelt, also machen wir einfach weiter. Denn man ist damit natürlich immer noch nicht fertig, jetzt kommt erst die eigentliche Schwierigkeit dieses Formates: Die Palettendecodierung.

Die Paletten, die im Bild vorliegen, sind wieder, jede für sich, sozusagen komprimiert. "Sozusagen" deswegen, weil sich die Komprimierung darauf beschränkt, die schwarzen Palettenfarben auszusortieren. Am Anfang einer jeden Palette (es gibt 3 pro Bildschirmzeile, wir erinnern uns), die übrigens dort in der Datei liegen, wo man mit dem dekomprimieren der Bilddaten aufgehört hat, befindet sich ein Word (2 Bytes), das bitweise angibt, welche Palettenfarben in der folgenden Palette enthalten sind. Ist ein Bit gesetzt, heißt das, die Farbe befindet sich in der Palette; ist es gelöscht, dann nicht. In diesem Fall ist laut der Spezifikation die Farbe auf Schwarz zu setzen. Das niederwertigste Bit dieses Kennwords steht für Palettenfarbe 0, das höchstwertige für Farbe 15. Beim Dekomprimieren sollte man gleich die drei Paletten einer Zeile zu je einer einzigen zusammenfassen, so daß man für jede Bildzeile eine Palette mit 48 Farben erhält. Dies ist relativ einfach, da die Paletten direkt hintereinander in der Datei liegen und vereinfacht den Zugriff.

Hat man die Farben also so dekomprimiert, gilt es noch herauszufinden, welche Palettenfarbe nun für welches Pixel im Bild zuständig ist. Man muß also nur herausfinden, an welcher X-Position im Bild welcher Index der 48-Farben-Palette für die jeweilige Zeile gilt. Hierzu gilt folgende Vorschrift:

(Es sei C der Wert des Pixels, dessen Palette ermittelt werden soll, und x seine X-Position in der Zeile):

x1=10*c

ist C ungerade?
  subtrahiere 5 von x1
ansonsten
  addiere 1 auf x1

ist  x>=x1 und  x<x1+160 ?
  addiere 16 auf C
ansonsten
  addiere 32 auf C

Das hört sich jetzt ein wenig nach "gehe nachts um zwölf beim dritten Vollmond auf eine Wiese und dreh dich fünfmal im Kreis" an, funktioniert aber. Danach ist C der gewünschte Palettenindex der Zeile und liegt zwischen 0 und 47.

So. Und jetzt stellt sich ein weiteres Problem: In den heutzutage gängigen Grafikmodi eigentlich aller Computer gibt es keinen Modus, der exakt 512 Farben, also 9 Bit Farbtiefe stellt. Man hat also prinzipiell die Möglichkeiten, das Bild auf 256 Farben zu reduzieren oder auf 16 Bit Farbtiefe aufzublasen. Ich favorisiere letztere Möglichkeit, da hierbei keine Qualitätsverluste entstehen - das Bild braucht dann zwar etwas mehr Speicher, verliert aber keine Farben.

Diverse Formate

Nun noch ein paar Formate, die zwar erwähnenswert, aber nicht interessant genug sind oder deren genaue Beschreibung einfach zu groß für diesen Artikel wäre:

Abschied?