Bildkonverter - Kunst der Verwandlung

Fast alle paar Wochen erblickt ein weiteres Grafikprogramm das Licht der Händlerregale. Selbst wenn man glauben mag, daß der Reigen der bildverarbeitenden Software längst komplett sein sollte, gibt es plötzlich einen neuen Font-Editor, ein neues DTP-Programm oder eine Scannersoftware mit Manipulationsteil.

Nichts gegen Neuentwicklungen und Programmverbesserungen, davon lebt schließlich eine expandierende Branche: und ein Großteil der Kreationen ist sicher sinnvoll und notwendig. Aber haben die Entwickler ihre Ideen in Konsequenz wahrhaftig bis zu Ende durchdacht?

Eigentlich ist man versucht zu glauben, Bild sei Bild.

Letztenendes macht es für die Bildinformation keinen Unterschied, ob ich das Konterfei meiner Tante Emma mit einer Praktika, einer Nikon oder einer Hasselblad fotografiere. Zugegeben, mit einer Hasselblad oder Mamiya werde ich wohl den Kontrast und die Vordergrundschärfe besser hinbekommen, aber meine Tante bleibt doch wohl auf allen Bildern meine Tante - oder? So sollte eine bestimmte, vordefinierte Grafik doch für das DTP-Programm auch nichts anderes sein als für x-beliebige Zeichen-Software oder Bildverarbeiter - sollte man meinen.

Streitfall

Wenn wir die Vielzahl an Programmen anschauen, die in irgendeiner Weise Bildinformationen zu verarbeiten in der Lage sind, und wenn wir uns zusätzlich noch die verschiedenen Dateiformate vor Augen halten, die diese Programme erzeugen können, wird einem angst und bange! Längst gibt es dicke Bücher [1,2], die nichts anderes tun, als alle möglichen Dateiformate aufzuzeigen und deren Unter schiede zu erklären. Alleine für den ATARI ST sind in [2] zur Zeit knapp über 100 unterstützte Grafikdateiformate registriert, und sie nehmen im Grunde mit jedem neuen Programm zu. Da stellt sich dem Computernormalanwender natürlich die Frage, ob ein solcher Formate-Wirrwar überhaupt sein muß und wozu er nur gut sein soll (außer zur Verärgerung der Anwender).

Auf der CeBIT ’89 hatte sich noch eine wackere Schar von ATARI-Programmierern um Händlerkollegen wie H. Richter, Gevelsberg geschart, um dem Formatechaos zunächst einmal nur für Textdateien Einhalt zu gebieten und verbindlich-freiwillige Standards zu setzen - leider ist es um das Häuflein Wackerer sehr still geworden. Wir möchten für heute in diesem Artikel die grundsätzliche Problematik nicht weiter ausdiskutieren. Warum es so viele Grafikdateiformate geben muß und welche Philosophie der Entwickler oder Geschäftspolitik der Vertreiber dahinter steht, diese Grundsatzproblematik der Computerbranche ausführlich zu behandeln, ist für eines der kommenden Hefte in einem angemesseneren Rahmen vorgesehen. Heute betrachten wir einige Programme, die uns helfen sollen/wollen/können. dem Durcheinander von Dateiformaten vielleicht ein Schnippchen zu schlagen - vielleicht.

Wandelbare Programme

Im Lateinischen gibt es das Wort „conversio“, was bedeutet: Umkehrung. Umwandlung, Übertritt. Laut Duden ist die Bedeutung des eingedeutschten Begriffes „Konversion“, der Übertritt eines Begriffes aus einer Sprache in eine andere, ohne dabei den formalen Inhalt, seine Bedeutung zu verlieren. Beispielsweise ist der Begriff „konvertierbar“ aus diesem Stammwort abgeleitet und bedeutet das Umwandeln oder Wechseln von einer Währung in eine andere, wobei der wirtschaftliche Wert der gleiche bleibt. Aus dieser Wortfamilie hat sich schließlich der „Konverter“ gebildet, der als Software auch nichts anderes tun soll, als irgendwelche Daten umzuwandeln. ohne deren Kerninformation zu verändern.

Man unterscheidet je nach Arbeitsweise verschiedene Gruppen von Konvertern, wobei es nicht unüblich ist, daß diese Programme die die folgenden Wandlungsprinzipien kombinieren:

