Dev

Bei Digitalfotografen derzeit sehr beliebt sind die so genannten High Dynamic Range-Fotografien. Durch einen Trick wird hierbei der Kontrastumfang einer Aufnahme stark erhöht. Details bleiben an hellen wie an dunklen Stellen sichtbar, wo sie bei einem normalen Foto sonst in sattes Weiß oder Schwarz übergehen.

Spiegel Online widmete dem Thema bereits mehrere Artikel - beeindruckende Fotostrecken mit Leserfotos inklusive. Eine weitere Galerie gibt es bei Chip Online . Wer Spaß an dem Hobby findet, kann sich auch verschiedenen Communities anschließen und sich mit anderen HDR-Fotografen austauschen.

Der Spaß ist nicht nur Windows-Anwendern vorbehalten. Wie man mit Linux zu seinen HDR-Fotos kommt, beschreibt dieses Special.

Was ist HDR-Fotografie?

Unsere Augen erlauben es uns, selbst an hellen Sommertagen Details im Himmel wie auch an dunklen, schattigen Stellen wahrzunehmen. Kameras sind dazu nicht in der Lage. Sie haben nur einen begrenzten Kontrastumfang, den sie darstellen können. Alles, was über diesen Bereich hinausgeht, wird nur noch als sattes Weiß oder Schwarz dargestellt, die Bilddetails gehen dort verloren.

Bei der HDR-Fotografie begegnet man diesem Problem mit einem Trick: Man nimmt vom gleichen Motiv mehrere Bilder in verschiedenen Belichtungsstufen auf. Auf den unterbelichteten Bildern bleiben helle Details erhalten, während auf den überbelichteten Bildern dunkle Details erhalten bleiben.

Eine spezielle Software setzt diese Bilder anschließend zu einem einzigen HDR-Bild zusammen. Durch den hohen Kontrastumfang des Bildes ist es allerdings auf herkömmliche Weise nicht mehr darstellbar - 16 Millionen Farben reichen dafür bei Weitem nicht aus.

Um das Bild wieder darstellbar zu machen, wandelt man es mit einem tonemapping genannten Verfahren in ein LDR-Bild (Low Dynamic Range, zum Beispiel eine JPEG-Datei) zurück. Die Software bewertet dafür jede Stelle der HDR-Vorlage einzeln und ändert die Belichtung punktuell so ab, dass alle Details wiedergegeben werden. So wird die große Dynamik, die die HDR-Vorlage hergab, in ein gewöhnliches Bild “gepresst”. Im Ergebnis sind dann die Details an hellen wie an dunklen Stellen sichtbar. Diese Bilder üben auf den Betrachter einen ganz besonderen Reiz aus, obwohl (oder gerade weil) sie unnatürlich aussehen.

Die Ausrüstung

Um HDR-Bilder anzufertigen, braucht man keine teure Ausrüstung. Fast alle einfachen Digitalknipsen der unteren Preisklasse bieten bereits eine zumindest rudimentäre Belichtungssteuerung, die für die ersten Schritte ausreicht. Da man das gleiche Motiv mehrfach fotografiert, wird man allerdings um ein Stativ nicht herumkommen. Sehr hilfreich ist auch ein Fernauslöser.

Gute HDR-Bilder lassen sich nur mit Digitalkameras ab der Mittelklasse machen, die eine manuelle Belichtung (also die manuelle Auswahl von Blende und Belichtungszeit) erlauben. Hilfreich in manchen Situationen, aber keine Voraussetzung ist es außerdem, Belichtungsreihen anfertigen zu können oder die Bilder im RAW-Format auf der Speicherkarte abspeichern zu können.

Das Motiv und die Aufnahme

Um die Vorzüge von HDR-Aufnahmen voll ausspielen zu können, braucht man zunächst mal eines: Ein Motiv mit einem hohen Kontrastumfang. Das können Außenaufnahmen von Gebäuden bei leicht bewölktem Himmel sein, wo die Wolken genauso detailreich zu sehen sein sollen wie im Schatten liegende Gebäudeteile. Beliebt sind auch Innenaufnahmen zum Beispiel von Kirchen, wo bei herkömmlicher Aufnahmetechnik die Fenster meist nur als blendend weiße homogene Fläche erscheinen. Vielleicht nicht ganz so nahe liegend sind Nachtaufnahmen, wo einerseits die Landschaft im Dunkeln liegt, andererseits aber Scheinwerfer, Reklametafeln oder Straßenlaternen ein helles Licht abgeben. Hier ist die Kamera im Vorteil gegenüber dem menschlichen Auge, das im Dunkeln weniger wahrnimmt.

Da mehrere Bilder angefertigt werden, darf sich das Motiv möglichst nicht bewegen. Bereits kleine Bewegungen (wie etwa Blätter eines Baumes im Wind) können später auf dem HDR-Bild als Geisterbild wahrgenommen werden. Eine HDR-Aufnahme von Menschen und Tieren ist unter der Voraussetzung gar nicht möglich.

