Bildinfos

Zitat von Rainer

Denk dran, maximal 32 Libraries sind möglich - und schummeln geht nicht. Includest du eine Library, die 31 weitere includet, bist du voll.
Rainer

Immer diese niedrigen Limits ! Wie soll man damit Warp-Antrieb oder Beamen erfinden?!

PS: Ich plane jetzt (noch) nicht, die 32 zu überschreiten, aber Du meintest ja mal, es dürfen maximal 32 verschiedene (!) Librarys sein, oder? Wenn also z.B. mehrere Librarys immer die gleichen Unterunter-Librarys einbinden und deren Gesamtzahl dann 32 überschreitet, geht es aber, wenn sie sich so oft doppeln, daß die Zahl der eindeutigen wieder unter 2^5 sinkt?

Hallo zusammen!

Nach einiger Zeit der Ruhe möchte ich mich mal zurückmelden und über den aktuellen Stand berichten.

• Da die aktuelle Version von Bildinfos aufgrund der Quellcode-Größe nicht mehr vernünftig handhabbar war, begann ich im April einen Umbau zu untersuchen, bei dem die Bildfunktionen in Bibliotheken ausgelagert werden. So würden mehrere kleinere Quellcode-Einheiten entstehen. Zudem wollte ich die Oberfläche umbauen, da die derzeitige provisorisch entstanden war und zu wenig Möglichkeiten bot, und die Größe der Bildfunktionen, die typischerweise bei ca. 1000 Zeilen liegt, verringern.
• Mir erschien es dann als der bessere Weg, das Programm und die Struktur neu aufzubauen als den bestehenden Code versuchen umzubauen. Also begann ich damit, eine neue Oberfläche zu entwerfen und diese umzusetzen. Bevor ich wieder der Knobelmagie neuer Formate erliege, wollte ich eine robuste Programmstruktur aufbauen, in die sich dann neue Komponenten einfach einklinken.
• Dann war ich jedoch für Wochen beruflich so ausgelastet, daß die Weiterentwicklung ruhte. Erst im Juli witterte ich wieder etwas freie Luft. Es wurde jedoch immer klarer, daß die neue Version noch sehr viel Zeit benötigen würde. Dabei erschien es mir bedauerlich, das aktuelle Bildinfos auf der Festplatte einsam verderben zu lassen. Es bietet ja viele Funktionen! Warum nicht veröffentlichen?
• Also führte ich einige Polierarbeiten durch: vervollständigte unfertige Funktionen, schrieb etwas Hilfetexte, malte ein Icon, übersetzte (teilweise) eine englische Version und erstellte eine Internet-Seite. Es fehlten also nur wenige Dekananometer bis zur Ziellinie – da suchte ich, um die Wartezeit zu überbrücken, leichtsinnigerweise (oder glücklicherweise?) nach unvollständiger Funktionalität. Und wurde fündig. Leider äußerst reichlich fündig. Dann begann ich also eifrig, die Lücken zu vermauern, und verschob die Veröffentlichung um wenige Tage.
• Dann kamen wieder andere Aufgaben und zwei Monate sind vergangen. Mein Ziel ist es jetzt, mir in den nächsten Wochen wieder etwas Zeit zu nehmen und dann, so Minerva will, Bildinfos 1 zum Geos-Treffen zu veröffentlichen.

Bis danne!

Also, Kinder der Sonne, die Zeit des Schlendrians schleicht sich hinfort, der Sprint hüpft schon in den Startlöchern. Das Fest des Großen Geos, im gewaltigen Tempel zu Syhra abgehalten, schiebt sich, zwischen Allerheiligen und den Adventus-Tagen gelegen, immer näher. Möchte ich mein besonders schönes Sacrificium Bildinfos auf den güldenen Altar legen, so muß ich nun eifrig dem Ruf der Schillerschen Glocke folgen: Frisch, Gesellen, seid zur Hand. Von der Stirne heiß rinnen muß der Schweiß.
Mag der Kern auch gut, nützlich und aus dem edelsten Erz gegossen sein, so fühlt er sich doch so wohlig und geschmeidig an wie ein wild wucherndes Brombeergestrüpp. Die Lage kann nur vergleichbar sein mit der Michelangelos, als er vor dem Block aus feinstem Marmor stand, der alles und in höchster Güte bereits enthielt. Es mußten nur noch die Ecken abgeschlagen und der erscheinende Rest poliert werden, damit die Figur des Davids ans Licht trat. Michelangelo hatte vier Jahre, vier Wochen sind mir gegeben.
Nun werde ich also die vielen losen Enden miteinander verweben, so daß Bildinfos in einem schönen Gewande präsentiert werden kann.
Wenn wieder ein ein Flicken kunstvoll eingewoben wurde, so werde ich ihn hier zeigen, so daß alle Zeuge der Vollendung werden können.
Und das sei schon verraten: am Ende folgt ein Knaller, ein Regenbogen samt Feuerwerk!
Vorwärts!