1. Umwandlung der Dateiformate unter Beibehaltung der Bildbeschreibungsart (Pixel bleibt Pixel, Vektor bleibt Vektor);
2. Umsetzung der Dateiformate mit Änderung der Beschreibungsart (Pixel zu Vektor, Vektor zu Pixel);
3. Umwandlung von Farbbildern in Schwarzweiß oder umgekehrt, was z.B. typischerweise bei Scannersoftware angewandt wird:
4. Konvertierung in Abhängigkeit zur Bildschirmauflösung (typisch für Pixel-Konverter) oder im Gegenteil auflösungsunabhängig (typisch für Vektorgrafik);
5. Konvertierung in Abhängigkeit zur Auflösung des Datenträgers für Ein- und Ausgaben (z.B. von Scannern, Druckern oder Belichtern, Angabe in „dots per inch“ = dpi);
6. Umwandlung in Abhängigkeit zu dem benutzten Betriebssystem oder davon unabhängig, systemübergreifend;
7. Wandlerprogramme speziell für Zeichensätze (Fonts), evtl, unter Berücksichtigung bestimmter Treiberprogramme, die eigene Fonts anbieten oder verlangen (GDOS, FSM-GDOS u.ä.);
8. Wandlerprogramme mit zusätzlicher Komprimierung oder Entkomprimierung für Quell- und Zielformat (oft als zusätzliche Option eingebaut);
9. Konvertierung mit Aufspaltung in bzw. Zusammenlegung aus mehreren Einzeldateien.

Nicht verschwiegen werden soll, daß es eine stattliche Anzahl von Grafik- bzw. Bildmanipulationsprogrammen gibt, die u.a. mindestens eine kleine Auswahl der eben beschriebenen Konvertierungsprinzipien anzubieten haben. Leider geht die Konversion nicht direkt, sondern es muß oft die zu wandelnde Grafik erst auf den Bildschirm geladen werden, um sie in einem anderen Format speichern zu können.

TIP: Wenn Sie ohnehin die Anschaffung eines Bildmanipulators erwägen, prüfen Sie vorher, welche Bildformate Sie benötigen (wenn Sie bereits auf eine Bildbibliothek zurückgreifen können, oder z.B. systemübergreifend arbeiten müssen) und ob das Programm diese beherrscht. Testberichte zu den Programmen finden Sie in der ST-COMPUTER: „Artis“ und „Retouche“ in Heft 1/92, „Repro Studio ST“ und „Type Art“ in Heft 12/91, „Cranach Studio“ in Heft 11/91, „Piccolo“ und „Arabesque“ in Heft 3/91 - um nur eine kleine Auswahl der bekanntesten Programme zu nennen.

Bevor wir uns aber dem Angebot von Konvertern zuwenden. Programmen also, die nur zum Wandeln innerhalb verschiedener Dateiformate gedacht sind, müssen wir noch ein paar Grundlagen aufbereiten, die mit dem ersten Grafikprogramm und damit mit dem ersten Dateistandard für den ATARI ST beginnen.

Wie im Speicher = PIC

Das erste Malprogramm (siehe Bild 1) nannte sich DOODLE und wurde mit dem Start der ST-Geräteserie 1986 meist verschenkt. Dieses Programm ermöglichte ausschließlich das Zeichnen eines Bildes in der original Farbpalette. Es orientierte sich an dem damals fest vorgegebenen Bildschirmspeicher von 32000 Bytes. Gleichgültig ob nun dieses Doodle-Bild in der hohen (640 * 400 Bildpunkte, 2 Farben - nämlich Schwarz und Weiß), mittleren (640 * 200, 4 Farben) oder niederen (320 * 200, 16 Farben) Auflösungsstufe des ST entstanden war, es wurde einfach der komplette Bildschirminhalt abgespeichert. Man mußte also durch Ausprobieren feststellen, in welcher Auflösungsstufe das Bild entstand und wieder darstellbar sein würde.

