GEOS-InfoBase-Forum

Würde auch vermuten, daß macOS etwas Antialiasing betreibt.
Es kann auch keine s/w-Bilder mehr darstellen, sondern rechnet diese in 256-Graustufen-Bilder um (so wurde mir gesagt). Vielleicht nutzt das System diese Gelegenheit und interpoliert zwischen Schwarz und Weiß.

So, verehrte Lesegemeinde, nach drei Wochen Verschwundensein geht es (hoffentlich) wieder weiter.
Nachdem ich ja kurz vor Weihnachten als tollkühnen Überraschungscoup einen Export nach PBM, der Portable Bit Map, vorgestellt hatte, gedachte ich, das Jahr mit einem phänomenalen Donnerschlag, quasi als informationstechnologischen Äquivalent zum knallbunten Silvesterraketenreigen, beginnen zu lassen, und auch die restlichen und zugleich ursprünglichen Mitglieder der Netpbm-Familie, nämlich Portable Gray Map und Portable Pixel Map, zum Export anzubieten. Doch, ach, Träume sind Schäume! Aus der angedachten schnellen Kopie des PBM-Codes erwuchsen ein Sumpf, ein Labyrinth, ein Bermuda-Siebzehneck sowie ein Schwarzes Loch. Irgendwo dazwischen bin ich dann verschwunden .

• Da PBM, PGM und PPM die Familie PNM, die Portable Any Map, bilden, entschloß ich mich nach einigen Versuchen, diese als gemeinsame Exportoption anzubieten und das Programm die jeweils geeignete Formatversion auswählen lassen. Doch dann wurden Exportdialoggestaltung, Export-Programm-Code und das Zusammenspiel der beiden immer komplexer.
  
• Nehmen wir PBM als Beispiel. Das Format speichert nur Schwarz-Weiß-Bilder. Bislang funktionierte der Export so (übrigens genau wie bei MacPaint), daß nur Bilder mit 1 Bit Farbtiefe, die (in Geos) immer schwarz-weiß sind, exportiert wurden.
  
  • Doch muß das so beschränkt sein? Es gibt doch auch Bilder mit 8 oder 24 Bit Farbtiefe, die auch Schwarz-Weiß-Bilder sind! Warum sollen die sich nicht als PBM speichern lassen?
    
  • Also gut, dann werden eben Routinen geschrieben, die das zu exportierende Bild als schwarz-weiß, grau oder farbig klassifizieren. Dann kann Bildinfos unabhängig von der Farbtiefe das geeignete Format wählen.
    
  • Mmmh, aber vielleicht will ich mein Schwarz-Weiß-Bild mit 24 Bit Farbtiefe gar nicht als PBM speichern, sondern mir wären PGM oder PPM viel lieber?! Dann also doch kein Automatismus, sondern eine Vorgabe durch den Nutzer? Aber will der das immer entscheiden? Oder strauchelt er zwischen den Formatvarianten gerade so wie ich? Also wie nun? Und wie soll sich das möglichst klar im Dialog zeigen?
    
  • Und die Transparenz! Die PNM-Formate unterstützen keine Tranparenzen. Also muß für Bilder mit Transparenzen bestimmt werden, welche Farbe an den unsichtbaren Stellen ersatzweise eingesetzt werden soll. Doch was, wenn der Nutzer als Ersatzfarbe für einen PBM-Export einen Grauton oder gar einen bunten wählt? Dann ist das Bild zwar vielleicht schwarz-weiß, aber durch die Ersatzfarbe wird es zum Farbbild. Dann kann es nur noch als PPM gespeichert werden.
    
  • Doch wie prüfe ich ein Bild auf Transparenzen? In R-Basic kann ich dafür die Bitmap-Eigenschaft BF_Mask abfragen. Doch es könnte doch sein, daß zwar eine Transparenzmaske vorhanden, aber kein einziges Pixel im Bild auf transparent gesetzt ist! Dann käme auch nicht die bunte Ersatzfarbe zum Zuge und das Bild könnte doch als PBM gespeichert werden! Doch um diesen Fall zu prüfen, müßte ich vor dem Speichern erst jede Bildzeile einlesen und die Transparenzdaten prüfen, dann das Exportformat festlegen und danach wieder alle Bildzeilen einlesen und ins Exportformat wandeln. Das kann unangenehm lange dauern.
    
  • Es war ein Graus! Irgendwann wünschte ich mir sehnlichst, die Transparenz möge sich unsichtbar machen und einfach verschwinden! Ich verdammte (fast) den Tag, an dem ich sie ins Programm geholt hatte!
    
  
  
