•  Back 
  •  Grafikformate, Teil 3 
  •  Index 
  •  Tree View 
  •  Cross references 
  •  ATOS Hilfe 
  •  Show info about hypertext 
  •  View a new file 
Topic       : ATOS-Magazin Juni/Juli 1997
Author      : Das ATOS-Team
Version     : 3/97 (2.6.1997)
Subject     : ATOS Diskettenmagazine
Nodes       : 319
Index Size  : 8070
HCP-Version : 5
Compiled on : Atari
@charset    : atarist
@lang       : 
@default    : 
@help       : ATOS Hilfe
@options    : -i -s +zz -t2
@width      : 70
@hostname   : CAB     
@hostname   : CAB     
@hostname   : CAB     
@hostname   : CAB     
@hostname   : CAB     
@hostname   : CAB     
View Ref-FileSpectrum 512 - Buntibunti...                     Das ATOS-Magazin 3/97

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 (Pro- 
grammunterbrechungen, 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 Farb- 
palette des ST-Grafikprozessors enthält 16 Farben, deren RGB-Komponen- 
ten 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 darge- 
stellt) 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 Gra- 
fikformates ist natürlich nicht so ganz einfach. Es gibt außerdem noch 
4 verschiedene Spectrum-512-Formate: SPU (uncompressed), SPC (compres- 
sed), 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:


   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 

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


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 Bildfor- 
maten 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 Kom- 
primierungsverfahren, wir erinnern uns, werden sich wiederholende 
Bytes komprimiert, indem sie durch eine Kennung, die Anzahl der Wie- 
derholungen, 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 eigent- 
liche 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 Komprimie- 
rung 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 be- 
findet 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 fol- 
gende 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, funktio- 
niert 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 prin- 
zipiell die Möglichkeiten, das Bild auf 256 Farben zu reduzieren oder 
auf 16 Bit Farbtiefe aufzublasen. Ich favorisiere letztere Möglich- 
keit, da hierbei keine Qualitätsverluste entstehen - das Bild braucht 
dann zwar etwas mehr Speicher, verliert aber keine Farben.





Diverse Formate