Kurz darauf kam das Programm NEOCHROM auf den Markt, das zwar auch den Inhalt des Bildschirmspeichers direkt, aber zusätzlich noch eine 32-Byte-Farbpalette festhielt. NEOCHROM konnte nur die niedrigste Auflösungsstufe darstellen. Dann kam DEGAS, was neben einer zweiten Farbpalette für einfachste Animationen auch alle drei Auflösungsstufen bediente. In dem Programm ARTDIRECTOR beispielsweise standen schließlich 16 Farbpaletten für etwas ausgefeiltere Animationen, allerdings auch nur in der niedrigsten Auflösung, zu Verfügung. Sehr schön werden diese Zusammenhänge aus der Anfangszeit der Grafikformate in [6] beschrieben. Nachforschungen bei großen und bekannten Verlagen haben ergeben. daß sich Bücher zur Grafik Programmierung für den ST leider über die Grafikformate weitestgehend ausschweigen.

Alle diese Vertreter aus der ATARI-Historie hatten eines gemeinsam: sie speicherten die Bildinformation als sogenannte ‚Plane‘ oder Map’. Das bedeutet, daß jedem gesetzten Byte in der Datei ein gesetzter Punkt (Pixel) auf dem Bildschirm entspricht. Für jede Farbe gab es also eine zugeordnete Plane. In dem fest vorgegebenen Speicherraum von 32000 Byte konnte man also maximal 640 mal 400 Punkte darstellen.

ACHTUNG! Dummerweise gibt es in der MS-DOS-Welt auch ein „PIC“-Format, das beispielsweise von LOTUS 1-2-3 erzeugt wird. Es hat überhaupt nichts mit dem hier besprochenen ATARI-„Screen“-Format zu tun.

Zusammenrücken mit PAC

Sehr schnell hatte man erkannt, daß durch das authentische Abspeichern des kompletten Bildschirminhaltes viel Speicherplatz vergeudet wird. Bleiben z.B. große Passagen im selben Farbton, wird entsprechend die selbe Farbinformation mehrmals hintereinander in der Datei stehen. Wäre es nicht effektiver, einfach zu sagen die Farbe X kommt für die nächsten 50 Bildpunkte infrage, dann stehen 30 Punkte in der Farbe Y, gefolgt von 20 Punkten in der Farbe Z?

Genauso funktioniert das Komprimieren. Übrigens ist diese Vorgehensweise nicht nur auf Grafikdaten beschränkt. Packprogramme wie ARC, LH ARC, ZOO usw. nutzen dies für beliebig aufgebaute Dateien. Selbst die zeilenweise Übertragung beim Telefax nutzt solche Packalgorithmen (z.B. nach dem Modified Huffman-Code). Natürlich ist es sehr einfach, den Bildspeicher nach ähnlichen Byte-Folgen zu durchsuchen und diese codiert zusammenzufassen. Bei waagrechten Linien wird das auch problemlos funktionieren. Was aber tun, wenn das Bild viele senkrechte Linien aufzuweisen hat? Der Packalgorithmus kann nicht ohne weiteres erkennen, welche Bildpunkte zu einer senkrechten Linie gehören, um diese zusammenzufassen.

Wir sehen hieran schon sehr leicht, daß es auf ausgefeilte Komprimierstrategien und vielleicht auch auf die geschickte Kombination mehrerer ankommt. Eines sei aber verraten: Auf das Komprimieren allein kann ein Grafikprogramm nicht bauen, es kann nur in Ergänzung zu anderen Verfahren angewandt werden. Es ist aber leicht einzusehen, daß durch die Komprimierung die Größe der Datendatei abnehmen wird. Die Verfahren der Bildkomprimierung werden sehr anschaulich in [5] dargestellt. Fast alle Grafikprogramme für den ATARI ST bieten die alternative Komprimierung an (z.B. STAD PAC).

Wir werden uns in der Zeitschrift ST-COMPUTER bald noch ausführlicher mit Dateienpackern, also Komprimierern beschäftigen und dabei auch auf Komprimierverfahren der Grafikprogramme näher eingehen.

Zusammenfassen mit IFF

