GEOS-InfoBase-Forum

Zitat von »Rainer«

Was ist der Unterschied zwischen GIF, GIF87 und GIF89a ?

https://de.wikipedia.org/wiki/Graphics_Interchange_Format

Von einer Webseite kopiert: "GIF87a is the original format for GIF images. GIF89a included support for multiple images in the file, as well as support for animation."

In der englischen Wikipedia stehen noch ein paar weitere Neuerungen in 89a, wie transparente Hintergründe, Speichern von Kommentaren (und anderen Texten), ...:
"The original version of GIF was called 87a.[1] In 1989, CompuServe released an enhanced version, called 89a,[2] which added support for animation delays (multiple images in a stream were already supported in 87a), transparent background colors, and storage of application-specific metadata. The 89a specification also supports incorporating text labels as text (not embedding them in the graphical data), but as there is little control over display fonts, this feature is not widely used. The two versions can be distinguished by looking at the first six bytes of the file (the "magic number" or signature), which, when interpreted as ASCII, read "GIF87a" and "GIF89a", respectively."

Mit anderen Worten: Will man die Transparenz erhalten oder Animationen speichern, sollte man 89a nehmen. Andernfalls reicht 87a.

Meine Englischkenntnisse bewegen sich zwar immer noch auf prä-Kindergarten-Niveau, aber der oben von Martin gepostete Link scheint zu ziemlich detaillierten Infos zu führen.

Interessant ist auch, das GIF mittlerweile schon lange patentfrei ist.

Bezogen auf das Konvertierungsskript ist weniger wichtig, wer wie was versteht, sondern was ImageMagick bei der GIF-Erstellung zu leisten vermag, vor allem im Hinblick auf (halb)transparente Bildpunkte. Das ist mir erst jetzt klargeworden, als ich mir die Konsolen-Optionen von ImageMagick angeschaut habe; auf der spartanischen GUI des Programms war davon nämlich nichts zu sehen.

ImageMagick bietet etliche Tools, um ein "GIF" (so wird es in der UI genannt) zu erzeugen, und meint mit "GIF87" das alte Format mit begrenzten Möglichkeiten für denjenigen, der unbedingt "old school" konvertieren möchte. Es steht hier also nicht in Rede, was GIF87a oder GIF89a sind. Ein Beispiel von den ImageMagick-Seiten:

Because of the GIF limitations, IM performs the following set of operations before saving to the GIF file format...
-channel A -threshold 50%
if (fully-)transparent pixels are present it then...
-quantize transparent -colors 255
otherwise if no transparent pixels present...
-colors 256

@Rainer: Bislang ist ausschließlich von einer Konvertierung Richtung GEOS die Rede. Umgekehrt bedarf es, wie Jörg im anderen Thread ausgeführt hat, keines solchen Vorgangs.

Es wird spannend sein herauszufinden, welche Einstellungen für die Konvertierung standardmäßig am vorteilhaftesten sind; ich denke da beispielsweise an die GEOS-Farbtabelle und die GEOS-Farbtabelle ohne IBM-RGB-Farben, die Thomas damals gepostet hat. Nach meiner Erinnerung genügt es, wenn eine solche Farbtafel im Zielordner liegt, also in DOCUMENT\Clipper_Images oder so ähnlich. Wenn die Skripte Richtung GEOS prinzipiell stehen, werde ich mir da noch Hilfe suchen.

Abschließend noch einmal: "GIF" und "GIF87" stehen hier weniger für Formateigenschaften, als vielmehr für das jeweilige Bündel an Maßnahmen, die ImageMagick ergreift, um die Konvertierung durchzuführen. Im Einzelnen nachzulesen im o. a. Link. Aus der UI ergibt sich das nicht (s. Anhang).

Ich mach mal 'ne Pause im Forum.

Hallo Martin,