• Und diese mühsame Familie wuchs auch noch! Es kamen halbseidene Cousins hinzu, die aufgrund einer vagen Ähnlichkeit in den Gesichtszügen adoptiert wurden! Es gibt nun auch das Format PFM, die Portable Float Map! Diese gibt's in Grau und in Farbe und beide verwenden für die Farbwerte keine Ganzzahlen, sondern Kommazahlen.
  
  • Erfunden haben dieses neue Format andere, in diversen Untervarianten. Die am besten ins bestehende Konzept passende wird vom Netpbm-Team gnädig geduldet, aber ist keine offizielle Variante.
    
  • Vom Aufbau her ähnelt PFM eher PAM, dem Nachfolger der PNM-Formate PBM, PGM und PPM. (Juchu, alle Kürzel in einem Satz untergebracht !)
    
  • Und zu PFM gibt es auch schon einen neuen Seitentrieb, nämlich PHM! Während nämlich PFM für jeden Farbkanal 32-Bit-Zahlen nutzt, begnügt sich die Portable Half Float Map mit 16 Bit.
    

Das war ein kurzer Blick auf die Mahlsteine, die sich anschickten, einen unschuldigen Programmierer zu Bit-Staub zu zerreiben. Vor diesem Schicksal bewahrten ich dann u.a. wohnliche Neugestaltungsaufgaben, die selten so willkommen erschienen. Über eine Woche lang erholte ich mich mit einer Bohrmaschine und nach Abschluß der Therapie bin ich dieses Wochenende ganz vorsichtig nur ein bißchen rückfällig geworden. Um den wütend kreischenden PNM-Code habe ich einen weiten Bogen getippt und mich mit unschuldigen Themen beschäftigt. Das ist wie Spielen mit Plüschtieren ... oder Gremlins?

Was war also das im vorherigen Beitrag erwähnte Wochenendplüschtier? Es war das gute, alte, liebe XBM, die X BitMap. War etwas verstaubt vom Dachboden, denn sein Nachfolger XPM versucht schon seit 1989, es zu verdrängen.

Kürzlich fand ich neue XBM-Beispielbilder, die ich mit meinem Code testweise anzeigen ließ. Bei einem entdeckte ich eine unerwartete Anomalie: Negative Hotspot-Koordinaten!

XBM-Bilder können nicht nur einfache Bilder enthalten, sondern auch Mauszeiger. Bei diesen ist ein Hotspot definiert, das ist die heiße Spitze des Mauszeigers.
Bei mir im Programm waren nur positive Werte erlaubt, doch dieser Zeiger besaß eine negative Spitze!
Also schaute ich doch einmal in den C-Quell-Code aus einen X-Window-Archiv und siehe da, während die Bildgröße als uint definiert war, war beim Hotspot das u wohl verbrannt und es gab nur int. Somit deckt die Bildgröße den Bereich 0–65.535 Pixel ab, die Spitze liegt aber zwischen -32.768 und 32.767.

Die Anpassung in Bildinfos ging dann doch immer das bloße Wechseln des Datentyps hinaus. So konnten jetzt negative Zahlen nicht mehr als Fehler-Code verwendet werden und das Parsen des XBM-ASCII-Formats mußte auch ein Minuszeichen an dieser Stelle akzeptieren.

Habe jetzt doch nochmal in XBM-Spezifikationen gestöbert und besonders wegen der negativen Mauszeigerspitzen, den Hotspots, geschaut.
So las ich mich durch den Code der freedesktop-Organisation zum Lesen und Schreiben von XBM-Bildern.
Dort fand ich dieses interessante Code-Stück:

Das würde ich jetzt so interpretieren:

