Grafik - Grundlagen / GEOS-Formate
Zur Startseite     Tipps & Tricks     Grafik - Grundlagen / GEOS-Formate
 
Mehr zu GeoDraw / NewDraw


Die folgenden zwei Texte stammen von Rainer B. und sind dem InfoBase-Forum entnommen.

Wie speichert GEOS Bilder?

Eigentlich ist es ganz einfach, GEOS kennt eigentlich nur genau vier Formate, Bilder (wir reden von Fotos, Screenshots usw.) abzuspeichern, nämlich: Schwarz/Weiss (1Bit/Pixel), 16 Farben (4 Bit/Pixel), 256 Farben (8Bit/Pixel) und Echtfarben (True Color, 14 Bit/Pixel).

Jede dieser Varianten kann "normal" oder "komprimiert" sein, sowie bei Bedarf eine "Maske" haben, also teilweise transparent sein. S/W, 16-Farb und 256-Farb-Bilder können außerdem noch eine Palette haben, die angibt welche Farben aus dem riesigen Farbspektum verwendet werden sollen. Aber das ändert nichts daran, dass es nur 4 Formate sind. Man kann sogar sagen, es ist eigentlich nur genau ein Format, das aber für vier verschiedene Farbtiefen definiert ist. Beide Standpunkte sind berechtigt.

Wie man leicht sehen kann, hängt die Größe eines Bildes mit vorgegeben Maßen also ausschließlich davon ab, in welchem Format es unter GEOS vorliegt - sprich mit welcher Farbtiefe es vorliegt.

Ein Screendump liegt automatisch immer in dem Format vor, das dem aktuell eingestellten Bildschirmmodus entspricht.

Was passiert beim Import von Bildern?

Ebenfalls ganz einfach: Die Bildinformationen werden von der Platte gelesen und dabei in das passende GEOS-Format umgewandelt. Diese Aufgabe übernimmt ein Programmteil, der "Importfilter" heißt. Daraus folgt zweierlei:

  1. In welches GEOS-Format das Bild konvertiert wird, (sprich: welche Farbtiefe es hat) entscheidet der Importfilter - sinnvollerweise danach, in welcher Farbtiefe das Bild im Original vorliegt. Allerdings kann man ein 16-Farb-Bild auch in ein TrueColor-Bild importieren. Das ist möglich, wenn auch sehr speicherplatzintensiv. So wandelt GONZO aus programminternen Effizienzgründen alle GIFs in 256-Farb-Bilder um.
  2. Nachdem das Bild einmal konvertiert ist, ist die Information darüber, wie es vorher vorgelegen hat, weg. GEOS braucht diese Info nicht mehr. Wenn ich jetzt also die Grafik ins Clipboard kopieren, nach Draw oder nach Write einklebe oder was auch immer: Es ist immer eine Grafik in einem der vier GEOS-Formate.
Irgend jemand hat einmal folgende Vermutung geäußert: Das mit der Grafikebene ist wohl in etwa so, dass dort Grafiken aller Art einfach "auf dem Textblatt angeheftet werden". Wahrscheinlich bleiben JPG-Grafiken innerhalb des GeoWrite Dokumentes in ihrem Format und sind quasi nur dazugeheftet. Stimmt das?

Nein, es stimmt also nicht. GEOS wandelt die Bildaten IMMER in sein eigenes Format um. Ob man also einen Screenshot als 16-Farb-PCX abspeichert oder als 16-Farb-GIF und anschließend wieder einliest, macht keinen Unterschied, auch dann nicht, wenn das GIF auf der Platte kleiner ist als das PCX.

Was aber einen Unterschied macht (machen kann), ist, welchen Importfilter man verwendet. Und da hat man aktuell genau zwei Möglichkeiten. Den vom GEOS-System (Geodraw: Grafik importieren) und den von Gonzo. Und diese beiden Filter sind offensichtlich mit verschiedenen Zielsetzungen programmiert worden:

  1. Bei Gonzo geht es um Schnelligkeit und eine große Vielfalt an Sub-Formaten. Deswegen komprimiert GONZO nur sehr große Bilder, denn unkomprimierte Bilder werden wesentlich schneller angezeigt (mann kann sich die Dekompression schenken und einigen Verwaltungsaufwand sparen).
  2. Der Systemfilter für GIF erzeugt aber offenbar kleinstmöglich Dateien: so versteht er sich auf 16-Farb-Bilder und komprimiert automatisch.

    Anmerkung Bernd: Soweit ich mich erinnere, erzeugt der GIF-Filter bis NDO 3.2a wesentlich kleinere GIFs als der GIF-Filter der späteren GEOS-Versionen. Deshalb hatte ich den Filter aus NDO 3.2a nach BBX Ensemble 4 verpflanzt, um weiterhin möglichst kleine ScreenShots für die InfoBase zu erhalten.