Ein anderes Prinzip stammt von der Firma Electronic Arts und wurde auf dem AMIGA zum ersten Mal in dem Programm Deluxe Paint angewandt. Dieses IFF-Format (bitte nicht mit „TIFF“ verwechseln!) wurde dann auf dem ST in DEGAS ELITE verwirklicht. Es faßt typische Eigenschaften eines Bildes zusammen und vermerkt dadurch nur noch dessen Charakteristik in sogenannten „Chunks“ (zu deutsch: Brocken oder Klumpen). So gibt es Chunks mit allgemeinen Informationen (Auflösung, Plane-Anzahl, Komprimierverfahren usw.), andere enthalten die Aussage über Farbpaletten, in weiteren Chunks sind die Bilddaten zusammengefaßt. Die Anzahl der Chunks, deren Reihenfolge und Vorhandensein in der Datei ist beliebig. Durch dieses Verfahren wird die Dateilänge sehr variabel und ist in der Hauptsache abhängig von der Anzahl der Merkmalsunterschiede im Bild. Das IFF-Format ist außerdem auch für Text, Animation oder Musik anwendbar. In [5] ist dieses Format extrem kurz erwähnt, ansonsten schweigt sich die ATARI-Literatur leider gänzlich darüber aus.

Verschlüsseln mit Befehlen

Ebenfalls in [5] sind einige Hinweise auf das „Hausformat“ der GEM-Oberfläche zu finden, das IMG-Format. Dieser Rasterbildtyp ist extrem flexibel, auf dem ATARI ST sehr häufig zu finden und kommt auf MS-DOSen (leider aber nicht kompatibel zu dem ST-IMG-Format) ähnlich verbreitet vor. IMG war lange Zeit ein Standardformat auf dem ATARI, obwohl es einige schwerwiegende Mängel aufzuweisen hat, so kann z.B. die Farbpalette nicht mitgespeichert werden. Abhilfe schafft das letztes Jahr geschaffene XIMG-Format, das nun auch die Farbpalette berücksichtigt.

Natürlich wird man sich weiterhin an dem Industriestandard messen müssen, auch wenn die dortigen Entwickler zu einer Art grafischem Benutzeroberfläche zurückgefunden haben. Die Standards der Grafikformate haben sich damit aber sinnigerweise weiterentwickelt. Ein Plädoyer für das TIFF-Format auf allen Systemen wurde bereits in [7] abgegeben. Eine ausführlichere Beschreibung der Grafikformate auf dem ATARI-Computer habe ich in [6] gefunden. Dennoch wird die Grafikwelt auf unserem Computer weiterhin mit unzähligen Dateiformaten überschüttet werden, den Anwendern zum Leid (!), den Programmierern zur Freud (?). Weitergehende Beschreibungen auch der neueren Dateiformate bleiben der Rubrik Programmierpraxis in der ST-COMPUTER vorbehalten.

Bitmap kontra Vektor

Ausgangspunkt für die verschiedenen Speicherungsformate war immer ein sogenanntes Punktbild (Raster. Bitmap), das im Grunde ein exaktes Abbild des Bildschirms war. Gerade aber der immense Speicherverbrauch zwang die Entwickler, sich nach anderen Bildbeschreibungsarten umzusehen, was ja mit dem eben betrachteten IFF- und IMG-Format bereits in Ansätzen geschah.

Der grobe Sprung geschah, als man von der Bildschirmorientierung über Beschreibungssequenzen bzw. Formatierbefehle zur Vektorisierung kam. Die programmtechnisch durchaus schwierige Wandlung von Bildpunkten in Vektorkoordinaten soll hier nicht unser Thema sein (siehe [9]), so soll aber das Grundprinzip doch kurz betrachtet werden.

Das Vektorisierungsprogramm tastet eine Bitmap, die vorzugsweise in echtem Schwarzweißkontrast vorliegen sollte (also ohne irgendwelche Graustufen oder ein Scanner unterdrückt Graustufen sowieso), nach den Konturen ab und merkt sich eine Unmenge an Punkten, die entlang der Grenzlinie Schwarz-nach-Weiß liegen. Die Farbe Schwarz wird einfach ausgeblendet, und nur die Punkte bleiben übrig. Nun verbindet das Programm die Punkte mit Linien. In einer weiteren Arbeitsphase versucht das Programm, die Menge an Punkten und Verbindungslinien zu verringern, ohne daß die typische Form bzw. die Kontur verlorengeht.

Wie arbeiten die Konverter?