Finde das Thema Clipper + Bilder sehr spannend. Die Palette enthält alle von GEOS im 256-Farben Modus nutzbaren Farben. Ein GIF, das nur diese Farben verwendet, wird folglich auch in der DOSBOX auf dem Mac korrekt angezeigt. Die ersten 16 Einträge (=IBM CGA Palette) werden leider auf Farbdruckern nicht wie auf dem Monitor wiedergegeben. Schließt Du sie daher bei der Konvertierung aus, erlebst Du keine bösen Überraschungen im Ausdruck bzw. PDF. Dieser gezielte Einfluß auf die verwendeten Farben, ist auch der Grund weshalb ich das GIF-Format unter GEOS bevorzuge.

Ich hoffe, bald wieder etwas Zeit zu haben, hier mit zu schnacken. Hätte da auch noch Ideen...

Gruß Thomas

Ich habe mir bei IBM mal die RGB-Farbtabelle angeschaut. Jetzt verstehe ich das Problem besser.

Was ImageMagick anlangt, scheint es mir für ein sinnvolles Standardverfahren am besten, mit "-remap" zu arbeiten, wobei eine GEOS-Palette mit Grautönen im GEOS-Rootverzeichnis (oder auf C: ) abgelegt wird. Ganz spannend finde ich die Behandlung von (halb-)transparenten Farben durch ImageMagick vor der Umwandlung in ein GIF. Da wäre dann noch die Frage nach der richtigen Reihenfolge der Befehle, und ob eventuell zweimal gedithert werden müßte: vor und nach dem Remapping.

Nur mal so: ImageMagick gibt es auch für Windows und Mac, mit eigener Skriptsprache.

Falsch gedacht: Einbindung der GEOS-Palette für Grafiken aus dem Web völliger Fehlschlag, Dithering gut. Es scheint sich zu bewahrheiten, was Thomas hier gesagt hat. Also wohl doch keine allgemeingültige Standardlösung, sondern zwei Skripte: "web2geos" und "img2geos".

Dithering ist sinnvoll, wenn im Bild Farbverläufe vor kommen. Diese produzieren beim direkten Mapping auf die 216 (6x6x6) Farben + 16 Graustufen sonst hässliche "Treppen". Du könntest versuchen, die geeignte Konvertierungsmethode näherungsweise über die Anzahl verschiedener Farben im Quellbild zu ermitteln:



Da auch JPEG komprimierte Cliparts wegen der Kompressionsartefakte mehr Farben enthalten kann, sind 256 wahrscheinlich in der Praxis zu wenig. Vielleicht ist ein Schwellwert von 2000 oder noch etwas mehr nötig, damit sie wieder "saubere cliparts" werden...

VG Thomas

Zitat von »t.hass«

Du könntest versuchen, die geeignte Konvertierungsmethode näherungsweise über die Anzahl verschiedener Farben im Quellbild zu ermitteln:

Das klingt natürlich verlockend, und dennoch tue ich mich mit dieser Lösung schwer. Wahrscheinlich erwischt das Skript 90-95 Prozent der Fälle; wenn man noch eine Codezeile anfügen könnte; "... und wenn Ergebnis Mist, dann andersherum.", dann wäre es perfekt. Aus dem Bauch heraus gefällt mir die Lösung besser, einen Klick nach Schätzung durchzuführen (Dithering oder Remapping), und wenn Schrott, dann zweiter Klick auf die Alternative.

Vorhin habe ich Fotos im Netz erst gedithert (Floyd-Steinberg), und dann auf die GEOS-Palette reduziert. Ergebnis war furchtbar. Dithering allein hat ein GIF89a produziert, das vom Clipper perfekt eingelesen wurde; der kann wohl dasselbe wie Gonzo. Ich weiß noch nicht so recht, welches der richtige Weg ist.

Apropos: als Nebenprodukt meiner Versuche habe ich ein paar hübsche Icons für den Tray gebastelt, die ich einfach mal anhänge, falls jemand so etwas mag. Sind sieben kleine PNGs.

Zitat von »msgeo«

Vorhin habe ich Fotos im Netz erst gedithert (Floyd-Steinberg), und dann auf die GEOS-Palette reduziert. Ergebnis war furchtbar.

Das macht so auch wenig Sinn, denn durch das Dithering sollen ja nur die Zwischentöne gemischt werden, die in der Palette nicht direkt verfügbar sind. Beide Vorgänge müssen folglich "in einem Abwasch" erfolgen...