Die Aufnahme erfolgt mit der auf das Stativ montierten Kamera. Zur verwackelungsfreien Auslösung benutzt man einen Fernauslöser oder (notfalls) den Selbstauslöser. Wenn man zwischen den Aufnahmen Einstellungen an der Kamera vornimmt, sollte man darauf achten, sie dabei nicht zu bewegen.

Zur Vorbereitung sollten möglichst alle Automatiken abgeschaltet werden. Der Weißablgeich sollte auf die Lichtverhältnisse eingestellt werden, und statt einer automatischen ISO-Einstellung sollte ein fester ISO-Wert gewählt werden. Der Autofokus könnte zwischen den Aufnahmen die Schärfe verstellen und sollte deshalb ebenfalls abgeschaltet werden.

Nun werden die einzelnen Bilder aufgenommen. Es sollten mindestens drei Bilder sein, wovon eines normal belichtet ist und die weiteren entsprechend stark unter- und überbelichtet sind. Im einfachsten Fall geschieht dies über die Belichtungskorrektur oder eine Belichtungsreihe.

Besser ist es aber, die Kamera auf manuelle Belichtung zu stellen, die gewünschte Blende auszuwählen und zunächst einmal die korrekte Belichtungszeit einzustellen. Von hier an kann man alleine durch Verstellen der Belichtungszeit alle notwendigen Bilder anfertigen.

Die Reihenfolge der Aufnahme spielt keine Rolle. Die Kamera legt die Belichtungsdaten im EXIF-Bereich der Bilder ab. Die HDR-Software liest diese Daten später aus und kann die Bilder dann entsprechend einordnen.

Die Software

Da HDR-Bilder per Definition eine sehr hohe Dynamik haben, ist eine Bearbeitung mit herkömmlichen Grafikprogrammen nur sehr eingeschränkt möglich. The GIMP zum Beispiel bietet derzeit nur 8 Bit pro Farbkanal und kann deshalb mit dem hohen Kontrastumfang nicht umgehen.

Anders sieht es schon mit CinePaint aus, einem GIMP-Ableger, der auf Foto- und Filmnachbearbeitung spezialisiert ist, und den es mittlerweile auch schon im Fedora-Repository gibt. Allerdings bietet Cinepaint bisher kein Tonemapping an, sondern kann nur aus den Vorlagefotos das HDR-Bild errechnen.

Qtpfsgui ist dagegen ein Programm, welches ausschließlich für HDR-Bilder gemacht wurde.

Nach der Installation des RPMs kann Qtpfsgui über den Menüeintrag Anwendungen → Grafik → Qtpfsgui gestartet werden. Das Programm gibt es momentan nur in Englisch.

Die Bedienung

Begonnen wird die Arbeit mit dem Erzeugen einer neuen HDR-Datei über den Button “New Hdr…”. In dem folgenden Dialog werden dann im ersten Schritt alle Vorlagebilder eingelesen, aus denen das HDR-Bild zusammengesetzt werden soll.

Über “Next >” gelangt man dann zum zweiten Schritt. Die voreingestellten Parameter können normalerweise so übernommen werden. Qtpfsgui bietet außerdem eine Option “Anti-ghosting” an, welche die Geisterbilder, die durch Bewegungen im Motiv entstanden sind, mehr oder weniger erfolgreich herausrechnen kann.

Ein erneuter Klick auf “Next >” erzeugt nun das HDR-Bild. Der Dialog kann mit “Finish” beendet werden.

Auf dem Monitor erscheint das HDR-Bild in einer speziellen Darstellungsweise. Da der Monitor nicht den kompletten Kontrastumfang wiedergeben kann, wird der Kontrast gestaucht. Das Histogramm über dem Bild gibt den dargestellten Kontrastbereich an und erlaubt es, mit der Maus einen anderen Bereich zur Dastellung auszuwählen. Man kann das Bild außerdem skalieren und drehen. Schließlich wird es über “Save Hdr as…” abgespeichert.

Als nächster Schritt wird nun das oben bereits erwähnte tonemapping vorgenommen. Dazu wird über “Tonemap the Hdr” ein neuer Dialog geöffnet. Auf der linken Seite des Dialogs lassen sich die Bildgröße, die Gammavorkorrektur, der Tonemap-Operator und dessen Parameter einstellen. Es stehen verschiedene Operatoren (“Fattal”, “Ashikhmin” usw.) zur Verfügung, welche über den entsprechenden Reiter ausgewählt werden und zum Teil sehr unterschiedliche Ergebnisse liefern. Mit “Apply” wird aus den aktuellen Einstellungen ein Bild errechnet.

Mit diesen Parametern kann man nun spielen, bis man ein schönes Bild erhält. Es gibt dafür keine Patentlösung. Entscheidend ist alleine der Geschmack und die Erfahrung des Anwenders. Das fertige Bild kann dann als LDR-Bild über “Save” in verschiedenen Formaten (für gewöhnlich JPEG oder verlustfrei als PNG) abgespeichert werden.