• Der if-Befehl: Wenn die x-Koordinate nicht -1 beträgt, dann schreibe die beiden Zeilen zur Hotspot-Definition in die Datei.
  
• Mir scheint nun, daß gar keine negativen Koordinaten erlaubt sind, sondern daß ein negativer Wert einfach besagt, daß keine Hotspot-Definition vorliegt.
  Negative Koordinaten wären wohl auch unpraktisch. Wenn sich zum Beispiel der Mauszeiger am oberen Bildschirmrand befindet, also auf der Bildschirmzeile 0, dann würde seine Spitze aber im negativen Bereich liegen. Und darauf muß die Steuerung der graphischen Oberfläche ja erstmal vorbereitet sein. Vielleicht ist sie das heutzutage sogar, nur mir erscheint es doch praktischer, im positiven Bereich zu bleiben.
  
• Diese if-Abfrage scheint mir aber nicht sehr fehlerrobust zu sein. So könnte die x-Koordinate ja auch den Wert -3 haben. Oder sie ist positiv, aber der y-Gefährte ist negativ. In beiden Fällen würden ungültige Werte in die Datei geschrieben werden (sofern man der Hypothese folgt, daß nur nichtnegative Koordinaten sinnvoll sind).
  Was sagen die C-Profis zu diesem Code-Vorschlag?
  

  	Quellcode
  1 2 3 4	if (x_hot >= 0 && y_hot >= 0) { fprintf(stream, "#define %s_x_hot %d\n", name, x_hot); fprintf(stream, "#define %s_y_hot %d\n", name, y_hot); }

  
  

Zitat von »Rainer«

Letztlich ist es aber eine Frage der Definition, was ist erlaubt was nicht.

Ja, letztlich war es ja nur ein Code-Auszug. Vielleicht haben sie ja schon an anderer Stelle sichergestellt, daß diese Variablen nur Werte >= -1 annehmen können.

An den PNM-Code habe ich mich noch nicht wieder herangewagt, aber etwas Neues erschaffen wollte ich doch. Also nahm ich mir den Code zum MacPaint-Speichern und formte daraus – ein Gefühl wie Giacometti! – eine Speichern-Möglichkeit im XBM-Format, dem klassischen X-Window-Bildformat.

• XBM speichert Schwarz-Weiß-Bilder mit 1 Bit Farbtiefe. Es ist ein ASCII-Format und stellt puren C-Code dar. So konnten die Unix- und X-Programmierer die Bilder, Icons und Mauszeiger direkt in ihre Programme einbinden.
  
• Obwohl es so ein einfaches Format ist, wuchs der Dialog mit den Optionen immer weiter an und ist nun umfangreicher als bei jedem anderen Format (siehe Anhang)!
  
• Als Besonderheit - und nicht ganz unwahrscheinlich als planetweites Unikum – erlaubt Bildinfos das Speichern im urhistorischen X10-Format! Das sollen einige Programme angeblich noch lesen können.
  
• Hinweis: Das Anzeigen von XBM-Bildern klappt bei anderen Programmen inzwischen aber nicht mehr problemlos. Der Mac-bekannte GC versteckt die Bilder hinter einem Grauschleier, das plattformübergreifende XnView streikt gleich ganz. Bei beiden Programmen habe ich schon etliche Fehler bei der Bildanzeige gefunden. Die alten Formate fragt wohl keiner mehr nach (sonst wäre es schon aufgefallen), aber für mich wirft es doch ein erstaunliches und schattiges Licht auf die Qualitätskontrollen.
  
• Die Hälfte der Wahlmöglichkeiten beim Speichern betrifft allerdings gar nicht das Format an sich, sondern erlaubt die Gestaltung des C-Codes. Da gibt es ja durchaus verschiedene Vorlieben. Die Anhänge zeigen eine luxuriöse und eine spartanische Variante.
  