Was kann Sigma?

Sigma steht für Simple Grafik MAnipulation Tool und ist in der Lage, ganz bewusst bestimmte GEOS-Grafik-Formate zu erzeugen. Man hat also Kontrolle darüber, wie groß die Write-Datei später werden soll. Sigma habe ich für mich selber als Werkzeug programmiert, entsprechend ist die Benutzung nicht so ausgefeilt. Außerdem habe ich den 16-Farb-Modus nicht benötigt, folglich kann Sigma kein 16-Farb-Bilder erzeugen (ein Manko, dass ich mit Blick auf die aktuelle Diskussion vielleicht beheben sollte). Der Haupteinsatzzweck in der jetzigen Form ist für mich persönlich:

  1. Farbbilder dithern, dass sie auf einem s/w-Ausdruck gut aussehen (klappt ganz prima)
  2. Bilder komprimieren, damit die Dateigröße der Write-Datei (bei mir i.a. Help-Files) verkleinert wird.

 
Hallo Leute, es scheint hier doch einige Verwirrung um dpi, Pixel, Grafikdateiformate und Grafikspeicherung zu geben. Daher hier mal die Sicht eines Programmierers - und damit die Sicht des Computers - auf diese Dinge. Ich bin mir dabei bewusst, dass ein Fotograf oder Künstler einige der Dinge aus einem anderen Blickwinkel heraus sieht, aber wenn man verstehen will, warum beim Arbeiten mit Grafiken am Computer dies oder das (nicht..) passiert, dann muss man verstehen, was die Rechenmaschine tut. Auch wenn es teilweise trivial ist, ich mache es vollständig, um eventuellen Missverständnissen aus dem Weg zu gehen.

1. Grafikformat im Sinne von Grafikdateiformat

Das ist die Art und Weise, wie die Grafikdaten auf der Festplatte liegen. Z.B. 8 oder 24 Bit pro Pixel
(= 256 Farben oder TrueColor), von oben nach unten (z.B. PCX) oder von unten nach oben (z.B.BMP), Zeilenweise in der Form rot/grün/blau - rot/grün/blau usw (BMP) oder erst alle roten, dann die blauen und zum Schluss die grünen Pixel (PCX), mit oder ohne Kompression und dergleichen mehr.

Das wichtige dabei ist:

  • Egal in welchem Dateiformat die Daten vorliegen, die Bildinformation bleibt gleich, wenn man eine Konvertierung (z.B. von PCX nach BMP) macht. Vorausgesetzt, man ändert nicht die Farbtiefe.
  • GEOS nutzt seine eigene Art und Weise, die Daten abzuspeichern, (sie ist BMP sehr ähnlich). Dabei gibt es die Möglichkeit, mit und ohne Kompression zu speichern, so dass das gleiche Bild unterschiedlich viel Platz verbrauchen kann.

Tipp von msgeo: Abspeichern im Hintergrund-Format verringert die Datengröße, weil Jens-Michael die Kompression aktiviert hat.

2. Grafikimport

Darunter versteht man den Prozess, ein extern auf der Platte rumliegendes Bild in das GEOS-Interne Format umzuwandeln. Das machen spezielle "Importfiler", bei Gonzo sind das die Grafik-Libraries.

alexZOP: Es ist also egal, aus welchem Dateiformat du die Grafiken nach GEOS importierst, die Datengröße in GEOS ist immer gleich. Es ist eben so wie es ist und ein Bild wird nicht "kleiner" nur weil es in GeoWrite integriert wird. Das mit der Grafikebene ist wohl in etwa so, dass dort Grafiken aller Art einfach "auf dem Textblatt angeheftet werden".

Rainer: Beides richtig.

Jörg: Viele JPEG-/BMP-/Tiff-Bilder lassen sich relativ problemlos mit DOS-/Windows-/Linuxprogrammen in ein 256-Farbenbild umwandeln (z.B. ins GIF-Format). Das spart Speicherplatz im Dokument.