RAW-Bilder

Wie oben erwähnt, müssen für HDR-Fotos gewöhnlicherweise mehrere Bilder aufgenommen werden, wodurch sich bewegende Motive (zum Beispiel Personen) nicht fotografiert werden können. Unter einer bestimmten Voraussetzung geht es allerdings schon.

Digitalkameras der gehobenen Preisklasse bieten die Möglichkeit an, die Sensor-Rohdaten als RAW-Datei abzuspeichern. Der Sensor der Kamera verarbeitet einen höheren Kontrastumfang, als später im fertigen JPEG-Bild abgelegt wird. In der RAW-Datei gehen diese Informationen nicht verloren, wodurch solche Aufnahmen auch nachträglich am Computer um bis zu drei Stufen über- oder unterbelichtet werden können.

Und damit eignen sich RAW-Dateien ideal für HDR-Fotos. Der Vorteil liegt auf der Hand: Statt mehrere Fotos mit unterschiedlichen Belichtungen anzufertigen, braucht man nur noch ein einziges Foto - und kann so auch in schwierigen Situationen noch HDR-Bilder machen. Außerdem lassen sich RAW-Fotos aus dem Fotoarchiv in HDR-Bilder wandeln, wo man bei der Aufnahme noch gar nicht an diese Möglichkeit dachte.

Der Kontrastumfang einer RAW-Aufnahme kann sich allerdings nicht mit einer manuell belichteten Reihe messen. Bei meinen Tests wurde außerdem das Rauschen des Bildsensors erheblich verstärkt und fiel durch Pixelraster störend auf. Wenn möglich, sollte man also die manuelle Belichtung oder eine Kombination aus beidem bevorzugen.

Qtpfsgui kann übrigens die RAW-Bilder vieler Kameramodelle direkt einlesen, so dass eine vorherige Konvertierung entfällt.

Danksagungen

Danke an Jörg Hellmich für den Hinweis auf Qtpfsgui und die Inspiration zu diesem Artikel.

Die Fotos stammen von Dean S. Pemberton und wurden bei Wikipedia unter der Creative Commons License veröffentlicht: Bild 1, Bild 2.

Wenn man weite Landschaften wie Berge oder das Meer in einem Foto festhalten möchte, fertigt man normalerweise ein Panoramafotos an. Dazu braucht man keine teure Ausrüstung. Es reicht bereits eine handelsübliche, einfache Digitalkamera, eine Software und ein wenig theoretisches Wissen, um durchaus vorzeigbare Ergebnisse zu erzielen. Dieses Fedorablog-Special zeigt, wie es geht.

Ein wenig Theorie

Panoramafotos sind Bilder, die zu breit sind, um sie mit einem normalen Objektiv in einer Aufnahme aufzunehmen. Um sie trotzdem mit der Kamera zu erfassen, greift man zu einem simplen Trick: Man macht mehrere Fotos und schwenkt die Kamera dabei immer ein Stück weiter. Zuletzt setzt man die einzelnen Bilder dann zu einem großen Bild zusammen. Früher waren es noch Papierabzüge, die man mit Klebestreifen passend aneinander klebte. Heute macht man das natürlich digital mit Unterstützung vom Computer.

Die Qualität des späteren Panoramabildes hängt von der Qualität des Ausgangsmaterials ab. Die Fotos, die nachher bearbeitet werden sollen, müssen bereits möglichst gut geeignet sein. Der Computer kann zwar den einen oder anderen Fehler verstecken, aber je besser die Vorlage ist, desto besser ist nachher auch das Ergebnis.

Dabei hilft schon, auf möglichst viele Automatismen der Kamera zu verzichten. Der automatische Weißabgleich zum Beispiel kann dazu führen, dass die einzelnen Bilder die Farben unterschiedlich wiedergeben und das Gesamtbild dadurch auffällige, fließende Farbverläufe bekommt. Man sollte möglichst einen festen, zu den Lichtverhältnissen passenden Weißabgleichsmodus verwenden (zum Beispiel “Tageslicht”). Wenn man genügend Erfahrung hat, sollte man auch manuell belichten, damit die Einzelfotos gleich belichtet sind. Die Brennweite (der “Zoom”) darf natürlich erst recht nicht verstellt werden, wenn man mit der Bilderserie angefangen hat.

Wichtig, aber schwierig ist es, die Kamera nach jeder Einzelbildaufnahme richtig zu schwenken. Idealerweise bestimmt man dafür den so genannten Nodalpunkt, der von Kameramodell und Objektiv abhängig ist. Das erfordert nicht nur ein erfahrenes Auge, sondern auch ein Stativ mit einem speziellen und teuren Panoramakopf. Für den Hobbyfotografen ist das eher unerschwinglich.