Für die folgenden Betrachtungen stehen uns fünf Konverter aus neuester Produktion zur Verfügung (sicherlich gibt es noch mehr davon - die uns aber leider nicht zugänglich waren). Reine Punkt/Punkt Konverter sind CONVERT von ApiSoft, PICON von Softworld und GEMVIEW als Shareware von Dieter Fiebelkorn. An Vektor/Punkt-Wandlern liegen uns VEC-TO-MAP von ApiSoft und META-BIT als Shareware von Thomas Much vor. Vertreter aus der PD-Ecke wollen wir hier und heute nicht betrachten - das würde wohl den Rahmen sprengen. Ebenso bleiben die kompliziert arbeitenden Punkt/Vektor-Wandler unberücksichtigt, weil diese schon sehr ausführlich in [8] und [9] besprochen wurden. (Traut sich mal jemand eine umfassende Marktübersicht zu?)

Warum auch zwei Shareware-Produkte mitbetrachtet werden, fragen Sie? Lassen Sie mich hierzu kurz einen Kommentar abgeben: Nachdem ich die kommerziell vertriebenen Programme betrachtet hatte, wurden mir über die PD-Schiene zwei Shareware-Kandidaten zugespielt. Im Grunde haben deren Autoren nur den schnellen und billigen Verbreitungsweg „PD“ gewählt. Für eine dauerhafte Nutzung dieser Programme wird ein Obulus erwartet, der schon sehr nahe an die Kaufpreise der Kommerziellen heranreicht - deswegen mache ich keinen großen Unterschied zwischen Shareware und Kaufprodukt (es lebe der kleine Unterschied). Eigentlich bleibt uns die Arbeitsweise der Konverter größtenteils verborgen. Einige Programme teilen nach außen diverse Nachrichten mit, andere stürzen sich ans Werk ohne große Ankündigung. Bei den Punkt/Punkt-Wandlern ist es noch recht leicht einzusehen, daß die echten Bildinformationen nicht gewandelt werden müssen. Dort müssen nur die Zusatzinformationen (Kopfeintrag, Farbpalette usw.) auszuwerten sein. Bei den Vektor/Punkt-Konvertern wird es schon ein klein wenig schwieriger.

Oftmals schauen die Konverter noch nicht einmal in die Datei hinein, um bekannte Strukturen oder Schlüsselinformationen zu suchen. Es reicht einigen, einfach nur nach der Dateierweiterung (engl. „extension“) zu schauen, um zu entscheiden, ob es ein bekanntes oder fremdes Dateiformat ist. Viele Computernutzer kennen doch die Bedeutung der drei Buchstaben nach dem Dateinamen. Sie verkörpern gewissermaßen den Dateityp. der es Anwenderprogrammen leichter machen soll, die zutreffenden bzw. nutzbaren Datendateien voneinander zu unterscheiden. Es gibt schon eine stattliche Liste solcher Extensions, auch für das ATARI-Betriebssystem.

Punkt/Punkt-Konverter

Wenden wir uns nun etwas eingehender den drei Bitmap-Wandlern zu. So ist dieser Programmtyp weitestgehend dazu gedacht, Quasikopien des Bildschirms in der größtmöglichen Varianz einer Farbe (z.B. Schwarz mit Gegensatz Weiß), also monochrom, umzusetzen. Dabei tritt schon gleich das Hauptproblem auf, vor dem diese Programme stehen: die Größe dieser Quasikopie. Viele Programme arbeiten heute nicht mehr nur auf die echte Bildschirmgröße (640 * 400 Punkte) beschränkt. Dabei muß es nicht unbedingt ein Großbildschirm oder eine Grafikerweiterungskarte sein. Diese Programme täuschen einen größeren (virtuellen) Bildschirm vor, in dem mit der wahren Bildschirmgröße (als Ausschnitt) umhergerollt werden kann. Natürlich ist dann die spätere Grafik größer als der Bildschirm. So muß ein Punkt/Punkt-Wandler in der Lage sein, größere Grafiken auf Echtbildschirmgröße zu „splitten“ (aufzuteilen) oder mehrere solcher Bildschirmsequenzen zu einem Komplettbild zusammenzukombinieren.