Rainer: Missverständlich. GIF spart nur Platz gegenüber z.B. PCX, nicht mehr nachdem es in GEOS importiert ist. Sparen tut die Reduktion von TrueColor auf 256 Farben - in welchem Format du das zwischenspeicherst oder ob du es gleich in GEOS machst (mit Sigma), ist wurscht.

3. Grafikgröße (Pixel, Speicherbedarf)

Für den Computer gibt es nur eine sinnvolle Einheit: Pixel.

Jede Grafik (Foto...) stellt für den Computer eine rechteckige Anordnung von Bildpunkten (Picture Elements - Pixel) dar. Nicht mehr und nicht weniger. Für jeden Bildpunkt wird nun eine bestimmte Menge Speicher benötigt. Bei Schwarz-Weiss-Grafiken ein Bit, bei 256-Farbgrafiken 1 Byte und bei TrueColor-Grafiken 3 Byte. Ein 800x600 Pixel gro\337es Foto benötigt also 800x600x3 Byte = 1,44 Megabyte. Nicht mehr und nicht weniger. Eine gleich große Schwarz-Weiss-Grafik benötigt nur 800x600/8 = 60 kByte, als 256-Farbgrafik brauchst du 800x600x1 Byte = 480 kByte.

Da Bilder oft redundante Informationen enthalten, kann man versuchen, sie zu komprimieren. Bei Schreenshots und Scans von Texten ( --> @msgeo) geht das ganz gut, bei richtigen Fotos ist das eher aussichtslos. Im Extremfall wird die Datenmenge sogar noch vergrößert.

4. Grafikgröße (dpi)

Was der Computer bisher nicht weiß: Wie groß soll das Bild auf dem Papier werden? Also in cm (oder wie unsere amerikanischen Freunde sagen: in Inch) Deswegen kann man jedem Bild noch eine "Auflösung" in dpi (dot per inch = Bildpunkte pro Zoll) zuordnen. Das GEOS-interne Format kann damit umgehen, einige Dateiformate auch, andere nicht (die kennen nur Pixel). Der Computer steht jetzt vor der Aufgabe, das Bild auf dem Bildschirm und auf dem Papier in "gleicher Größe" erscheinen zu lassen, auch dann, wenn es gar keine dpi-Informationen hat. Die Lösung ist, dem Bildschirm eine "Auflösung" von 72 dpi zuzuordnen. Bilder mit 72 dpi werden also so dargestellt, dass jeder Bildpunkt des Bildschirms ein Pixel des Bildes bekommt. Damit hat man die optimale Darstellung. Genau aus diesem Grund importiert GONZO alle Bilder mit 72 dpi. Gonzo ist eine Grafik-BETRACHTER.

5. Richtige Bildgröße und dpi

Ein Bild mit 320x200 Pixeln mit 72 dpi ist also auf dem Schirm (beim einfügen in GeoWrite) 11,3 cm breit. Was passiert, wenn man das ganze auf einem Drucker mit 300 dpi ausdruckt? Ganz einfach: GEOS nutzt für jedes Pixel des Bildes 300/72 = 4,16 Pixel des Druckers. Damit ist das Bild auch auf dem Drucker 11,3 cm breit. Eine A4-Seite ist 20 cm = 7,87 Zoll breit. Bei 72 dpi sind das 566 Pixel. Unser 800x600 Foto von oben ist aber 800 Pixel breit und ragt deshalb bei 72 dpi zunächst über die A4 Seite hinaus, da es 800/72 = 11,1 Zoll = 28,2 cm breit ist. Das sind 28,4 Pixel (800/28,2 = 28,4) auf jeden Zentimeter. Drucke ich es jetzt, passt es nicht auf die Seite.

Und nun beginnen die Probleme. Der GEOS-User (und jeder normale Mensch) fasst das Foto mit der Maus an einer Ecke und zoomt es solange, bis es auf die Seite passt. Nehmen wir an, wir haben es um den Faktor 2 verkleinert. Damit ist es zwar immer noch 800 Pixel, aber nur noch 14,1 cm breit. Das sind schon 56,7 Pixel auf jeden Zentimeter bzw. auf amiländisch: 144 Pixel pro Zoll (dpi). Das Bild hat aber noch immer eine "Auflösung" von 72 dpi (so steht es in den Bilddaten im Speicher), aber zusätzlich einen "Skalierungsfaktor" von 0,5.

