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

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 erweiterba- 
ren Grundgerüst bestehen. Wie Module können einzelne Erweiterungen 
später noch angefügt und das Format ohne Probleme erweiterten Anforde- 
rungen gerecht werden. Manche sind sogar so flexibel, daß sie inter- 
pretiert 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. Aus- 
nahmen 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 Codebei- 
spiele 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 Informationsmo- 
dule nicht Tags, sondern Opcodes. In diesem Format jagt eine Design- 
schwäche die andere, das Format muß nicht gelesen, sondern interpre- 
tiert werden. Mac-Programmierer werden allerdings nur selten ein Wort 
über das Format verlieren (ob gut oder schlecht), dort macht das Be- 
triebssystem die Hauptarbeit.

Eine weitere Aufteilung läßt sich zum Beispiel dadurch erzielen, in 
dem die unkomprimierenden Formate in die eine Ecke und die komprimie- 
renden 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 Bilderaus- 
tausch 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 implemen- 
tieren 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 Un- 
terschieden. So ist dort mit Motorolaformat die Reihenfolge RGB 
gemeint, wohingegen bei Intel die Farben in der Reihenfolge BGR im 
Bild stehen.





Photo-CD