Es gibt a) sogenannte „Block“-Formate, die nur Bildschirmteile berücksichtigen (DEGAS-Block, GFA-Get/Put-Block, STAD-Puffer, Omikron BIT), b) zwei füllbare Bildschirmgrößen untereinander (DRAW!, Profi Painter), c) mehrere Bildschirme untereinander (Artkraft) sowie d) unter- und nebeneinander (EasyDraw, Lavadraw, Public Painter) und frei wählbare, die nur vom Arbeitsspeicher abhängig sind (Arabesque, Mega Paint, diverse Scanner-Formate).

Wenn nun aber dem Punkt/Punkt-Wandler ein Farbbild angeboten wird? Es geht aus dem jeweiligen Dateikopf (engl. „header“) hervor, ob die Farbpaletten ausgenutzt wurden (siehe Bild 1). Dann muß der Konverter in der Lage sein, die Farbinformationen in Graustufen umzuwandeln.

Vektor/Bitmap-Konverter

Den kleinen Unterschied dieser zwei grundsätzlichen Bildbeschreibungsarten haben wir schon kennengelernt. Diese Wandlerprogramme sind hauptsächlich dazu erdacht worden, aus den vektorisierten Bildelementen Punktgrafiken herzustellen.

Wenn wir mit einem Grafikprogramm Linien oder Kreise zeichnen, sorgen Programmroutinen dafür, daß diese auf dem Bildschirm korrekt dargestellt werden. Es wird also aufgrund von Voreinstellungen (Größe, Liniendicke, Linienart usw.) beim Zeichnen die Ausdehnung. Musterung und Plazierung im Bild festgelegt. Diese charakteristischen Kennpunkte und Elemente speichert ein Vektorprogramm anders als die Bitmap und zwar in einer regelrechten Merkmalsliste. So stellen uns beispielsweise die Grafikprogramme und auch das Betriebssystem (mit VDI und GDOS) Routinen zum Zeichnen zur Verfügung. Eine „Metafile“, wie die Vektorprogramme sie anlegen. ist nun nichts anderes als eine Liste solcher standardisierten Befehle. Darauf greifen auch die Vektor/Bitmap-Konverter zu.

Wie testet man denn eigentlich Konverterprogramme?

Tja, mit dieser Frage habe ich gerechnet! Jetzt hätte ich ja irgend ein Bild nehmen und durch die Programme jagen können. Da hätten sich die kompliziertesten Dateiformate angeboten: Von IMG nach TIF, dann nach PIC und über IFF zu CRG und zurück? Und wenn das Bild am Schluß sich noch ähnlich sieht, dann wäre der Test bestanden? Nein. Im Grunde geht es doch gar nicht darum, ob ein Programm tausend verschiedene Formate, komprimiert und graustufengewandelt, beherrscht. Die breite Masse der Anwender wird doch wohl in den gängigen Formaten heimisch bleiben. Naja, das kann man durchaus testen und dabei hat keines der fünf Programme versagt.

Also doch kein richtiger Test? Wenn Sie jetzt irgendwelche Geschwindigkeitsmessungen erwarten, muß ich Sie leider enttäuschen. Die Konverter haben ihre Arbeit redlich erledigt. Aber einen Test kann es trotzdem geben: Wie ist die Benutzerführung, sind die gängigsten Formate (auch systemübergreifend) vorhanden, wie sieht das Handbuch aus und vor allem - der Preis?

CONVERT (ApiSoft)

CONVERT kann die stattliche Anzahl von 82 verschiedenen Formaten laden. Neben dem reinen Konvertieren lädt es auch Sequenzen, dreht diese auf Wunsch, speichert in einem Puffer zwischen und stellt einen Arbeitsbildschirm mit Fadenkreuz für kleinere Ausschnitte zur Verfügung. Alle Bildparameter (Größe, Auflösung u.ä.) sind individuell änderbar. Ausschnitte sind dann in STAD, Screen, Degas, IMG. TIFF (für MAC), PCX (für PC) oder als Signum-Dokument (warum auch immer) speicherbar. Im Programmteil Toolbox sind dann weitergehende Manipulationen, wie Radieren, Spiegeln, Invertieren möglich.