Ein einfaches Stativ reicht für brauchbare Ergebnisse aber meistens schon aus. Man schwenkt einfach die Kamera Stück für Stück auf dem Stativ weiter und nimmt die Einzelfotos. Mit ein wenig Übung kann man sogar aus freier Hand ganz passable Panoramas schießen. Als Faustregel gilt, das Kameraobjektiv nur zu drehen, aber möglichst wenig zu bewegen. Es darf auch kein Objekt zu nahe an der Kamera stehen, da es sich sonst in den Einzelaufnahmen zum Hintergrund verschiebt und nachher ein nahtloses Zusammensetzen des Panoramas fast unmöglich macht.

Die einzelnen Bilder, die man aufnimmt, sollten sich stets gut überlappen. Das Folgebild sollte immer etwa die Hälfte des vorherigen Bildes beinhalten. Arbeitet man hier zu knapp, hat man später Verzerrungen und Abschattungen (Vignettierungen), die störend im Panoramabild auffallen können. Manche Kameras bieten dazu einen Panoramaassistenten, bei dem man immer eine Bildhälfte des zuletzt gemachten Bildes sieht und live das nächste Bild passend daran ansetzt.

Panoramafotografie ist ein Fotografie-Kapitel für sich. Weitere Details würden den Artikel sprengen. Am Ende gibt es aber noch ein paar weiterführende Links.

Stitching

Im nächsten Arbeitsschritt müssen die einzelnen Fotos zu einem Panoramabild zusammengesetzt werden. Man nennt diesen Vorgang stitching. Eine passende Software, die kürzlich in das Fedora-Repository aufgenommen wurde, ist Hugin. Diese wiederum benutzt Enblend, um die Einzelbilder schließlich zu einem Gesamtbild zusammenfügen.

Die Software ist mit yum schnell installiert:

yum install hugin enblend

Hugin kann anschließend unter Anwendungen > Grafik gestartet werden.

Im Prinzip ist die Bedienung der Software kinderleicht. Als erstes lädt man die einzelnen Bilder ein und bringt sie in die Reihenfolge, in der sie nachher zusammengesetzt werden sollen (meistens von links nach rechts). Wenn alle Bilder geladen und sortiert sind, wählt man das Ankerbild aus. Normalerweise ist es das mittlere Bild. Dieses wird mit “Positionsanker setzen” ausgewählt. In der Bildertabelle ist es in der Spalte Anker mit einem “A” markiert.

Danach folgt das Vernähen im Reiter “Kontrollpunkte”. Dort wählt man zuerst zwei benachbarte Bilder aus (zum Beispiel auf der linken Seite Bild 1 und auf der rechten Bild 2). Dann klickt man mit der Maus auf einen markanten Punkt eines Bildes (ein Gegenstand, eine Ecke, ein auffälliger Stein oder ähnliches), und wählt im anderen Bild den gleichen markanten Punkt aus. Es folgt eine Vergrößerung, in der man diese beiden Punkte nachjustieren kann; fast immer hat die Software aber schon die genaue Position selbst gefunden. Mit “Hinzufügen” kann dieses Punktepaar dann in die Liste aufgenommen werden. Man sieht danach wieder die beiden Vollbilder, bei denen das Punktepaar durch gleichfarbige Kreise markiert ist.

Auf diese Art müssen mehrere markante Punktpaare eingegeben werden; je mehr und je weiter über das gesamte Bild verteilt, desto besser das Endergebnis. Fünf Paare sollten es mindestens sein. Danach wählt man die nächsten zwei benachbarten Bilder (links Bild 2, rechts Bild 3) und fährt mit der Arbeit fort, bis man das vorletzte Bild mit dem letzten vernäht hat.

Die Arbeit ist damit schon fast geschafft. Als nächsten Arbeitsschritt lässt man Hugit die Punktpaare optimieren. Dazu wechselt man in den Reiter “Optimieren”, wählt dort in der “Optimieren”-Box den Eintrag “Alles” und klickt auf “Jetzt optimieren!”. Die Software rechnet nun kurz und präsentiert ein Ergebnis, das man übernehmen kann.

Es lohnt sich, jetzt einmal die Vorschau zu betrachten. Diese erreicht man über das Menü unter Ansehen > Vorschaufenster. Besonderes Augenmerk sollte man auf die Nahtstellen legen. Wenn dort Sprünge sichtbar sind, muss man zurück zu den “Kontrollpunken” und an den entsprechenden Stellen weitere Punktpaare einfügen.

Die Vorschau dient auch dazu, die Bildmitte und den Bildausschnitt festzulegen. Mit “Zentrieren” und “Einpassen” kriegt man bereits eine gute Vorlage. Allerdings sieht der Rand des Panoramas durch die Einzelbilder ein wenig bauchig und gezackt aus. Mit den Schiebern rechts von und unter der Vorschau kann man aber den Bildwinkel und damit den Ausschnitt verstellen und so zum Beispiel auch die Ränder entfernen.

