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-FileGEM-IMG                                          Das ATOS-Magazin 3/97

Das ist unser Format. Also nicht Olafs und meines, sondern des Atari- 
aners 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 Pro- 
grammen 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 zeilenwei- 
se 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 Com- 
pressed 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 aller- 
dings 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 Replica- 
tion 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 Bildda- 
ten 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 ent- 
scheidend von der beim Speichern aktiven abweichen.

Also gingen die Geißens daher und definierten, daß im XIMG eine Farb- 
palette 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 Pro- 
gramm auch nicht unterscheidbare) TC-IMGs. Das eine stammt vom Pro- 
gramm PixArt und ist vom Format her kompatibel zu den niedrigeren 
Farbtiefen, d.h. die 3 Bytes der Bilddaten sind auf 24 Planes ver- 
teilt. Das ist zwar konsequent, für ein TC-Format aber recht umständ- 
lich zu handlen.

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





Spectrum 512 - Buntibunti...