Ähm, ich hatte ein kleines Detail zu erwähnen vergessen: Quelldatei war ein PNG. Mit JPEGs klappt es prima: convert.im6 /root/test.jpg -dither FloydSteinberg -remap GeosPalette.png GIF87:/root/test.gif. Hat natürlich den Vorteil, daß die Grafik anschließend mit jedem GEOS-Programm bearbeitet und exportiert werden kann. Ich kann auch im Browser nachsehen, welches Format die zu konvertierende Datei besitzt. Aber ich muß erst noch das Konvertierungsproblem mit den PNGs lösen.

Es liegt am Remapping, das in einer älteren ImageMagick-Version nach meiner Erinnerung gut funktioniert hat. Im Moment muß ich aus Eigennutz aber erstmal etwas anderes machen. Im Folgenden ein Skript, das alle PNGs in meinem Scan-Verzeichnis ins GIF87-Format umwandelt. Dabei wird u. a. skaliert und die Dateinamen werden bis auf das Suffix beibehalten.

$ /bin/bash
convert.im6 /root/.dosemu/drive_c/e/document/scans/*.png -scale 826 -colorspace gray +dither -colors 2 -normalize -set filename:f "%t" GIF87:/root/.dosemu/drive_c/e/document/scans/%[filename:f].gif

Oben genanntes Skript betrifft die Verarbeitung gescannter Korrespondenz oder von Webseiten heruntergeladener Verträge/Rechnungen bspw. vom Strom-oder Gasversorger, Telefonanbieter u. ä.

Ich habe für mich die Skalierung von 826 (y) auf 1240 (y) geändert, also von 100 auf 150 dpi, aus mehreren Gründen: zunächst kommen für die Ansicht und die Verwaltung gescannter Korrespondenz vor allem zwei Wege infrage, einmal Gonzo und zum anderen das Scrapbook. Gonzo ist für die Betrachtung natürlich bequemer, muß aber erheblich mehr Einzelgrafiken verwalten, die sauber indiziert und notfalls in eigene Ordner verschoben werden müssen, je nach Umfang der Korrespondenz (ich erinnere mich, daß allein mein Mietvertrag mit Anhängen und Übergabeprotokollen 80 Seiten umfaßt hat). Deshalb verwende ich Sammelalben, um einen besseren Überblick zu behalten; der Mietvertrag beispielsweise ist in zweien gelandet. Sammelalben wiederum sind nicht so komfortabel in der Betrachtung wie Gonzo, weshalb ich gelegentlich Scrap&Drop mit seiner Zoomfunktion heranziehen muß. Deshalb nehme ich unter GEOS eine weitere Ansichtsskalierung auf 75 dpi vor, halbiere also den Zoomfaktor der Quelldatei, ohne deren Pixel zu reduzieren. Das Ergebnis läßt sich auch im normalen Sammelalbum im Regelfall einigermaßen lesen.

Zweitens vereinfacht die Ansichtsskalierung auf 75 dpi den (Beleg-)Ausdruck einer gescannten Korrespondenz: wenn ich GeoWrite ode GeoDraw verwende, um in eine ps-Datei zu drucken (ich verwende geos2pdf nicht, da muß mir Achim mal helfen), oder eben ein PDF zu erstellen, dann brauche ich lediglich die Seite(n) im Sammelalbum zu kopieren, die Ansicht von Write oder Draw auf "Anpassen" ("scale to fit") zu stellen, und die Grafik wird mittig eingefügt. Jetzt nur noch drucken. Nochmal: GEOS klebt Grafiken in die Mitte des sichtbaren Bereichs, daher die Gesamtansicht einer DIN A4-Seite aufrufen.

Ich habe bewußt realitätsnahe Grafiken angehängt, die allerdings nichts enthalten, was Google & Co. nicht längst über mich wissen. Nebenbei: die Ausdruckqualität eines derart erzeugten PDFs ist weitaus höher, als es die Bildschirmansicht unter GEOS vermuten ließe.

Skript zum Konvertieren der Scans in das Gif87a-Format und Icon für den Tray.