Wenn die Vorschau nun das gewünschte Ergebnis liefert, werden im letzten Schritt die Bilder zu dem endgültigen Panoramabild zusammengefügt. Dazu wählt man den Reiter “Zusammenfügen”. Unter “Bilder zusammenfügen” kann man das Bildformat auswählen, zum Beispiel “in ein hochwertiges JPG-Bild”. Mit “Jetzt zusammenfügen!” wird dann die Panoramadatei erzeugt und abgespeichert. Das kann je nach Umfang der Bilder und der Geschwindigkeit des Rechners durchaus ein paar Minuten dauern.

Danach ist das Panoramafoto fertig! Es empfiehlt sich trotzdem, die Hugin-Projektdatie zu sichern, falls man nachträglich noch kleine Korrekturen vornehmen möchte.

Links

• Ein Workshop zur digitalen Panoramafotografie von digitalkamera.de
• Eine Anleitung, wie man den Nodalpunkt findet von digitalkamera.de
• Panoguide ist eine ganze Website, die sich alleine dem Thema Panoramafotografie widmet, allerdings in Englisch.

Dass die Computergenerationen immer leistungsfähiger werden, hat einen interessanten Nebeneffekt: Es ist dadurch möglich, dass ein moderner Computer einen alten Computer vollständig simuliert, Spezialhardware eingeschlossen. Man spricht dann davon, dass der alte Computer emuliert wird. Die dazugehörige Software heißt Emulator.

Dieses Special beschäftigt sich mit einer Auswahl der Emulatoren, die es für Fedora gibt.

Quelle

Ein paar Emulatoren stehen bereits in Fedora Extras oder im Freshrpms-Repository zur Verfügung. Die wahren Sahnestücke aber gibt es in dem eher unbekannten Dribble-Repository. Mit einem kleinen Handgriff wird yum das neue Repository bekannt gemacht:

rpm -ivh http://dribble.org.uk/repo/dribble-release-5-1.noarch.rpm

Als erstes sollte man sich nun ein Emulator-Menü in der Gnome-Startleiste anlegen:

yum install dribble-menus

Dort findet man dann alle Emulatoren, die man sich von Dribble installiert hat.

Das war bereits die Vorbereitung. Bevor ich nun die Emulatoren vorstelle, möchte ich noch einen kleinen Haken an der Sache ansprechen.

Woher mit der Firmware?

Ein Emulator stellt quasi nur eine virtuelle Hardware zur Verfügung, und ist damit nur die halbe Miete. Jeder Computer braucht eine Firmware oder ein Betriebssystem, so auch die Emulatoren, die für gewöhnlich eine Kopie des Original-ROMs benötigen. Hier macht jedoch meistens der Hersteller noch seine Urheberrechte geltend, so dass man sie nicht einfach zusammen mit dem Emulator verteilen kann.

Wenn man Glück hat, hat der Hersteller mittlerweile eine nicht kommerzielle Nutzung erlaubt. In Fedora darf die Firmware dann zwar immer noch nicht aufgenommen werden, da die Distribution strikt nur freie, quelloffene Software verwendet. Repositories wie Dribble bieten aber die Firmware an, wenn möglich. Das ist - wie gesagt - legal, da der Hersteller die Firmware für nicht kommerzielle Zwecke freigegeben hat.

Ist das nicht der Fall, gibt es eigentlich nur einen legalen Weg: Man muss das zu emulierende Gerät selbst im Original besitzen. Dann darf man die Firmware oder das Betriebssystem auslesen und auf dem Emulator verwenden, solange das Originalgerät weiter im Eigentum bleibt (und ganz streng genommen auch währenddessen nicht angeschaltet wird). Oft gibt es aber auch die Möglichkeit, die benötigten Dateien käuflich zu erwerben. Ein gewisses Restrisiko bleibt dann, weil man nicht weiß, ob und wie stabil der Emulator schließlich mit den Originaldateien arbeitet.

Eine dritte, etwas ungewöhnliche Möglichkeit ist, dass die Firmware quelloffen nachprogrammiert wurde. Das ist zum Beispiel der Fall beim Atari ST-Emulator, weshalb er auch in Fedora Extras zu finden ist.

Von Schwarzkopien sollte man dagegen absehen. Die Emulatoren werden von vielen Herstellern mit Argwohn beobachtet und mehr geduldet als gemocht. Wenn sie den Eindruck bekommen, dass dadurch ihre Rechte verletzt werden, könnte der Frieden schnell vorbei sein.

Jetzt aber genug der Theorie! Schauen wir uns ein paar Emulatoren näher an.

Apple Macintosh

Der erste Emulator ist schon ein Leckerbissen. Mit dem SheepShaver lässt sich ein Apple Macintosh emulieren. Unterstützt wird MacOS 7.5.2 bis 9.0.4, allerdings kein MacOS X. Installieren kann man ihn von Freshrpms per

yum --enablerepo=freshrpms install SheepShaver