CONVERT wird mit einem 20seitigen Handbüchlein geliefert, das die Vorgehensweise befriedigend beschreibt und auch in Ansätzen auf die Theorie der Grafikformate eingeht. Dort habe ich gelesen, daß sogenannte 8-Bit/256-Graustufen-Bilder in Größen zwischen 100% und 1600% in einem Ordered-Dither-Raster dargestellt werden. Was dabei aber passiert, warum das nötig ist und was dahinter steckt, das habe ich leider nicht erfahren. Da wären ein paar Seiten Erklärung, vielleicht mit Bildern, recht nützlich gewesen.

Das Programm war 95,- DM das teuerste - und das meine ich auch so. CONVERT kann zwar wirklich viel und macht einen ausgereiften Eindruck, aber die Preislage reicht schon fast an Grafikprogramme heran, die ja auch, zwar über Umwege konvertieren können, aber u.a. wesentlich mehr Zeichenfunktionen zu bieten haben. Vielleicht sollte man mit dem Preis doch noch etwas tiefer gehen.

PICON (Softworld)

Der nächste Punkt/Punkt-Wandler importiert 22 verschiedene Formate und speichert in PAC, IMG, TIF, PIC, PI3 und BMP für Windows. Damit ist der Übergang zu anderen Systemen gewährleistet. PICON ist als reiner Konvertierer zu betrachten. Das spiegelt sich vor allem in zwei Punkten:

Die Größe des Bildes ist nicht individuell einstellbar und richtet sich immer nach der Quelldatei. Die Bilder können während der Konvertierung sichtbar gemacht werden, aber Ausschnitte daraus zu extrahieren. ist nicht möglich. Dafür wandelt es Farbbilder automatisch in Grau werte, splittet ein Bild in mehrere Dateien oder sogar auf mehrere Disketten.

Das „Handheftchen“ im Format DIN A6 mit seinen winzigen 20 Seiten steht einem Kommerzprodukt nicht sehr gut zu Gesicht. Es beschreibt zwar alle Arbeitsscheue ausreichend, geht aber selten auf die Theorie ein. Die Dialogboxen sind dort pflichtgemäß abgebildet. Der Preis von DM 89,- ist u.a. auch aus denselben Gründen wie bei CONVERT viel zu hoch angesetzt.

GEMVIEW (Dieter Fiebelkorn)

Das Shareware-Produkt versteht sich mit 16 Formaten, unter denen so „exotische“ wie SUN Rasterfiles, OS/2-Bitmap, SPECTRUM 512 und X-Bitmap (für UNIX-Workstations) zu finden waren. Damit dürfte ein Programm vorliegen, das die meisten, nämlich 7, Fremdbetriebssysteme ansprechen kann. Speichern kann es allerdings nur im IMG-Format auf dem ATARI (logisch).

Gut gefallen hat mir die echte GEM-Oberfläche, wobei mich der englische Menütext störte. Ein Text-File mit knappen 1300 Zeilen beschreibt zwar alles Wichtige zum Programm, schweigt sich über Allgemeines zu Grafikformaten leider gänzlich aus. Als „Teilnahmegebühr“ werden DM 30,- vorgeschlagen, und für weitere DM 40,- gibt es ein Update mit durchaus interessanten Neuerungen. Beispiel:

Auslagern von Identifizierungs-, Lade- und Speicherroutinen in externe Module und Freigabe der Datenstrukturen (mit einem vernünftigen und vor allen Dingen ausführlichen Handbuch dazu eine bemerkenswerte Sache). Trotzdem empfinde ich die dann aufgelaufenen DM 70,- für zu teuer. Will der Autor etwa einen kommerziellen Vertrieb mit allen Rechten und Pflichten umgehen?

Das Programm hätte eine sicherere Plattform als Ausgangsbasis für Weiterentwicklungen verdient.

VEC-TO-MAP (ApiSoft)

Nun zum Vertreter der Vektor/Pixel-Wandler. Das Programm erzeugt aus GEM-Metafiles und HPGL-Dateien (werden von vielen CAD-Programmen unterstützt) IMG-Rastergrafik, die nur vom Arbeitsspeicher abhängig ist. GEM-Texte, Füllmuster sind abschaltbar, die Auflösung kann individuell gewählt werden. Ausschnitte können detailgenau betrachtet werden, ein Nachbearbeiten mit einfachem Zeichenwerkzeug ist nicht möglich.