Drucke ich das Bild jetzt auf einem 300 dpi-Drucker aus, muss ich jedem Pixel des Bildes nur noch 2 Punkte des Druckers zuordnen. Zum Glück macht GEOS das für mich.

Zwischen-Fazit für mich als Programmierer:

Die Angabe in dpi ist eigentlich überflüssig. Denn manuelle Vergrößerung / Verkleinerung und Änderung der "Auflösung" in dpi sind zwei verschiedene Methoden, die das Gleiche zu erreichen: Das Bild auf dem Papier in die von mir gewünschte Größe zu bringen. Beide Werte ändern die Anzahl der zum Speichern des Bildes benötigten Bytes nicht, aber sie ändern, wie groß das Bild auf dem Papier (bzw. auf dem Schirm) wird.

Anmerkung: Ich habe nicht gesagt, dass dpi-Werte an sich sinnlos sind, aber für einen Programmierer machen sie bloß zusätzlich Arbeit.

6. Computer und dpi

Nun kommen aber die Fotografen und andere nicht-Computer-Leute daher und beharren auf ihren dpi-Werten. Sie wollen ein 6,8x5,1 cm großes Bild mit - sagen wir - 300 dpi einscannen. Und sie wollen, dass das Bild nach dem Einkleben in GeoWrite auch sofort 6,8x5,1 cm groß ist. Das ist ein sehr vernünftiger Wunsch, die Konsequenzen führen aber immer wieder zu Problemen im Verständnis.

6,8x5,1 cm mit 300 dpi sind nämlich 800x600 Pixel (1 Zoll=2,54cm, 6,8cm=2,68Zoll). Wie oben beschrieben, wäre das Bild dann "eigentlich" 28,2 cm breit. Die Lösung: Ich ordne dem Bild jetzt 300 dpi zu, anstelle 72. Damit stellt GEOS das Bild gleich im richtigen Maßstab verkleinert dar und es wird 6,8 cm breit. Auf dem Bildschirm werden nun immer 4 Pixel des Bildes einem Bildschirmpunkt zugeordnet (eigentlich sind es 16, wenn man die y-Richtung mit berücksichtigt), auf dem 300 dpi-Drucker aber jedem Druckerpunkt genau ein Pixel des Bildes.

So weit so gut, nur 800x600x3 Byte sind eben schlappe 1,44 Megabyte. Und die musst du im Dokument gespeichert haben.

7. Wie reduziert man die Datenmenge?

  • Vernünftige Auswahl der Farbtiefe. Schreenshots im Schwarz-Weiss-Modus oder im 16-Farb-Modus machen, Fotos auf 256 Farben dithern, falls möglich. Wenn es auf den Ausdruck ankommt, ausprobieren was besser ist: Angepasste Farbpalette mit irgendwelchen Windows-Programmen (kostet 1 kb Speicher pro Bild für die Palette) oder GEOS-Palette mit Sigma.
  • Auf die Bildgröße in Pixeln achten, die bestimmt den Speicherplatz. Die dpi-Zahl ist dabei unerheblich. GONZO zeigt immer die Größe in Pixeln an und importiert das Bild mit 72 dpi.

    Verändern der Bildgröße mit der Maus ändert den Speicherbedarf nicht, wohl aber die Qualität der Ausdrucks. Deswegen gibt es hier kein allgemeingültiges Optimum.

  • Bilder komprimieren (Sigma!). Bei Bildern mit gleichfarbigen Flächen bringt das viel, bei Fotos eher nichts. Ausprobieren!
  • Für Diagramme, Organigramme und dergleichen: Keine eingescannten Bitmaps verwenden, sondern alles manuell unter GeoDraw zeichnen. Das ist am kleinsten!
  • Beim Einscannen von Fotos eine möglichst kleine dpi-Zahl verwenden. Wie viel das ist, muss man ausprobieren. Aber je weniger dpi, desto weniger Pixel, desto weniger Speicherbedarf.
So, ich hoffe, das bringt jetzt mehr Klarheit als Verwirrung und war nicht für alle Leser ein "alter Hut".

Rainer
 

Zum Anfang der Seite     Zuletzt geändert 14.05.14 Mütze