Wer noch einen echten Mac Classic sein Eigen nennt, kann nun dessen Betriebssystem für den SheepShaver verwenden. Es ist vielleicht sogar möglich, die Festplatte des Originals in den Linux-PC einzubauen und zu benutzen. Es gibt aber auch die Möglichkeit, von Apple kostenlos die Installationsdateien für MacOS 7.5.3 herunterzuladen und zu installieren. Die Frage ist, wieviel man noch damit anfangen kann, denn MacOS 7.5.3 ist mittlerweile schon ziemlich betagt.

Der Name SheepShaver ist übrigens eine Verballhornung von ShapeShifter, dem ersten Software-Mac-Emulator für den Amiga.

Amiga

Apropos Amiga: Auch dieses klassische System lässt sich emulieren. Die Software dafür heißt UAE. Ursprünglich stand die Abkürzung für “Unusable Amiga Emulator”, und das nicht zu Unrecht, denn selbst sehr schnelle PCs reichten in den 1990ern nicht aus, um nur das Basismodell Amiga 500 mitsamt seiner komplexen Hardware in Echtzeit zu emulieren. Zwischenzeitlich hat sich aber viel getan, so dass heutzutage selbst ein durchschnittlicher PC einen schnelleren Amiga emuliert als das damalige Spitzenmodell mit 68060-Prozessor. UAE steht mittlerweile auch für “Ubiquitous Amiga Emulator”.

Installiert wird UAE aus dem Dribble-Repository per:

yum install e-uae

Auch hier fehlt das Betriebssystem, das so genannte Kickstart-ROM. Wer einen Amiga besitzt, kann mit Software aus dem Aminet selbst eine Kickstart-Datei erzeugen. Eine andere Möglichkeit ist, sich einen kommerziellen Amiga-Emulator zu besorgen, der die Kickstart-Datei enthalt. Meistens findet man die begehrte Datei aber auch auf Amiga-Spielesammlungen für den PC, die in vielen Software-Shops erhältlich sind. Die Sammlungen sind preiswerter und bringen außerdem gleich noch “Futter” für den Emulator mit.

Atari ST

Auch für den damaligen Erzrivalen des Amiga, dem Atari ST, gibt es einen Emulator. Er heißt hatari und steht sogar im Fedora Extras-Repository zur Verfügung:

yum install hatari

Als Betriebssystem kommt hier das quelloffene EmuTOS zum Einsatz. Damit ist hatari tatsächlich zu 100% Open Source.

Commodore C64 und seine Geschwister

Gleich eine ganze Armee von Emulatoren bringt vice, vom C64 und C128 bis hin zu ganz alten Schätzchen wie dem Commodore PET. Installiert wird vice aus dem Dribble-Repository per:

yum install vice

Leider scheint es aber ein Problem mit dem Sound zu geben; ich bekomme jedenfalls immer eine Fehlermeldung, dass alsa nicht ansprechbar ist. Gerade beim C64 mit seinem legendären Synthesizer-Chip SID ist das tragisch.

ZX Spectrum

Auch wenn der C64 zweifellos der populärste Heimcomputer der 1980er war, gab es noch Alternativen. Eine war der Sinclair ZX Spectrum. Natürlich gibt es auch dafür einen Emulator, genannt FUSE (Free Unix Spectrum Emulator). Der Emulator selbst liegt im Extras-Repository, allerdings ohne die notwendigen ROM-Dateien. Diese können vom Dribble-Repository nachinstalliert werden. Folgende Zeile installiert den kompletten Emulator mit ROMs und verschiedenen Tools:

yum install fuse-emulator fuse-emulator-roms fuse-emulator-utils

Emuliert werden verschiedene Modelle wie der ZX Spectrum 48k, der ZX Spectrum 128k oder die baugleichen Geräte von Timex und Pentagon.

MAME

Ein wahrer Spezialist unter den Emulatoren ist MAME, der Multiple Arcade Machine Emulator. Sinn dieser Software ist, Spielhallen-Computer zu emulieren. Eine nicht gerade leichte Aufgabe, denn sehr häufig wurde die Hardware des Geräts für das Spiel maßgeschneidert.

Der Emulator steht im Freshrpms-Repository und wird wie folgt installiert:

yum --enablerepo=freshrpms install gxmame xmame xmame-roms

Um mit MAME spielen zu können, braucht man die ROMs der Originalsysteme. Diese sind ziemlich schwer auf legalem Weg zu beschaffen, denn eigentlich muss man dazu das System (oder wenigstens dessen ROM-Bausteine) besitzen. Wenigstens drei Spiele, deren ROMs von den Eigentümern freigegeben wurden, werden mit dem xmame-roms-Paket mitinstalliert.

Weitere Emulatoren

Dribble bietet noch eine Vielzahl an weiteren Emulatoren, zum Beispiel für Gameboy, Gamecube, NES, Nintendo 64 oder für MSX-Homecomputer. Viel Spaß beim Ausprobieren!