Ein Handbuch mit 15 Seiten geht ausführlich auf die Arbeitsweise ein und erklärt GEM-Metafile- und HPGL-Befehle leider etwas knapp. Der Preis von DM 50,-erscheint mir gerade noch so unterhalb der Schmerzgrenze.

META-BIT (Thomas Much)

Diesem Shareware-Programm hat der Autor eine einwandfreie GEM-Oberfläche mitgegeben, von der sich die Entwickler der anderen Programme eine Scheibe hätten abschneiden können. META-BIT lädt nur im Metafile-Format, speichert dagegen in IMG, PCX (für PC), PIC, Degas und STAD. Eine interessante Option ist das gleichzeitige Wandeln in Graustufen. Ein Text-File mit Aspekten zur Formatetheorie erklärt die Bedienung recht akzeptabel. Der Autor wünscht einen freiwilligen Obulus von DM 50,- und verspricht dafür ein ausführliches, gedrucktes Handbuch und die neueste Programmversion. Dieser Shareware-Beitrag liegt auch hart an der Grenze des Vertretbaren.

Bevor ich nun geh’

Ja, Sie haben recht, ein richtiger Test ist es wohl doch nicht so ganz geworden. Das Thema ist auch sehr schwierig gewesen, weil man bei den Programmen nicht sehr viel bei der Arbeit zusehen kann und auch auf dem Bildschirm nicht so viel passiert. Die Programme funktionieren halt, und das war die Hauptsache. Nun muß jeder Anwender für sich selbst entscheiden, welches dieser Programme ihm zusagt.

Grundsätzlich gilt festzuhalten: Alle Programme waren für mein Gefühl etwas überteuert. Die beiden Shareware-Programme sollten nach einigen Neuerungen durchaus den Weg zu einem kommerziellen Vertrieb finden, denn interessante Ansätze waren bei beiden zu finden. Erstaunlich ist, daß nur die beiden Shareware-Produkte eine echte GEM-Oberfläche zu bieten hatten.

Und noch grundsätzlicher fällt mein Schlußgedanke aus: Einmal ehrlich, mit wieviel verschiedenen Grafikformaten haben Sie denn täglich zu kämpfen? Zugegeben, der Markt für solche Programme ist sehr eng, danken wir es den Programmautoren, daß uns mit solcher Software die fremden Grafikwelten nicht verschlossen bleiben. Aber gerade diesen Programmautoren muß ich (pauschal) ins Stammbuch schreiben, sie sind ja auch schuld an der Formateverwirrung. Man setze sich an einen Tisch und bastele einen vernünftigen Standard! Der Worte hör ich wohl...

DK

Bezugsadressen:

KONVERTER
APi Soft
Andreas Pirner Software,
Bundesallee 56,
W-1000 Berlin 31.

SOFTWORLD
Stettener Weg 8
W-8221 Teisendorf

GEMVIEW & META-BIT
(siehe ST-PD 491)
MAXON Computer GmbH
Industriestraße 26
6236 Eschborn

Literatur:

[1] (BORN90) Born G., Das Dateiformate-Referenzhundbuch. Addison Wesley Bonn, München. ISBN 3-B9319-302-2

[2] N.N., Dateiformate ATARI ST(erscheint in Kürze)

[3] (HOGANHR) Hogan T.. Die PC-Referenz für Programmierer, Systhema Verlag München, ISBN 3-89390-250-3

[4] (JANK91) Jankowski u.a., ATARI ST Profibuch, Sybex Verlag Düsseldorf, ISBN 3-88745-563-0

[5] (ERNST91) Ernst Dr. H.. „Einf. digitale Bildverarb, Franzis Verlag München, ISBN3-7723-5682-6

[6] Höhn S. und Drücker J., „Bildung“, ST-COMPUTER 8-9/88, Seite 107 und Höhn. S., „Weiterbildung“, ST-COMPUTER 10/88, Seite 102

[7] Wiesler R., „Von ST zu TIFF-Grafik“, ST-COMPUTER 10/90, Seite 99

[8] Hollmann A., „Convector“ - Ein Programm zur automatischen Vektorisierung, ST-COMPUTER 4/91, Seite 20

[9] Brümmer I., „Der Bitmap auf der Spur“ - Vier Vektorisierungsprogrammen auf der Spur, ST-COMPUTER 6/91, Seite 16

---

---