Und der erste Streich folgt sogleich!
Das historische Format PBM – Portable Bit Map – kann das Programm, zur Freude eines Herrn K., ja schon seit vorigem Dezember speichern. Ich hatte dann schon begonnen, die Schwesterformate PGM – Portable Gray Map – und PPM – Portable Pixel Map – , die zusammen die PNM-Familie – Portable Any Map - bilden, hinzuzufügen, verhedderte mich dann aber im Gestrüpp der Optionen und zog mich mit zerfetztem Hemde fluchend zurück.
Doch nun, mit frischer Kraft, gelang das kühne Unternehmen! Das Programm Bildinfos kann nun beliebige Geos-Bilder in einem passenden PNM-Format speichern:

• PBM speichert Schwarz-Weiß-Bilder, PGM Graubilder und PPM Farbbilder.
• Um das passende Format zu bestimmen, prüft das Programm, welchen Farbtyp das zu speichernde Bild besitzt. Das kann im schlechtesten Fall, z.B. bei einem Schwarz-Weiß-Bild mit 24 Bit Farbtiefe, bedeuten, daß das gesamte Bild durchlaufen, zeilenweise ins VRAM geladen und pixel-weise geprüft werden muß.
• Da die Formate keine Transparenz unterstützen, muß diese, sofern sie im Bild vorkommt, durch eine Farbe ersetzt werden. Diese kann das Ergebnis der Bildprüfung auf den Kopf stellen, wenn z.B. bei einem Schwarz-Weiß-Bild mit 1 Bit Farbtiefe, das sonst einfach nach PBM gewandelt werden würde, die transparenten Bildteile in Purpur dargestellt werden sollen. Dann ist ein PPM vonnöten.
• Das Programm wählt von den drei Formaten immer das kleinstmögliche aus. Das erwähnte Schwarz-Weiß-Bild mit 24 Bit Farbtiefe wird also als PBM gespeichert.
• In die berechnungszeitliche Optimierung habe ich einigen Aufwand gesteckt, um die Zahl der aufwendigen Bildprüfungen zu reduzieren. Wenn etwa als Transparenzersatz eine Farbe angegeben wurde, so muß PPM verwendet werden, das eigentliche Bild braucht nicht mehr geprüft zu werden. Auch erstellte ich eine lange, systematische Liste der Kombinationen aus zu speicherndem Bild, gewählten Optionen und gewünschtem Ergebnis, die ich dann abarbeitete. Das lohnte sich, denn es offenbarten sich einige Fehler und Optimierungsmöglichkeiten.

Anbei ein Abbild der Speichern-Optionen.

Genau, alles im wunderbaren R-Basic geschrieben. Gebrannt, angebrannt, verbrannt ist da noch nix, aber vielleicht sollte ich mal eine Datensicherung auf CD brennen?

Nachdem die drei älteren PNM-Kinder PBM, PGM und PPM nun sauber implementiert sind, wandte ich mich dem jüngeren Geschwister PAM zu. Das hatte ich ja vor einer Weile schon komplett umgesetzt, so daß hier nur ein kurzes Überfliegen des Codes notwendig wäre. Dachte ich. Doch der Mensch denkt, Gott lenkt. So fanden sich zwei größere Schnitzer und Graubilder wurden fehlerhaft kodiert. Zudem werden nun Schwarz-Weiß-Bilder mit 8 oder 24 Bit Farbtiefe korrekt als PAM-Schwarz-Weiß gespeichert. Dann noch die Hilfe für das Format geschrieben und schon wieder ist ein Punkt auf der Bis-Syhra-Liste abgehakt!