Als ich eben las, dass der erste Netzbetreiber schon in Köln bezahlbare 100 Mbit-Leitungen für zu Hause anbietet, fielen mir meine ersten Schritte im Netz ein. Mein erstes Modem schob gerade mal 4 Kilobit pro Sekunde über die Kupferdoppelader. Es folgte kurz darauf ein (sündhaft teures) ZyXEL-Modem, das mit 19,2 kbit/s damals zu den schnellsten Modems überhaupt gehörte. Als ich dann ein paar Jahre später ISDN hatte und mit 64 kbit/s durch das Netz raste, fühlte ich mich wie ein König. Mein Umstieg auf DSL fing mit 768 kbit/s an. Lange Zeit war das schnell genug für mich. Mehr braucht kein normaler Mensch, dachte ich damals. Mittlerweile habe ich 18 Mbit/s und beneide bereits die 9000 Kölner, die eine solche 100 Mbit-Leitung haben können.

Und ich fragte mich, wie sich das Internet von heute mit den Geschwindigkeiten von damals anfühlen würde. Das war dann auch der Anstoß für diesen Artikel, denn Linux bringt schon seit geraumer Zeit serienmäßig die Fähigkeit des so genannten traffic shaping mit. Mit ein paar Handgriffen lässt sich die verfügbare Bandbreite ziemlich effektiv begrenzen und verteilen.

Der Bequemlichkeit halber habe ich per traffic shaping nur den eingehenden Datenverkehr gedrosselt. Das ist ausreichend, um beim normalen Surfen ein paar Nostalgiegefühle zu wecken. Mit folgenden zwei Befehlen (ausgeführt als root) wird der eingehende Datenverkehr auf 56 kbit/s begrenzt, was einem schnellen Analogmodem entspricht.

tc qdisc add dev eth0 handle ffff: ingress
tc filter add dev eth0 parent ffff: protocol ip prio 50 u32 match ip src 0.0.0.0/0 police \
  rate 56kbit burst 10k drop flowid :1

Nun wird flugs der Browser gestartet und sämtliche Caches gelöscht, wir wollen ja ein unverfälschtes Surferlebnis. 😁

Um dem Spuk ein Ende zu bereiten, reicht folgende Zeile aus:

tc qdisc del dev eth0 ingress

Das 56kbit kann durch andere Bandbreitenangaben ersetzt werden, zum Beispiel durch 64kbit für ISDN oder durch 4kbit für ein einfaches Analogmodem. Und wer es ganz abgefahren mag, simuliert mit 0.3kbit einen alten Akustikkoppler. Vor jeder Änderung muss das laufende Shaping über das zuletzt genannte Kommando zurückgesetzt werden. Und die Bandbreite des eigenen Anschlusses erhöhen kann man mit traffic shaping natürlich nicht. 😉

Übrigens: Die Fedora Core 6-DVD ist im Idealfall bei 100 Mbit/s in knapp 6 Minuten heruntergeladen. Bei 56 kbit/s braucht man dafür bereits über eine Woche, bei 4 kbit/s um die 100 Tage. Die DVD wäre dann fast schon veraltet, sobald sie fertig heruntergeladen ist.

Sun bietet verschiedene Zertifizierungen an, die die eigenen Fähigkeiten als Java-Entwickler in einem internationalen Maßstab bewerten sollen. Das “Sun Certified Java Developer”-Zertifikat bescheinigt, dass der Entwickler in der Lage ist, ein gegebenes Problem zu analysieren und unter Java-Standardtechniken daraus ein Programm zu entwickeln.

Voraussetzung für den Test ist das Bestehen des Sun Certified Java Programmers.

Dieser Test besteht nun aus zwei Teilen. Der erste Teil ist eine Aufgabe, die umgesetzt werden muss. Der zweite Teil besteht aus Fragen zu der eigenen Umsetzung.

Die gesamte Prüfung findet in englischer Sprache statt, wobei hier deutlich mehr verlangt wird, als nur einen englischen Text zu verstehen. Wer Probleme damit hat, längere Texte in Englisch zu verfassen, sollte sich das Geld besser gleich sparen. Das ist auch mein persönlicher Hauptkritikpunkt an der Prüfung. An sich sollte sie alleine die Fähigkeiten des Prüflings als Java-Softwareentwickler bewerten, aber zwangsläufig spielen so auch die Englischkenntnisse eine große Rolle in der Endnote. Englische Muttersprachler sind hier einfach im Vorteil.

Vorbereitung

Auch hier half mir die Complete Java 2 Certification Study Guide von Philip Heller (Sybex) weiter. Das Buch gibt wertvolle Tipps mit absoluter Prüfungsrelevanz. Ich empfehle außerdem die OOP-Pflichtlektüre schlechthin, die Entwurfsmuster von der berühmten Gang of Four.

Das schönste am ersten Teil der Prüfung ist aber, dass man ihn zu Hause und in aller Ruhe lösen kann!

Die Aufgabe

Nachdem man sich das Voucher für den ersten Teil gekauft hat, wird man in wenigen Tagen auf einer Test-Webseite freigeschaltet und kann sich sein Aufgabenpaket herunterladen. Es liefert die genaue Aufgabenstellung und vielleicht noch die eine oder andere dazu gehörende Datei.

