Sie sind nicht angemeldet.

1

Freitag, 5. Oktober 2018, 10:24

Bildformate

Zitat

Zitat von »Rainer«
Zu welchem Zweck? :whistling:


Stimmt, ich habe bislang einen Fehler begangen. ImageMagick bietet sowohl "GIF" (nicht GIF89a!) als auch "GIF87" zur Konvertierung an, aber das fortschrittlichere Verfahren bei ImageMagick ist "GIF", vgl. http://www.imagemagick.org/Usage/formats/#gif
Es fällt mir immer schwer dem Ganzen zu folgen, weil ich oft nicht weiß, ob du gerade bei GEOS oder beim Host bist. Also konkret: Wenn du nach GIF konvertierts, weil du ein 8 Bit Format haben willst, oder wile GEOS PNG nicht kann, dann verstehe ich das. Wenn du aber nach GIF konvertierst, weil das GIF-Format klein ist, dann verstehe ich das nicht - immer mit der Maßgabe, dass du die Datei anschließend nach GEOS importieren willst.

Klär mich mal bitte auf: Was ist der Unterschied zwischen GIF, GIF87 und GIF89a ?

Gruß
Rainer
Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

2

Freitag, 5. Oktober 2018, 11:58

Was ist der Unterschied zwischen GIF, GIF87 und GIF89a ?
https://de.wikipedia.org/wiki/Graphics_Interchange_Format

3

Freitag, 5. Oktober 2018, 19:05

Ich liebe es wenn jemand etwas weiss und trotzdem auf Wikipedia verweist oder etwas nicht weiss und deshalb auf Wikipedia verweist.
Den einzigen Unterschied den ich gefunden habe ist die Möglichkeit von Transparenz .


Mein Fehler. Frage falsch formuliert. Also welche Vorteile hat die eine Version weswegen du sie gegenüber der anderen bevorzugst?
Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Rainer« (5. Oktober 2018, 19:52)


4

Freitag, 5. Oktober 2018, 19:26

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.
d[ 0_O ]b

5

Freitag, 5. Oktober 2018, 20:02

Ups, da hat das Handy den halben Betrag nicht gesendet.
Trotzdem Danke. Das war mir so nicht klar. Aber wegen der Abwärtskompatibilität macht das Speichern als GIF87a eigentlich keinen Sinn.

Gruß
Rainer
Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

6

Freitag, 5. Oktober 2018, 20:49

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.
Bernd

7

Freitag, 5. Oktober 2018, 21:47

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).
»msgeo« hat folgendes Bild angehängt:
  • gif87.gif
"Always Look On The Bright Side Of Life!"

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »msgeo« (5. Oktober 2018, 22:30)


8

Sonntag, 7. Oktober 2018, 20:27

Hallo,
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
Halb-Transparent ist ja nu nicht. Das geht auch in GEOS nicht. :)
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.
Die eigentlich spannende Frage ist: Was versteht man unter "Vorteilhaft"?

8 Bit macht Sinn, wenn man Speicher sparen will. Bei größeren Bilder auf jeden Fall eine gute Wahl.

Die GEOS Farbpalette zu verwenden scheint zunächst einmal clever, ist aber nur dann sinnvoll, wenn du das Bild z.B. in ein anderes Bild mit GEOS-Palette hineinzeichnen willst. Jedes Nicht-GEOS-Programm wird die Farbpalette mit abspeichern (egal welche es ist), und GEOS wird sie mit einlesen, so dass es speichermäßig keinen Unterschied gibt (aber was sind schon 768 Byte in der Gesamtbilanz). Ganz im Gegenteil. Wenn das Programm aus dem vorhandenen Bild eine eigene Farbpalette erzeugen kann (also keine vorgefertigte benutzt) bekommst du schon mal eine bessere Qualität.

Willst du eine richtig gute Bildqualität (dass 8 Bit also noch etwas nach True Color aussieht, dann musst du außerdem dafür sorgen, dass das Programm das Bild dithert, und nicht die Farben einfach ersetzt. Ein gängiges und gutes Verfahren ist "Floyd-Steinberg", in dem die beim Ersetzen eines True-Color-Pixels durch eine Palettenfarbe entstehenden Fehler auf die umliegenden Pixel verteilt werden (sog. Fehlerdiffusion). Damit bekommst du selbst bei einer vorgefertigten Palette ganz gute Ergebnisse. Mein Sigma macht das z.B. so. Aber dann bist du ja schon in GEOS :-)Dithering hat aber ganz und gar nichts mit GIF oder nicht GIF zu tun. Womit wir wieder bei meiner ursprünglichen Frage wären :P


