Von Rainer Wiesenfeller und Olaf Piesche
Mittlerweise gibt es bereits zwei Preview-Versionen eines neuen Grafikkonverters namens "Smurf". Smurf wird von den Autoren als eines der schnellsten und vielseitigsten Grafikbearbeitungsprogramme angepriesen, das es auf dem TOS-Sektor gibt. Für die ATOS haben wir uns zusammen mit einem der Programmierer von Smurf, Olaf Piesche, einmal angesehen, was uns da zu erwarten hat.
Inhalt:
Die Oberfläche
Im- und Exportmodule
Bearbeitungsmodule
Die Modulschnittstelle
Das Interview
Außerdem hat Christian Eyrich, einer der Mitprogrammierer
des Smurf, uns noch einen netten Text zur Verfügung gestellt, den
er verfaßte, nachdem er versuchte, das Handbuch mittels der
Rechtschreibkorrektur von Word für Windows zu
"verbessern" ... Die Abenteuer des Grafikschlumpf
Doch nun zuerst zu "Smurf" ...
Dadurch, daß bei der Programmierung des Smurf keinerlei öffentliche Libraries zum Einsatz gelangt sind, ist die Oberfläche völlig ungewöhnlich gestaltet. Sie bietet bei vollem GEM-Komfort verschiedene Einstellungsmöglichkeiten, von "Normal", über "Abgefahren" bis "Therapy". Wenn Sie z.B. "Abgefahren" einstellen, sind die langweiligen Radiobuttons plötzlich kleine farbige Kugeln, die in Mulden liegen. Unter einem geeigneten AES sind alle Dialoge hintergrundbedienbar (AES > 3.2).
Es gibt im Smurf nicht einen einzigen modalen Dialog. Alle Dialoge kommen in Fenstern daher, was besonders für Benutzer eines multitasking-fähigen Betriebssystems wie z.B. ASH-MagiC oder N.AES besonders wichtig ist.
Nach dem Starten kann man sich neben einem Status-Fenster, das die fortlaufenden Aktionen (Dithern, Module) anzeigt, auch noch einen Bildmanager öffnen lassen, in dem alle momentan im Speicher befindlichen Bilder angewählt werden können. Bei Modulen, die mehr als ein Ausgangsbild benötigen, können diese bequem mittels Drag&Drop auf das entsprechende Modulfenster gezogen werden.
Kommen wir nun zu den einzelnen Bearbeitungsmöglichkeiten.
Smurf beherrscht über 60 verschiedene Grafikformate. Neben den bekanntesten wie GIF, IMG und TIFF auch solche wie Zeiss Bivas oder Kontron IBAS. Damit ist man mit dem Smurf wirklich für jeden Eventualfall gerüstet, zum Beispiel, wenn man Grafiken von einem anderen Computersystem bearbeiten möchte.
Eine vollständige Auflistung aller Smurf-Importmodule finden sich in der nachfolgenden Grafikformatliste.
In der Liste der Grafikformate befinden sich nur Importmodule, Exportmodule hat der Smurf ebenfalls, allerdings nicht in der Vielzahl. Momentan unterstützt werden die Formate GIF, IMG, TGA, PCX, Inshape Image (IIM) und True Paint Image (TPI). Weitere sind aber in Arbeit.
| 1st Publisher | .ART |
| Adex ChromaGraph | .IMG |
| Alpha Microsystems | .BMP |
| Amiga IFF/ILBM | .IFF, .LBM |
| Art Director | .ART |
| Atari PCP | .PCP |
| Atari Public Painter | .CMP |
| Atari Spectrum 512 | .SPC |
| Atari-Grafikformat | .PCP |
| Autologic Bitmap | .GM |
| CAS Fax | .DCX |
| Compuserve VIDTEX | .RLE |
| Cubicomp Picturemaker | .R8 |
| Degas | .PI1-.PI3, .PC1-.PC3 |
| Doodle | .DOO |
| Dr. Halo Import | .CUT + .PAL |
| EGA-Paint/Colorix | .RIX |
| ERDAS-Image | .LAN |
| Edsun Labs | .CEG |
| Enhanced Simplex | .ESM |
| Falcon | .XGA |
| Fontasy Bitmap | .BSG |
| GEM-IMG | .IMG |
| GIF | .GIF |
| GOES Satellite Bitmap | .GOE |
| HSI-File | .RAW |
| Highlight PC-Format | .PIC |
| IBM-Picturemaker | .PIC |
| Indypaint | .TRU |
| Inshape Images | .IIM |
| Kodak Photo CD | .PCD |
| Kontron IBAS | .IMG |
| MTV Raytracer | .MTV |
| Mac PICT 2 | .PIC |
| MacPaint | .MAC |
| Macintosh Giffer | .QDV |
| Microsoft Paint | .MSP |
| NASA-PDS Image | .IBG |
| NeoN Mapfile | .MAP |
| Neochrome | .NEO |
| OS/2 V1.x BMP | .BMP |
| OS/2 V2.x BMP | .BMP |
| PC-Paint/Picturepage | .PIC |
| Photoshop Document | .PSD |
| Portable Bitmap | .PPM |
| Q0 Japan Image File | .FAL |
| QRT Ray Tracer | .RAW |
| RIFF Bitmap | .RIF |
| Scodl File | .SCD |
| Silicon Graphics Image | .SGI |
| Stad | .PAC |
| Sun Rasterfile | .RAS |
| TIFF | .TIF |
| Targa | .TGA |
| True Paint Image | .TPI |
| Turbo Pascal Image | .TPI |
| Vivid Raytracer | .IMG |
| Windows BMP | .BMP |
| Windows Clipboard v | .CLP |
| Atari Icons | .ICN |
| X Bitmap | .XBM |
| ZSoft Paintbrush | .PCX |
| Zeiss Bivas | .DTA |
Eine besondere Stärke des Smurf liegt in der großen Zahl der verfügbaren Bearbeitungsmodule. Neben den "Standard"-Modulen, die ein Grafikbearbeitungsprogramm einfach beherrschen muß, gibt es einige Module, die in ihrer Art sicherlich neuartig sind und zu denen wir hier ein paar Beispiele zeigen wollen:
weitere Module:
Dieses Modul ist dazu geeignet, Bilder mit einem einfarbigen Hintergrund mit Schatten zu unterlegen. Dieses Modul kam bereits in einigen meiner Hypertexte zum Einsatz (CATalog, Termitenhügel). Ein Beispiel haben wir natürlich auch hier parat:
Wenn Sie ein Freund von Desktopkacheln sind, werden Sie an diesem Modul Ihre helle Freude haben. Haben Sie sich noch nie geärgert, wenn Sie eine schöne Grafik hatten, die Sie als Kachel einsetzen wollten, aber nach dem Laden waren überall die störenden Kanten zu sehen?
Edge-O-Kill sorgt dafür, daß die Kanten eines beliebigen Bildes ineinander übergeblendet werden, so daß hinterher beim Kacheln eine durchgehende Fläche ohne störende Kanten zu sehen ist.
Hinter diesem mysteriösen Namen verbirgt sich ein tolles Modul. Es erzeugt aus zwei Bildern ein neues Bild, das an Resultate erinnert, die man sonst nur aus Rendering-Programmen (NeoN, InShape) kennt.
Im vorliegenden Beispiel wurde ein Strudelbild mit einer Marmorfläche kombiniert:
Das Ergebnis:
Dieses Strudelmodul kennt die besondere Fähigkeit, bei Strudeln die Bildrändern mitzubearbeiten, sodaß das gesamte Bild verstrudelt wird. Außerdem kann man noch einen speziellen Tunneleffekt erzeugen:
Beispiel 1:
Beispiel 2:
Ein freier Filter in einer 5*5 Matrix ermöglicht verschiedenste Bildmanipulationen. Dieses Modul kann Filtermatrizen von DA's Picture laden und später auch wieder speichern. Dadurch stehen sofort hunderte von Filtern zur Verfügung.
Viele Computeranwender haben sie im Laufe ihrer "Computerkarriere" kennen- und liebengelernt: die Apfelmännchen. Auch Smurf bietet ein Modul zum Erzeugen solcher Fraktalbilder der Mandelbrotmenge. Hier ein Beispiel:
Als besonderes Schmankerl stellt Smurf auch noch einen Modplayer zur Verfügung, der allerdings nur auf einem Falcon zum Einsatz kommen kann. Mit ihm kann man während des Arbeitens mit Smurf seine Lieblingsmodfiles abspielen.
Die in Smurf integrierte Modulschnittstelle trägt den Namen Schlumpfine und bietet momentan folgende Features:
Es können bis zu 20 Bearbeitungsmodule gleichzeitig laufen. Die Module haben die Wahl, ob sie einen in Smurf eingebauten "Standarddialog" verwenden möchten, um ihre Parameter einstellen zu lassen, oder selbst eine GEM-Resource mitbringen und von Smurf in ein Fenster legen lassen möchtem. Auch im letzten Fall übernimmt Smurf das komplette Handling der Modulfenster inklusive Redraw.
Damit Module Dinge wie Schieberegler, Listenfelder u.ä. nicht selber mitbringen müssen, können und sollen (im Zuge einer Vereinheitlichung der Bedienung) hierfür Smurf-interne Funktionen genutzt werden. Wenn man grundlegende Programmierkenntnisse mitbringt, sollte das Programmieren eigener Module eigentlich kein Problem darstellen.
ATOS hat sich mit Olaf Piesche einmal unterhalten, wie das Projekt Smurf entstanden ist.
Olaf, bist Du der alleinige Programmierer von Smurf?
Nein. Ich glaube, da würde mich der Wahnsinn packen (was er auch so schon manchmal tut...). Neben mir programmieren noch Christian Eyrich und Dale Russel mit am Hauptprogramm und den Modulen, weitere Module werden auch von Jörg Dittmer und Andre Dietze entwickelt. Ich habe nur den Hauptteil des eigentlichen Smurf und einige Module übernommen.
Wie lange arbeitet ihr schon an dem Projekt, und wann ist mit einer Fertigstellung zu rechnen? Mittlerweile hat es ja bereits zwei Preview-Veröffentlichungen gegeben. Langsam werden die Leute neugierig ...
Dann haben wir ja genau das erreicht, was wir wollten ;-) Mit dem Projekt haben wir vor ca. 1 1/2 Jahren begonnen, als wir für unser erstes Demo ein TGA-Bild ins Falcon-16Bit-Format wandeln wollten. Dann kamen noch ein GIF-Importer und 8Bit-Export hinzu und schon hatten wir einen Grafikkonverter...
Die erste Previewversion war eigentlich ein Schnellschuß. Buggy bis dorthinaus und konnte noch fast nix. Ich hoffe, daß wir bisher ein wenig zeigen konnten, daß sich etwas getan hat. Wir wollen noch eine Previewversion veröffentlichen, die die Versionsnummer 0.9 tragen wird und voraussichtlich Anfang bis Mitte Februar released wird. Die Vollversion ist für Anfang April bis Mai geplant.
Smurf wird als kommerzielles Programm vertrieben werden. Warum glaubt ihr, daß auf dem Atari-Sektor da noch Bedarf besteht?
Wir haben natürlich überlegt, welche Distributionsform wir wählen können. Da aber dermaßen viel Arbeit in Smurf steckt, haben wir uns gegen eine Shareware-Lösung entschieden. Der Preis wird ja nicht viel höher als bei gängigen Shareware-Produkten liegen.
Bedarf an neuer Software, gerade im Grafikbereich, besteht wohl immer, auch auf dem Atari-Markt - Atari mag tot sein, die Software ist es noch lange nicht.
Einer der wesentlichen Gründe, die für den Schlumpf sprechen, ist seine hohe Bearbeitungsgeschwindigkeit. Kannst Du da etwas zu sagen, zum Beispiel im Vergleich zu anderen Konvertern auf dem PC- oder Mac-Sektor? Wird es eventuell auch Umsetzungen für andere Systeme geben?
Große Teile von Smurf (z.B. die Ditherroutinen und Teile vieler Module) sind in Assembler geschrieben, um höchstmögliche Performance zu erreichen. Wir liegen z.B. im Vergleich zu Photoshop auf dem Mac extrem gut im Rennen: die Graustufenwandlung von Smurf ist z.B. auf einem normalen Falcon genauso schnell wie die von Photoshop auf einem 66MHz-PowerMac. Im Vergleich zu anderen Grafikkonvertern auf dem Atari schneiden wir auch nicht schlecht ab, wir sind beim Laden und Dithern (auf 16 Farben, Fehlerdiffusion) z.B. 18mal so schnell wie das langsamste und 5mal so schnell wie das schnellste Grafikprogramm, das wir auf dem Atari finden konnten - und wir haben intensiv gesucht ...
In nicht allzuferner Zukunft nach dem Release der Atari-Version wollen wir uns auf eine Mac-Umsetzung stürzen. PC vielleicht auch noch, und mal sehen, was sonst noch kommt.
Smurf läuft also nicht nur auf einem Falcon?
Natürlich nicht. Smurf läuft, wie Du selbst feststellen kannst, inzwischen relativ stabil auf MagiCPC, außerdem auf MagiCMac, auf einem ST haben wir es auch getestet, außerdem auf 2 TTs mit und ohne Grafikkarten und einem Hades060. Diverse Bugs sind dabei natürlich nicht zu vermeiden, wir wollen aber natürlich dafür sorgen, daß die Vollversion bugfrei auf allen TOS-kompatiblen Rechnern läuft.
Euer umfassendes Wissen über die verschiedenen Grafikformate, die sicherlich Voraussetzung für ein solches Projekt ist, habt ihr euch ja unter anderem auch aus der Programmierung von Demos geholt. Unsere Leser wird es sicherlich freuen, daß ihr euch bereiterklärt habt, uns alle daran ein bißchen teilhaben zu lassen ...
Naja, das Wissen über Grafikformate an sich kam vielmehr mit der Programmierung von Smurf zu uns. Um Erfahrungen mit grafischen Effekten und der Bearbeitung von Bildern zu sammeln, kamen uns die Demos natürlich gerade recht. Als dann eure Anfrage kam, ob wir nicht eine Artikelserie für die ATOS schreiben wollen, wollten wir uns natürlich nicht lumpen lassen. Es wird wahrscheinlich ein drei- oder vierteiliger Artikel, der sich mit so ziemlich allem, was mit Grafiken zu tun hat, beschäftigt. Der erste Teil ist ja schon in dieser Ausgabe zu finden.
Darauf freuen wir uns schon jetzt und wünschen Euch viel Erfolg mit Eurem Schlumpf. Wir bedanken uns für das Gespräch.
Das Interview mit Olaf Piesche führte Rainer Wiesenfeller.
Olaf Piesche steht für Nachfragen zum Artikel, ebenso wie Christian Eyrich sicherlich bereit. Anfragen können entweder per e-mail an
MausNet: Olaf Piesche
| Sackpost: | Olaf Piesche |
| Beethovenstraße 1 | |
| 40822 Mettmann |
sowie
MausNet: Christian Eyrich
| Sackpost: | Christian Eyrich |
| Verdistraße 28 | |
| 90455 Nürnberg |
gerichtet werden.
Von Christian Eyrich
oder: Wie das Smurf-Handbuch von WinWord mißhandelt wurde ...
Nein.
Die Smurfdoku wurde nicht mit Word geschrieben. Aber in der Dienststelle steht nur ein PC - was kann ich dafür, wenn ich in der Arbeit am produktivsten bin?
Nunja, nachdem es jetzt schon kurz vor zwei ist, wollte ich mal kurz die Fehler des Tages korrigieren und aktivierte eben die Rechtschreibprüfung Words.
Ich weiß, es war ein Fehler. Es ist ja auch jene Rechtschreibprüfung, die nicht einmal "Microsoft" kennt.
Aber wie konnte ich auch ahnen, daß mir derart obszöne Vorschläge gemacht werden würden?
Noch ziemlich harmlos fing alles mit dem typisch microsoften Vorschlag, doch "KB" durch "GB" zu ersetzen, an. Hm, also gut, dann heißt es eben, "Smurf ist ein Grafikkonverter für TOS und läuft ab 512 GB freiem Speicher" eine ziemlich befremdliche Vorstellung.
Ach, ich hatte ja mitten im Satz mit der Korrektur angefangen, also von vorne.
Gut, nach der Korrektur des gesamten Satzes stimmt dann wieder alles, denn nun heißt es: "Sumpf ist ein Grafikkonverter für DOS und läuft ab 512 GB freiem Speicher." Das ist nett.
Weitere Ausschnitte gefällig?
Als ich bei der Bezeichnung für unseren lieben Freund Dale zwischen Ale (Schnapsdrossel) und Dame wählen durfte, hab' ich lieber "nicht ändern" angeklickt.
Zwar hält es Word wie wir bei unseren Programmiersessions und verhohnepipelt "Dithern" mit "Dietern", als "FS-Dichterling" möchte ich unser geliebtes FS-Dithering dann aber doch nicht hinstellen, denn der Dichter, der Dichter, der kriegt eins auf die Lichter.
Fast normal dürfte aber sein, daß M$ etwas gegen den Atari-Desktop hat, weshalb er aber gerade als "Atari-Despot" hingestellt wurde, ist mir wieder ein Rätsel.
Dank der Rechtschreibhilfe hat der Smurf, oder besser Sumpf, wie Words Kosename für unser Programm ja lautet, aber auch eine nette Erweiterung erfahren. Der Smurf liest jetzt nämlich "auch die gängigsten Lektor-, Rektor- und Sektorformate", wobei besonders letzteres hochinteressant, da das bisher nur Kopierprogrammen oder Festplattentreibern vorbehalten ist. Lieber wäre mir aber auch, wenn Smurf die Formate meiner Arztrezepte lesen könnte.
Ach ja, die gängigsten Vektorformate können nun leider nicht mehr gelesen werden, aber Ihr wißt ja, bei wem Ihr Euch bedanken dürft.
Vielseitig ist Word auch. Hervorragend lassen sich nämlich Lückentexte erzeugen, wenn alle unbekannten Worte aus dem Text gestrichen werden. Lückentexte mit seehhr vielen Textlücken.
Daß die Veröffentlichung neuer Smurf-Module nicht im Internet, sondern im "Internat" zu erfolgen hat ist ja wohl die Höhe. Die Höhe könnte aber auch der Flakon, 0,30 l sein, zu dem Word meinen Falcon030 gemacht hat. Oder waren es die harmlosen Bedienelemente, zu denen mir Word erklärte, es seien Dinge wie Furunkel oder Ödeme?
Rückblickend (ja, schon aus, denn ich muß nach Haus) läßt sich feststellen, daß ich zwar wie geschrieben die Fehler des Tages korrigieren lassen wollte, das aber genau der Fehler des Tages war.
Würde ich einen Testbericht für ein Magazin schreiben, wäre mein Urteil "Eine nette Spielerei für Pubertäre und Rätselfreunde, aber für Smurfanleitungen ungeeignet".
Aber immerhin kann ich mir nun vorstellen, weshalb von Bill Gates jetzt schon in verschiedenen Publikationen als der Erfinder von BASIC, wenn nicht sogar des PC, die Rede ist.
Das Grausamste, was man sich vorstellen kann ...
... ist, jemanden an die Rechtschreibhilfe WfWs zu setzen - er könnte sich totlachen.
Ich wollte wieder mal was zu lachen haben und habe es getan, ich drückte F7 - die Rechtschreibhilfe.
Erinnert Ihr euch an die zu Lektor- und Rektorformaten gewordenen Vektorformate (ich vergaß, mußte ich gerade sehen, den Vorschlag 'Viktor')? Die Rechtschreibhilfe kommt also an den Ausschnitt "gängigsten Lektor-, Rektor-[...]", der ist jetzt nämlich als Zitat in der Doku, und meint (ich brauche einen Snapshot, sonst glaubt mir das keiner): "Nicht im Wörterbuch: Lektor. Ändern in: Lektor. Vorschläge: Lektor, Lektors." Gehirnbluten sag' ich nur.
Für meinen lange gedienten MegaSTE hatte Word nur den Kommentar "magerste" übrig - ich weiß das zu schätzen.
Außerdem fiel mir eine schon seit längerer Zeit bekannte Korrektur ein. Denn die Struktur heißt ja gar nicht Gargamel, nein, "Grabmale" ist das Wort.
Ein paar lichte Nanosekunden hatte Word allerdings, als es für Vobis das Wort "Phobie" parat hatte.
Gleich darauf wurde mir im Eifer des Gefechts allerdings auch vorgeschlagen, wir sollten keine Demos sondern "Deos" machen. Mir reicht's.
Im Einsatz war ja Word 6 - schade. Laut der Microsoft-Werbung in diversen Zeitschriften gibt es ja in Word 95 die von papyrus her bekannte AutoKorrektur während des Schreibens. Und diese "AutoKorrektur kennt mehr Tippfehler als je zuvor" - soso, das kann ja lustig werden.
Einen hab' ich noch. Der Smur..., äh Sumpf scheint Word nicht genau genug zu sein. Anstatt einen Konverter zu schreiben sollten wir nämlich "konkreter" werden - meint Word.
Weshalb konnte uns MS-Words Rechtschreibkorrektur immer so begeistern? Weshalb wurde die Smurf-Doku dadurch nur noch schlimmer?
Nach langjähriger Forschung konnten wir nun einen Blick auf die Ursache werfen. Der Trick ist ganz einfach, wir brauchen nur das Wort Duden zu schreiben und es der Rechtschreibkorrektur vorzuwerfen. Das Ergebnis:
| Unbekannt: | Duden |
| Vorschläge: | Dudeln |
| Dudel | |
| Dulden | |
| Duzen | |
| Budeln | |
| Juden | |
| Luden |