Die Aufgabe ist klar und deutlich gestellt. Manche Bedingungen sind ausdrücklich ein must. Wer die nicht erfüllt, hat den ganzen Test nicht bestanden, und wenn der Rest der Lösung noch so gut ist. Es empfiehlt sich also, die Aufgabenstellung mehrmals und sehr gründlich durchzulesen. Die konkrete Aufgabe darf ich hier natürlich nicht wiedergeben, aber so viel kann ich sicherlich verraten: Ich sollte eine Swing-Applikation schreiben, die über das Netzwerk auf eine ebenfalls zu programmierende Datenbank zugreift.

Aus technischer Sicht ist diese Aufgabe für einen halbwegs routinierten Java-Entwickler problemlos zu meistern. Die Aufgabe stellte ein paar Einschränkungen, die zum Teil recht knifflig zu umgehen waren. Das ist durchaus Absicht, denn man soll auch seine Fähigkeit unter Beweis stellen, aus einer bereits bestehenden (und verkorksten) Teillösung noch das Beste herauszuholen.

Am Ende ein laufendes Programm zu haben, ist aber nur die halbe Miete. Es wird nämlich eine umfangreiche Dokumentation verlangt. Das fängt beim Quelltext an, der natürlich vernünftig formatiert, kommentiert und mit JavaDoc-Kommentaren versehen sein muss. Ebenso gehört eine kurze Benutzeranleitung dazu. Und schließlich soll man in einem Freitext schreiben, welche Probleme man bei der Umsetzung sah, wie man die Probleme löste und was für Alternativen es gab. Was ich abgab, bestand nur zu einem kleinen Teil aus Programmcode, die Dokumentation drumherum war weitaus umfangreicher.

Wenn man fertig ist, meldet man sich bei Sun, um Schreibrechte auf der Prüfungswebsite zu erhalten. Danach kann man dann sein Antwortpaket auf den Server hochladen. Man hat dabei nur einen Versuch! Wenn man auch nur eine Datei vergessen hat, muss man die (dann zum Glück ermäßigte) Prüfungsgebühr erneut bezahlen, bevor man das Paket ein zweites Mal hochladen darf.

Die Prüfung

Auf den ersten Teil folgt ein zweiter Teil, der ebenfalls absolviert werden muss. Im Gegensatz zu manchen Beschreibungen muss man nicht zuvor den ersten Teil bestanden haben. Die gesamte Prüfung wird erst dann bewertet, wenn der Prüfling beide Teile abgegeben hat. Deshalb sollte man so früh wie möglich nach Abgabe des ersten Teils einen Termin für den zweiten Teil machen, damit die eigene Lösung noch im Kopf präsent ist.

Auch für diese Prüfung muss man sich ein Voucher von Sun besorgen und mit einem Testcenter von Thomson Prometric einen Termin vereinbaren. Die Prüfung selbst dient eigentlich nur der Absicherung, dass man den ersten Teil auch selbst gelöst hat und nicht etwa nur abgeschrieben hat.

Man sitzt dafür an einem Computer und bekommt von ihm vier allgemeine Fragen zu der Umsetzung gestellt, die in einem Freitext beantwortet werden müssen. Dafür hat man insgesammt zwei Stunden Zeit.

Auch dieser Teil des Tests findet nur in Englisch und unter erschwerten Bedingungen statt. Ich tippe schon recht schnell englischen Text herunter und fand die zwei Stunden dennoch ein wenig knapp bemessen. Neben dem Zeitdruck kommt außerdem hinzu, dass keinerlei Hilfsmittel erlaubt sind, nicht einmal ein Englisch-Wörterbuch! Wer hier nicht halbwegs fit in Englisch ist, hat wohl kaum eine Chance.

Die Fragen selbst waren recht einfach und bargen wenig Überraschungen. Die Antworten hatte ich mehr oder weniger schon in der Dokumentation des ersten Teils gegeben, so dass ich sie einfach nur noch zu wiederholen brauchte. Wer sich auf den ersten Teil gründlich vorbereitet hat, braucht hier eigentlich nichts mehr zu befürchten. Wenigstens das…

Das Ergebnis

Beide Teile werden zusammen bewertet. Das heißt, der Prüfer bewertet einen erst, wenn beide Teile der Prüfung vorliegen. Das kann dann gute vier bis sechs Wochen dauern.

Die Fehlerquote ist recht gering bemessen: Von 400 möglichen Punkten muss man mindestens 320 erreicht haben, um zu bestehen. Vorausgesetzt natürlich, man patzt nicht gleich schon bei einer der must-Bedingungen.

Was es jetzt allerdings bedeutet, wenn man eine der Prüfungen nicht besteht, weiß ich nicht. Wenn man den ersten Teil nicht besteht, bekommt man die Chance, ihn gegen eine geringere Gebühr erneut einzureichen. Aber ob man dann auch den zweiten Teil wiederholen muss?