• Derzeit werden die Hexadezimalbuchstaben immer als A-F groß geschrieben. In den Beispiel-C-Codes, die ich fand, werden allerdings oft die Kleinbuchstaben a-f verwendet. Kann sein, daß diese den sparsamen C-Programmierer lieber sind. Spart ja das Drücken der Umschalttaste! – Was meint Ihr?
  Die Option, die XBM-Bilder mit Kleinbuchstaben zu erstellen, fehlt allerdings noch. Die R-Basic-Funktion Hex$() bietet keinen Schalter dafür, sondern wirft immer große Buchstaben aus. Rainer! Ich könnte natürlich den Hex-String optional durch den Aufruf convert$(hexnumber$, DOWNCASE_CHARS) jagen, aber dann wird der Code wieder komplexer und langsamer. Jede Abfrage und jeder Aufruf machen sich ja bemerkbar. Mal sehen, bis zu welcher Höhe mein Postfach mit Nachfragen und Bitten dazu überschwemmt wird :-)!
  
• Was noch fehlt, ist die (bei den PNM-Formaten erwähnte) Möglichkeit, auch Schwarz-Weiß-Bilder mit 8 und 24 Bit Farbtiefe als XBM (bzw. MacPaint, da steht es auch noch aus) zu speichern. Das dürfte wohl der nächste Streich werden!
  

Nachtrag: Ich füge mal noch mit der zip-Datei drei (bekannte) Bilder in der XBM-Variante hinzu. Vielleicht möchte die ja mal jemand bei sich ausprobieren. Ein Linux-Test wäre ganz interessant, denn die X-Betriebssysteme sollten das Format ja beherrschen! Habe die Bilder in der ganz einfachen Form, ohne Kommentare und Leerzeilen, über die z.B. der GC stolperte, erstellt.

Es klappt :-)! Danke!

Hase und Ente sind zusammen einfach nicht zu schlagen ! Danke, Achim!

Das sieht doch gut aus! Beziehungsweise die Rose sieht immer so schlecht aus .

„ToyViewer“ kannte ich noch nicht! Entgegen deiner Aussage werben sie aber gerade damit, daß sie unglaublich viele Formate unterstützen: „supporting absolutely everything from TIFF to obscure formats like XBM and MAG“. Dabei sind auch die dubiosen PNG-Formate PBM, PGM und PPM sowie, mehrmals erwähnt, ein Format MAG, das mir bislang bei all meinen Recherchen noch nie untergekommen war. Kennt das jemand? Eine kurze Suche ergab als mögliches Programm MAGIchan, MS Access und MPS Magro Paint System. Äußerst mysteriös!

Zitat von »jpolzfuss«

Hallo Bernd, vermutlich kann der ToyViewer deutlich mehr Formate importieren als exportieren.

Yep, so steht es auch auf der Homepage: Mehr Importe als Exporte. Mmmh, das ist doch nicht gut für die Zahlungsbilanz!

Zitat von »jpolzfuss«

Hallo Sebi, es könnte vielleicht dieses japanische Dateiformat sein: https://mooncore.eu/bunny/txt/makichan.htm
Wobei scheinbar auch irgendwelche uralte Photoshopversionen .MAG Dateien nutzten, um den Magenta-Anteil von Bildern separat zu speichern. Oder irgendein Programm, mit dem man Platinenlayouts designen konnte…
Aber um ehrlich zu sein, sagt mir alles nichts.

Die Platinen hatte ich auch gefunden, aber die werden's wohl nicht sein. Das japanische Format sieht aber heiß aus ! Anime und Manga sind ja auch voll im Trend und in diesem japanischen Format scheint's 'ne Menge davon zu geben. Vielleicht betonen sie das Format deswegen so, wegen all der Fernostzeichentrickliebhaber!
Toll, daß du sogar eine richtige Formatbeschreibung gefunden hast! Klingt leider recht kompliziert, aber auch verdammt reizvoll ! Mal sehen, mal sehen ...


PS: Wenn Du so gut im Finden bist: Bin vor kurzem auf das alte, mir bislang unbekannte Format HP Starbase (image file) gestoßen. Starbase scheint eine HP-Graphikbibliothek aus den 80ern zu sein. Habe sogar eine Formatbeschreibung gefunden, aber keine Beispieldateien. Auch eine Anfrage im HP-Forum und bei einer Firma hat nichts gebracht. Falls Du dazu noch was findest oder weißt