Der pure Wahnsinn! Über 100.000 Zugriffe hat diese kleine Artikelserie nun schon erhalten. Unglaublich! Vielen Dank für das Interesse.
Und ich frage mich, wie groß die heimliche Geos-Gemeinde abseits der Syhra-Gruppe wohl ist?

Tempus fugit – es ist einfach wahr. Der letzte Beitrag ist schon wieder fast einen Monat her, ein Monat, in dem mich wieder das Knallen der Nilpferdlederpeitsche in den dunkelsten Stollen trieb, wohin ich nicht für filigrane Geos-Arbeiten geschickt wurde. Aber dem Allerheiligen sei an Allerseelen Dank, mit dem freien Tag verschaffte er mir eine Atempause und so konnte ich endlich wieder ein Loch im Heiligen Teppich zu Syhra flicken, auf das er das kommende Fest schmücken möge.

Heute vollendete ich das vor einiger Zeit begonnene Format FilmLight32. Dieses ist ziemlich zu Recht ziemlich unbekannt und zudem ehrlicherweise noch unpraktischer als manch anderes Format, denn es wird nur intern in der britischen Firma FilmLight verwendet, die sich auf Software für die Filmproduktion spezialisiert hat. Aber genau dieser Exotenstatus reizte mich wohl. Zudem speichert es ungewöhnlicherweise die Bilddaten in einem 4-Byte-Gleitkomma-Format. Das ist selten und mit so einem Format hatte ich mich bislang nicht beschäftigt. Daher erschien mir FL32 wohl als Blaue Mauritius unter den Bildformaten. Und die Umsetzung entpuppte sich wirklich als spannendes Unterfangen:

• Bildinfos kann die Bildeigenschaften auslesen und das Bild anzeigen.
• Der Formataufbau ist sehr simpel, aber das Gleitkommaformat bildete das sphinxsche Rätsel, um an den Schatz zu gelangen. Mit R-Basic fand ich keine Lösung, dieses direkt einzulesen. Also liest das Programm die Daten als 4-Byte-Integer-Datentyp DWORD ein und zerlegt diesen dann in eine Gleitkommazahl, um jene wiederum zu einer reelen Zahl zusammenzubauen, die wiederum den prozentualen Anteil am jeweiligen Farbwert darstellt, womit letztlich der RGB-Wert ermittelt werden kann.
• Wem gerade spontan der Aufbau einer Gleitkommazahl entfallen ist, der hebe ihn hier wieder auf:
  
  
  • Eine binäre Gleitkommazahl wird in dieser Form dargestellt: 1,x * 2^n. Das Komma gleitet also so hin und her, bis die Zahl diese Form angenommen hat. Ein Beispiel in unserem Dezimalsystem könnte sein: 31.415 wird als 3,1415 * 10^4 dargestellt.
  • Die vier Byte der FL32-Gleitkommazahl bestehen aus Vorzeichen (1 Bit), Exponent (8 Bit) und Mantisse (23 Bit).
  • Als weitere Schmankerl werden zum Exponenten 127 addiert (so wird daraus eine positive Byte-Zahl) und von der Mantisse wird die Eins vor dem Komma nicht gespeichert, denn diese ist immer eine Eins. Die 23 Bit sind die 23 Nachkommastellen.
  • Rechnet man dies also also rückwärts und wieder zusammmen, kommt man auf eine Zahl zwischen Null und Eins. Dies ist der Anteil am Farbwertebereich, bei Geos von 0 bis 255. Bei Programmen mit 16 Bit Farbtiefe können es dann auch 65k Stufen pro Farbe werden.
  • Die Rechnerei verbraucht übrigens einige Ressourcen und Zeit. Zudem müssen die DWORD-Werte etwas umständlich zerlegt werden, weil in R-Basic die logischen Befehle AND, OR usw. nur mit WORDs arbeiten. Warum eigentlich? – Da bin ich nun schon ein paar Mal darüber gestrauchelt.