Gruß
Rainer



P.S. Ich muss schon wieder blöd fragen. Was zum Teufel sind "IBM-RGB-Farben"? Und warum sollen sie etwas schlechtes sein? (Ist aber nicht ganz so wichtig).


P.P.S Ich habe mir den Text in deinem Link nicht angetan. a) keine Zeit und b) ein Programm, das ich als Windows-User eh nicht habe. Vielleicht findest du ja was zum Thema Dithering und "angepasste" Palette:)
Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

9

Freitag, 12. Oktober 2018, 23:02

Ich mach mal 'ne Pause im Forum.
"Always Look On The Bright Side Of Life!"

10

Samstag, 13. Oktober 2018, 11:09

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

11

Samstag, 13. Oktober 2018, 11:56

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: :D ) 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.
"Always Look On The Bright Side Of Life!"

12

Samstag, 13. Oktober 2018, 13:16

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".
"Always Look On The Bright Side Of Life!"

13

Samstag, 13. Oktober 2018, 18:00

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:

Quellcode

1
2
3
4
5
6
if [ $(identify -format %k $quelle) -le 256 ]
then
   convert $quelle +dither -remap GeosPalette.png GIF87:$ziel
else
   convert $quelle -dither FloydSteinberg -remap GeosPalette.png GIF87:$ziel
fi


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

14

Samstag, 13. Oktober 2018, 19:12

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.
»msgeo« hat folgende Bilder angehängt:
  • txt2geos.png
  • web2geos.png
  • img2geos.png
  • draw2linux.png
»msgeo« hat folgende Datei angehängt:
  • icons.zip (19,06 kB - 46 mal heruntergeladen - zuletzt: 14. November 2018, 01:26)
"Always Look On The Bright Side Of Life!"

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »msgeo« (13. Oktober 2018, 21:09)


15

Montag, 15. Oktober 2018, 21:00

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...

16

Dienstag, 16. Oktober 2018, 14:54

Ä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.
"Always Look On The Bright Side Of Life!"

17

Dienstag, 16. Oktober 2018, 15:41

@Thomas
Dein Beitrag vom Samstag, 13. Oktober 2018 war sehr erhellend für mich. Von der Seite habe ich das noch nicht gesehen. Danke. Der Vollständigkeit Halber zwei Ergänzungen.
1. Wenn man die Palette will muss es nicht GIF sein, BMP z.B. unterstützt auch Paletten. Das nutzt bloß kaum ein Programm.
2. Das Problem mit den "umgemodelten" Farben beim PDF-Druck hast du nicht nur mit den unteren 16, sondern auch mit den höheren Farben, wenn die Farbzusammensetzung genau einer der unteren 16 entspricht (was wegen der Systematik Farbwerte vorkommt). Das ist offenbar ein Problem im PDF-Treiber. Zum Glück fällt das bei geditherten Bildern nicht auf. Wenn ich mich recht entsinne gibt es das Problem sogar beim True Color Druck, dafür würde ich aber meine Hand nicht ins Feuer legen.
Ähm, ich hatte ein kleines Detail zu erwähnen vergessen: Quelldatei war ein PNG.
Gleiches Bild, verschieden Formate -> unterschiedliches Ergebnis? Kann eigentlich nicht sein, da die Bilder vor der Bearbeitung immer entpackt werden müssen (also dann quasi gleich sind). Wenn dich hast du (oder imgaemagic) etwas falsch gemacht.
Gruß
Rainer
Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

18

Samstag, 20. Oktober 2018, 06:37

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
»msgeo« hat folgende Datei angehängt:
  • img2geos.zip (317 Byte - 42 mal heruntergeladen - zuletzt: 14. November 2018, 01:27)
"Always Look On The Bright Side Of Life!"

19

Samstag, 20. Oktober 2018, 19:32

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.
»msgeo« hat folgende Bilder angehängt:
  • pixel.png
  • scraps.png
  • index.png
  • scale.png
"Always Look On The Bright Side Of Life!"

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »msgeo« (20. Oktober 2018, 22:07)


20

Samstag, 20. Oktober 2018, 22:02

Skript zum Konvertieren der Scans in das Gif87a-Format und Icon für den Tray.
»msgeo« hat folgendes Bild angehängt:
  • scan2geos.png
»msgeo« hat folgende Datei angehängt:
  • scan2gif.zip (318 Byte - 46 mal heruntergeladen - zuletzt: Heute, 04:20)
"Always Look On The Bright Side Of Life!"

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »msgeo« (21. Oktober 2018, 00:46)


Ähnliche Themen