• Originellerweise existiert in freier Wildbahn nur ein einziges Beispielbild (siehe Anhang). Dagegen ist die Mauritius also Massenware! Somit ließ sich auch nur ein Teil der Spezifikation praktisch testen. Übrigens beherrscht auch das bekannte Programm ImageMagick dieses Format, womit sich weitere Beispiele erzeugen ließen, doch das hebe ich mir für Bildinfos 2 auf.
• Die nächste phantastische Neuigkeit ist, daß ich den FL32-Code nicht mehr in das überfüllte Bildinfos gequetscht habe, sondern in eine Bibliothek, eine R-Basic-Library, steckte!
  
  
  • Jedes R-Basic-Programm kann diese Bibliothek einbinden und damit FilmLight32-Dateien anzeigen 8)! Bestimmt wiegen notorische Zweifler ihre schweren Köpfe bedenkenvoll hin und her, aber es sei bereits verkündet, daß dies nur den Anfang darstelle und weitere schöne und noch nützlichere Bibliotheken folgen werden!
  • Da fertige Bibliotheken nur ausgeführt, aber nicht debuggt werden können, habe ich für die Entwicklung ein Programmgerüst geschaffen, womit ich die Library wie ein normales Programm schreiben und testen kann (siehe auch Bild). Der Quelltext wird gleich fein säuberlich auf die Code-Fenster aufgeteilt, so daß der Test-Code schnell entfernt werden kann – und die Bibliothek steht bereit!

PS: Das Beispielbild mag in meinem Geos etwas unansehnlich wirken, das liegt jedoch an den 256 Farben. Als BMP gespeichert und auf dem Mac angezeigt, erkennt man jedoch die Farbenpracht. Falk, kommt dieses Jahr der endlich Mac-MegaDosBox-Treiber :-)?

Heute habe ich mich mal damit beschäftigt, wie man das Runde ins Eckige bekommen kann. Genau, ich wollte einen Kreis in ein Bild einfügen.
Dabei muß die schicke, glatte Kreislinie so zackig auf Pixel aufgeteilt werden, daß trotzdem ein runder Eindruck verbleibt.
Eine Inspirationsquelle fand ich im Mittelpunkt-Algorithmus, den ich an meine Zwecke adaptierte, denn ich wollte den Kreis nicht auf einmal erstellen, sondern Schicht für Schicht aufbauen.
Nach etlichen Versuchen leuchtet mir dann endlich die Sonne entgegen!
Vom Erfolg beflügelt versuchte ich mich dann sogleich am allgemeineren Gevatter, der Ellipse. Dafür paßte ich den Algorithmus selbst an deren Formel an und wurde bald erneut belohnt. Graphikprofis gähnen da wohl nur, aber mir hat das Werkeln mit den mathematischen Formeln so viel Freude bereitet, daß ich die kleinen Goldstücke hier mit Euch teile !

Ein Hallo hinaus ins wilde Schneegestöber!

Eine Frage: Hat jemand zufällig Windows 3.0 am Laufen und könnte für mich etwas ausprobieren?

Habe es schon mit Windows 3.11 ausprobiert und hätte nun noch gerne einen weiteren Test.
Und zwar lautet die Aufgabe: Paintbrush öffnen und unter Optionen – Palette laden die angehängte Farbpalette zu laden und schauen, ob es funktioniert.
Das Sahnehäubchen wäre: Paintbrush starten und unter Optionen – Palette speichern die originale Paintbrush-Palette zu sichern und mir zu schicken .

Herzlichen Dank!

PS: Bei Ausflügen nicht Jack Londons Lehren vergessen und die gefangenen Rebhühner nicht etwa unter schneebedeckten Bäumen über dem Lagerfeuer grillen!

PPS: Ein Sakrileg des Teerens und Federns würdig, aber unter der DOSbox läuft Win 3.11 gefühlt schneller als Geos

Im Gegensatz zu UTF-8, das wir mit Rainer ja schon nach R-Basic gebracht haben, besteht in UTF-16 ein Zeichen aus zwei Byte. Damit reagieren diese sehr sensitiv auf ihre Reihenfolge: welches steht zuerst, welches folgt (Little Endian vs. Big Endian). Wenn sie mal vorwitzig ihre Plätze tauschen und Wald-und-Wiesen-Software, wie etwa Photoshop, darauf nicht mitfühlend eingeht, dann mutiert ein profanes, deutsches „Farbe 1“ zu einem chinesischen „Liebe und die Liebe“ – meint zumindest der Google Translator .