Pro/Contra .PNG?

[Lactrik]

Hi zusammen,

wenn ich mich nicht irre, wurde doch PNG ursprünglich mal als Web-Grafikstandard entwickelt und sollte JPEG/GIF (oder eines von beiden) ersetzen, oder?

Lohnt es sich überhaupt, PNG zu verwenden? Im Prinzip hat man mit JPEG und GIF doch alles, was man benötigt zu einem relativ kleinen Speicherplatzverbrauch.

Grüsse
Lars

[Philipp Hasenfratz]

Halihallo Lactrik

wenn ich mich nicht irre, wurde doch PNG ursprünglich mal als Web-Grafikstandard entwickelt und sollte JPEG/GIF (oder eines von beiden) ersetzen, oder?
Lohnt es sich überhaupt, PNG zu verwenden? Im Prinzip hat man mit JPEG und GIF doch alles, was man benötigt zu einem relativ kleinen Speicherplatzverbrauch.

http://www.libpng.org/pub/png/pngintro.html, sollte einige Fragen beantworten
können.

Viele Grüsse

Philipp

[Cyx23]

Hallo,

wenn ich mich nicht irre, wurde doch PNG ursprünglich mal als Web-Grafikstandard entwickelt und sollte JPEG/GIF (oder eines von beiden) ersetzen, oder?

PNG hat vielleicht noch ein paar Features -Transparenz?- welche aber von den
meisten Browsern nicht unterstützt werden, und Animation ist wohl auch etwas
für GIF.

Im Prinzip hat man mit JPEG und GIF doch alles, was man benötigt zu einem relativ kleinen Speicherplatzverbrauch.

Sieht so aus, gute und farbenreiche PNGs werden meist zu gross, ein Grund
für PNG waren wohl irgendwelche Patentrechte an GIFs bzw. d. math. Grundlagen,
vielleicht postet ja noch jemand hier wann/ob das abgelaufen ist, und ob es
eher ein Problem der Grafik-Softwarehersteller sein dürfte.

Grüsse

Cyx23

[Thomas W.]

Hallo,

PNG hat vielleicht noch ein paar Features -Transparenz?- welche aber von den meisten Browsern nicht unterstützt werden, und Animation ist wohl auch etwas für GIF.

Naja, die meisten Browser bezieht sich hier auf den IE, die anderen grossen sind da schon soweit. Animation kann PNG aber nicht, das ist richtig.

Im Prinzip hat man mit JPEG und GIF doch alles, was man benötigt zu einem relativ kleinen Speicherplatzverbrauch.
Sieht so aus, gute und farbenreiche PNGs werden meist zu gross, ein Grund für PNG waren wohl irgendwelche Patentrechte an GIFs bzw. d. math. Grundlagen, vielleicht postet ja noch jemand hier wann/ob das abgelaufen ist, und ob es eher ein Problem der Grafik-Softwarehersteller sein dürfte.

Nein, bei *gleicher* Qualitaet sind PNGs normalerweise kleiner als GIFs; im Normalfall wird man aber die Qualitaet bei PNGs hoeher setzen (mehr als 256 Farben) und dann werden die auch groesser.
Das Patent-Problem ist in der Tat Sache des Herstellers, allerdings stolpert auch jeder drueber, der Bilder "on the fly" generieren lassen will. Die dazu benutzten Libs der offenen Sprachen koennen kein GIF (aus obigen Gruenden).

Gruss
Thomas

[Cyx23]

Hallo Thomas,

Naja, die meisten Browser bezieht sich hier auf den IE, die anderen grossen sind da schon soweit. Animation kann PNG aber nicht, das ist richtig.

"den IE", sind ja wohl über 80% der Besucher, soviel zur Groesse.

Im Prinzip hat man mit JPEG und GIF doch alles, was man benötigt zu einem relativ kleinen Speicherplatzverbrauch.
Sieht so aus, gute und farbenreiche PNGs werden meist zu gross, ein Grund für PNG waren wohl irgendwelche Patentrechte an GIFs bzw. d. math. Grundlagen, vielleicht postet ja noch jemand hier wann/ob das abgelaufen ist, und ob es eher ein Problem der Grafik-Softwarehersteller sein dürfte.
Nein, bei *gleicher* Qualitaet sind PNGs normalerweise kleiner als GIFs; im Normalfall wird man aber die Qualitaet bei PNGs hoeher setzen (mehr als 256 Farben) und dann werden die auch groesser.

Es gibt m.E. einen ganz schmalen Bereich wo in wenigen Fällen PNG mal
5% bis 10% kleiner sind als GIF oder JPEG, und das typischerweise bei
Farbreduzierung auf 16-32 Farben, sonst ist GIF oder JPEG besser/kleiner
(bzw. beides).

Das Patent-Problem ist in der Tat Sache des Herstellers,

Ich hatte vermutet das diese Patente vielleicht sowieso schon abgelaufen
sind, und der Punkt ist schon wichtig um zu verstehen warum PNGs früher
so unterstützt wurden obwohl die dann Qualität enttäuscht, wenn man
deutlich erkennbare Verbeserungen erwartet hat.

Grüsse

Cyx23

[Christian Seiler]

Hallo Cyx,

Es gibt m.E. einen ganz schmalen Bereich wo in wenigen Fällen PNG mal
5% bis 10% kleiner sind als GIF oder JPEG, und das typischerweise bei
Farbreduzierung auf 16-32 Farben, sonst ist GIF oder JPEG besser/kleiner
(bzw. beides).

Bisher war fast jedes PNG, das ich aus einem maximal komprimiertem GIF erstellt habe, kleiner als das GIF. (Farbtiefe _nicht_ verändert) Du darfst mir gerne eine GIF-Datei zuschicken und ich werde sie als PNG neu komprimieren und dann können wir ja sehen, wer Recht hat. (Du kannst bei der von mir erstellten PNG-Datei dann gerne auch überprüfen, welche Farbtiefe sie hat und sehen, ob ich was daran manipuliert habe)

Übrigens waren einige PNGs nur 70% so groß wie die entsprechenden GIFs.

Ich hatte vermutet das diese Patente vielleicht sowieso schon abgelaufen
sind,

Das dauert noch ein paar Jahre.

und der Punkt ist schon wichtig um zu verstehen warum PNGs früher
so unterstützt wurden obwohl die dann Qualität enttäuscht, wenn man
deutlich erkennbare Verbeserungen erwartet hat.

Die Qualität enttäuscht _nicht_. PNG kann jetzt bis auf Animationen alles das, was GIF vorher konnte - und das bei niedrigerer Dateigröße. (Ich gehe jetzt vom IE aus, wenn man den Mozilla nimmt, der ja noch zusätzlich MNG und PNG+Alpha unterstützt, dann kann PNG sogar noch mehr, aber Mozilla kann man noch nicht als Maß der Dinge sehen, zumindestens nicht bei 80% IE, wie Du sagst)

Christian

[Michael Schröpl]

Hi Christian,

Bisher war fast jedes PNG, das ich aus einem maximal komprimiertem GIF erstellt habe, kleiner als das GIF. (Farbtiefe _nicht_ verändert)

im Prinzip stimme ich Dir zu - sofern das GIF eine Mindestgröße von ungefähr 500 Bytes hat.
Bei sehr kleinen GIFs ist offenbar der Grundoverhead von PNG ausschlaggebend - deshalb habe ich einige Markierungs-Bildchen auf GIF belassen, weil sie in PNG vielleicht 200 Bytes hätten, in GIF aber nur 80 oder so ähnlich.

Versuch doch mal, '<img src="http://www.schroepl.net/_img/extern.gif" border="0" alt="">' als PNG kleiner zu machen ...

Übrigens waren einige PNGs nur 70% so groß wie die entsprechenden GIFs.

ACK: 80% ist auch nach meiner Erfahrung eine übliche Quote bei größeren GIFs, 70% sind durchaus möglich.

Viele Grüße
      Michael

[Christian Seiler]

Hallo Michael,

Versuch doch mal, '<img src="http://www.schroepl.net/_img/extern.gif" border="0" alt="">' als PNG kleiner zu machen ...

Das kleinste, was ich hinbekomme, sind 139 Bytes. (73 Original-GIF) Naja, aber diese paar Byte habe ich locker bei anderen Graphiken wieder raus. Außerdem sind meine Graphiken meist größer als 200 Bytes. ;-)

FYI: <img src="http://www.christian-seiler.de/temp/extern.png" border="0" alt="">

Christian

[Cxy32]

Hallo,

wichtig ist doch zunächst der Vergleich zu GIF _und_ JPEG.

Ich hab mir nochmal ein älteres Projekt angeschaut bei welchem ich erstmal
alles mit PNG versucht hatte, da hat sich gezeigt dass gleich grosse JPEG
meist deutlich besser waren, sogar ohne besonders hochwertige Software mit
selektiven Komprimierungen.

Dann die m.E. falsche Behauptung PNGs wären kleiner als GIFs.

Zur Grösse von PNGs habe ich jetzt mal ein GIF, 140x300px, 32/256 Farben,
7589 Bytes, in ein PNG umgewandelt, und 9296 Bytes erhalten, bei 256 Farben,
und interlaced. Ohne interlaced 8126 Bytes, also immer noch nicht kleiner
als das Gif.

Das 2k Logo oben links xweb.gif wird übrigens, zumindest bei meiner
Software, als PNG auch grösser.

Grüsse

Cyx23

[Christian Seiler]

Hallo Cyx,

wichtig ist doch zunächst der Vergleich zu GIF _und_ JPEG.

Zu GIF ja, zu JPEG nein. PNG kann zwar so viele Farben wie JPEG anzeigen, aber für Fotos ist PNG total ungeeignet. Wer hat denn hier so etwas behauptet?

Ich hab mir nochmal ein älteres Projekt angeschaut bei welchem ich erstmal
alles mit PNG versucht hatte, da hat sich gezeigt dass gleich grosse JPEG
meist deutlich besser waren, sogar ohne besonders hochwertige Software mit
selektiven Komprimierungen.

Das wundert mich nicht.

Dann die m.E. falsche Behauptung PNGs wären kleiner als GIFs.

Michael hat das einzige Beispiel genannt, in dem das der Fall ist. (sehr kleine Dateien) Bei größeren Dateien ist PNG

Zur Grösse von PNGs habe ich jetzt mal ein GIF, 140x300px, 32/256 Farben,
7589 Bytes, in ein PNG umgewandelt, und 9296 Bytes erhalten, bei 256 Farben,
und interlaced. Ohne interlaced 8126 Bytes, also immer noch nicht kleiner
als das Gif.

Ohne das GIF respektive das PNG sehen zu können, ist diese Information wertlos.

Das 2k Logo oben links xweb.gif wird übrigens, zumindest bei meiner
Software, als PNG auch grösser.

Mein GIMP komprimiert es mir ohne Interlacing auf exakt 70 Bytes wengier runter:

<img src="http://www.christian-seiler.de/temp/xweb.png" border="0" alt="">

(Mit Interlacing sinds knapp 2,4KB, also 200 Bytes mehr als das GIF - da ist noch ein kleiner Vorteil für GIF drin)

Wie gesagt: ich habe das Ding überhaupt nicht optimieren lassen, sondern nur in GIMP den Kompressionsregeler auf Maximum gestellt - ich bin mir sicher, dass das SELFHTML-GIF optimiert ist und ich bin mir (fast) genauso sicher, dass ich mit etwas Optimierung das PNG auch mit Interlacinng unter die GIF-Größe drücken kann.

Christian

[Cyx23]

Hallo Christian,

wichtig ist doch zunächst der Vergleich zu GIF _und_ JPEG.

Zu GIF ja, zu JPEG nein. PNG kann zwar so viele Farben wie JPEG anzeigen, aber für Fotos ist PNG total ungeeignet. Wer hat denn hier so etwas behauptet?

da man JPEG auch oft für Logos sinnvoll einsetzen kann, liegt es doch
nahe, und irgendwo (Ausgangsposting?) war doch überlegt worden ob
GIF/JPEG alles abdecken oder beide erstzbar wären o.ä..

Michael hat das einzige Beispiel genannt, in dem das der Fall ist. (sehr kleine Dateien) Bei größeren Dateien ist PNG

M.E. nicht immer nur _sehr_ kleine Dateien.
Eher müssen PNGs oft vmtl. über 40-50k (Gif) sein damit sie kleiner
als Gif sein können, und das nur ohne interlacing.
Bei steigender Grösse wird aber Jpeg oft deutlich
brauchbarer bzw. die Bilder wären sowieso zu gross.

Mein GIMP komprimiert es mir ohne Interlacing auf exakt 70 Bytes wengier runter:

Die Algorhytmen sind doch gleich, wird da bei Gimp an der internen Beschreibung
gespart?

Grüsse

Cyx23

[Christian Seiler]

Hallo Cyx,

da man JPEG auch oft für Logos sinnvoll einsetzen kann, liegt es doch
nahe, und irgendwo (Ausgangsposting?) war doch überlegt worden ob
GIF/JPEG alles abdecken oder beide erstzbar wären o.ä..

Ja. Aber Fotos nicht. Und Bei Logos ist PNG _eindeutig_ die bessere Wahl.

M.E. nicht immer nur _sehr_ kleine Dateien.

nein.

Eher müssen PNGs oft vmtl. über 40-50k (Gif) sein damit sie kleiner
als Gif sein können, und das nur ohne interlacing.

40-50...? Ich würde eher sagen 4-5k, wenn nicht gar drunter. Du schuldest mir immer noch ein GIF, das kleiner als ein PNG ist. (Das Interlacing beim SELF-Logo zählt nicht, da 2k so klein sind, dass man es da verschmerzen kann - ab 5k zählt Interlacing aber - IMHO natürlich)

Die Algorhytmen sind doch gleich,

Du meinst, die die GIMP und Dein Programm verwendet? Keine Ahnung, ich tippe jetzt mal auf »nein«. (Entscheidend ist ja nicht, wie komprimiert wird, sondern wie man es in eine Form bringen kann, dass es der Dekompressionsmechanismus versteht - und da gibt es sicherlich mehrere Möglichkeiten, manche effizienter, manche ineffizienter)

wird da bei Gimp an der internen Beschreibung gespart?

Keine Ahnung.

Ich habe folgende Einstellungen verwendet:

<img src="http://www.christian-seiler.de/temp/gimp-kompression.png" border="0" alt="">

- Hintergrundfarbe unnötig: Transparent
 - Gamma: kapiert eh' noch kein Browser
 - Ebenenversatz: was auch immer das sein mag...
 - Auflösung: wenn ich die PPI-Zahl speichere, dann sind es exakt 11 Bytes mehr, also ohne Interlacing immer noch weniger als GIF.
 - Zeit der Erstellung? - brauche ich nicht...

Christian

[Cyx23]

Hallo Christian,

Ich habe folgende Einstellungen verwendet:

danke für die Infos, m.E. ist der Algorhytmus tatsächlich gleich, und
der Hauptunterschied ist der Kompressionsgrad meiner Software, der wird
wohl nur bei "6" liegen, was in der Dateigrösse z.B. 5% Unterschied zu
Deinen "9" ausmacht. Da muss ich dann evtl. etwas suchen, denn das betr.
Beispiel-Gif -nochmnals mit anderer Software exportiert- hat als PNG bei
9% 7524 Bytes, als Gif 7598, wobei aber bei unter 1% Grössenunterschied
das Gif vorzuziehen ist weil es m.E. deutlich schneller aufbaut als PNG,
besonders bei einem Kompressionsgrad von 9.

Grüsse

Cyx23

[Michael Schröpl]

Hi Cyx23,

Michael hat das einzige Beispiel genannt, in dem das der Fall ist. (sehr kleine Dateien) Bei größeren Dateien ist PNG
M.E. nicht immer nur _sehr_ kleine Dateien.
Eher müssen PNGs oft vmtl. über 40-50k (Gif) sein damit sie kleiner
als Gif sein können

Ich habe mehrere hundert GIFs nach PNG konvertiert, und bei mir lag die Grenze bei etwa 500 bytes. Darüber wurde das PNG _immer_ kleiner als das GIF.

Mein GIMP komprimiert es mir ohne Interlacing auf exakt 70 Bytes wengier runter:
Die Algorhytmen sind doch gleich

Hat jemand den RFC dazu gelesen?

Ich glaube mich vage daran zu erinnern, daß die Algorithmen eben _nicht_ gleich sind, weil GIF nur Zeilen mit einer Art run length encoding komprimiert, PNG aber in Flächen denken kann.
Wäre meine Erinnerung korrekt, dann müßte es spezielle Fälle geben, bei denen PNG ganz erheblich besser ist als GIF.

Viele Grüße
      Michael

[Michael Schröpl]

Hi Cyx23,

da man JPEG auch oft für Logos sinnvoll einsetzen kann

diese Aussage bezweifele ich.

Ein Logo muß sich meiner Meinung nach dazu eignen, auf ganz verschiedenen Seiten und damit ggf. verschiedenen Hintergründen eingesetzt zu werden - und wie kriege ich ein JPEG transparent?

Viele Grüße
      Michael

[Cyx32]

Hallo Michael,

da man JPEG auch oft für Logos sinnvoll einsetzen kann

diese Aussage bezweifele ich.

Ein Logo muß sich meiner Meinung nach dazu eignen, auf ganz verschiedenen Seiten und damit ggf. verschiedenen Hintergründen eingesetzt zu werden - und wie kriege ich ein JPEG transparent?

Logo und Hintergrundfarbe können doch als Einheit betrachtet werden,
ausserdem klappt es mit der Transparenz ja nur wenn ohne Verlauf
oder Unschärfe Pixel für Pixel gestzt werden kann, sonst gibt es
ja auch bei GIF merkwürde Ränder.
Wenn überhaupt das Wort Logo so streng interpretiert werden muss,
ich meine hier den typischen Anwendungsfall für Gif, kleine
Dateigrösse, farbreduziert, wo manchmal sogar JPEG besser geeignet ist,
allerdings mag es Probleme geben Farbtöne exakt zu treffen usw..

... bei mir lag die Grenze bei etwa 500 bytes. Darüber wurde das PNG _immer_ kleiner als das GIF.

Da kann es zwei Gründe geben warum das bei mir anders ausschaut,
zunächst scheint die bislang von mir eingesetzte Software meist
Komprimierungfaktor 6 statt bei Gimp möglicher 9 zu verwenden
oder interlaced immer zu verwenden.
Besonders ist es aber die aufwändige Farbreduzierung beim GIF.
Ich habe jetzt versuchsweise ein anderes Programm mit 9x und ohne
interlaced getestet,und bei einem schnell erstellten Versuchsgif
kam ich sogar von 38k auf 26k beim PNG, sieht erstmal toll aus, wenn
ich aber ältere GIFs mit aufwändiger Farbreduzierung, um die 8k,
entsprechend getestet habe wurden die teilweise etwas grösser, da spart
PNG höchstens etwas Zeit zum Bearbeiten der Palette, auch nicht schlecht,
aber die Filegrössen unterscheiden sich weniger oder PNGs sind soweit
ich das bislang sehe auch schon mal grösser.

Ich glaube mich vage daran zu erinnern, daß die Algorithmen eben _nicht_ gleich sind, weil GIF nur Zeilen mit einer Art run length encoding komprimiert, PNG aber in Flächen denken kann.
Wäre meine Erinnerung korrekt, dann müßte es spezielle Fälle geben, bei denen PNG ganz erheblich besser ist als GIF.

Ich hatte Algorithmen der verschiedenen Software gemeint, ein 6x PNG
unter Software A ist gleich gross wie ein 6x kompr. von "B".
Grosse Unterschiede können fast nur durch den Komprimierungsfaktor und
interlaced bedingt sein, und nur minimale durch fehlende interne Angaben
o.ä. mögliche Einstellungen.

Grüsse

Cyx32

[Michael Schröpl]

Hi Cyx32,

... bei mir lag die Grenze bei etwa 500 bytes. Darüber wurde das PNG _immer_ kleiner als das GIF.
Da kann es zwei Gründe geben warum das bei mir anders ausschaut,
zunächst scheint die bislang von mir eingesetzte Software meist
Komprimierungfaktor 6 statt bei Gimp möglicher 9 zu verwenden

meinst Du damit den Wert, der z. b. auch bei gzip angegeben werden kann?
Wenn ja (das ist eine verlustfreie Komprimierung), dann habe ich kein Verständnis dafür, wie man auf die Idee kommen kann, bei einer GIF- oder PNG-Datei freiwillig weniger als das Maximum zu nehmen.

Viele Grüße
      Michael

[Cyx23]

Hallo Michael,

meinst Du damit den Wert, der z. b. auch bei gzip angegeben werden kann?
Wenn ja (das ist eine verlustfreie Komprimierung), dann habe ich kein Verständnis dafür, wie man auf die Idee kommen kann, bei einer GIF- oder PNG-Datei freiwillig weniger als das Maximum zu nehmen.

manche Software wie ältere Photopaint haben wenn ich nichts übersehen habe
gar keine Einstellung und eh nur 6x, also unfreiwillig.
Freiwillig vielleicht auch, denn vermutlich leidet die Performance beim
Betrachter sehr stark wenn man wegen 5% kleinerer Files 9x nimmt
(womöglich sind GIFs auch schneller anzuzeigen).
Könnte u.U. bei 200 Vorschaubildchen in einer Tabelle auffallen, je nach
CPU o.ä., oder die Performance beim Server wenn Bilder generiert werden,
auch wenn jedes einzelne PNG vielleicht nur tausendstel mehr braucht?

Grüsse

Cyx23

[Christian Seiler]

Hallo Cyx,

Könnte u.U. bei 200 Vorschaubildchen in einer Tabelle auffallen,

Rechnung:

200 * 10 KB (6x-PNG[tm]) => 2 MB
200 * 9 KB  (9x-PNG[tm]) => 1,8 MB

_Gerade_ dann ist CPU das geringste Problem. (der Autor sollte sich lieber überlegen, warum er die Bilder nicht auf mehrere Seiten aufteilt)

Mal im Ernst: Wenn auf einer Seite 30 unterschiedliche Graphiken sind, dann fällt das überhaupt nicht ins Gewicht. Und bei mehr als 50 unterschiedlichen Graphiken sollte sich der Autor wirklich mal fragen, ob er was falsch gemacht hat.

Christian

[Michael Schröpl]

Hi Cyx23,

meinst Du damit den Wert, der z. b. auch bei gzip angegeben werden kann?
Wenn ja (das ist eine verlustfreie Komprimierung), dann habe ich kein Verständnis dafür, wie man auf die Idee kommen kann, bei einer GIF- oder PNG-Datei freiwillig weniger als das Maximum zu nehmen.
Freiwillig vielleicht auch, denn vermutlich leidet die Performance beim
Betrachter sehr stark wenn man wegen 5% kleinerer Files 9x nimmt

ganz im Gegenteil: Die der Aufwand der Dekomprimierung ist beispielsweise bei gzip direkt abhängig von der Dateigröße (weil einfach nur Codes gegenüber einer Tabelle umgesetzt werden müssen).
Besser komprimierte Dateien sind also sogar _schneller_ anzeigbar.

Der Aufwand zum _Komprimieren_ dagegen ist abhängig von der Komprimierungsstufe (und damit von der Intelligenz bei der Suche nach der effizientesten Codierung) - aber gerade den leistet man eben nur ein einziges Mal.

Viele Grüße
      Michael

[Cyx23]

Hallo Michael,

ganz im Gegenteil: Die der Aufwand der Dekomprimierung ist beispielsweise bei gzip direkt abhängig von der Dateigröße (weil einfach nur Codes gegenüber einer Tabelle umgesetzt werden müssen).
Besser komprimierte Dateien sind also sogar _schneller_ anzeigbar.

besser als ich erwartet habe, ich dachte das Bild müsste zur Anzeige mehrfach berechnet werden.

Der Aufwand zum _Komprimieren_ dagegen ist abhängig von der Komprimierungsstufe (und damit von der Intelligenz bei der Suche nach der effizientesten Codierung) - aber gerade den leistet man eben nur ein einziges Mal.

Momentan scheint der Aufwand die Suche der effizientesten Software zu sein,
da hat sich ja in den letzten Jahren doch etwas getan, aber die verschiedenen
Programme scheinen alle nicht perfekt zu sein, Gimp will bei mir irgendwie
nicht laufen "fehlende export lib ", und andere Programme und Tools scheinen
unerwarteterweise immer nur ein paar PNGs wirklich kompakt hinzukriegen, ich
müsste also möglichst mehrfach mit verschiedener Software PNGs erstellen
und dann die Grössen vergleichen, dann gibt es noch "tweakPNG" um ggf. dpi
zu entfernen, spart immerhin ganze 9 Byte :)

Grüsse

Cyx23

[Michael Schröpl]

Hi Cyx23,

Momentan scheint der Aufwand die Suche der effizientesten Software zu sein,

hm ... ich habe dafür immer das uralte PaintShop Pro 4.12 verwendet ... ich komme allerdings an die von Christian genannten Zahlen nicht ganz heran.

Viele Grüße
      Michael

[Christian Seiler]

Hallo Michael, Hallo Cyx,

hm ... ich habe dafür immer das uralte PaintShop Pro 4.12 verwendet ... ich komme allerdings an die von Christian genannten Zahlen nicht ganz heran.

pngcrush leistet sogar noch etwas bessere Dienste als GIMP:
http://pmt.sourceforge.net/pngcrush/

Ich bin mit folgenden Einstellungen am besten Klargekommen, zumindest beim SELF-Bild: (das habe ich nochmal um eine Kleinigkeit reduzieren können)

pngcrush -reduce -w 1024 -l 9 alt.png neu.png

Eventuell kannst Du noch am -w-Wert herumspielen, ich habe zwar keinen laut pngcrush --help gültigen Wert angegeben (nur 32, 16, 8, 4, 2, 1 und 512 sind scheinbar erlaubt) aber mit 1024 konnte ich nochmal eine Verbesserung erzielen (naja, ein paar Bytes ;)) und die Graphiken »funktionieren«. Bei größeren Bildern kann man da eventuell mit einem anderen Wert noch mal was rausholen.

Christian

[Cyx23]

Hallo Christian,

Ich bin mit folgenden Einstellungen am besten Klargekommen, zumindest beim SELF-Bild: (das habe ich nochmal um eine Kleinigkeit reduzieren können)

pngcrush -reduce -w 1024 -l 9 alt.png neu.png

also offenbar erübrigt sich dann Gimp speziell für PNG?

'pngcrush' muss ich mit Deinen Einstellungne so nochmal probieren, ich hatte
u.a. auch mit pngcrush 1.510 unerwartet etwas grössere Files als mit einer
harmloseren Software, und dann gibt es noch 'tweakpng', 'pngrewrite'...

Grüsse

Cyx23

[Christian Seiler]

Hallo Cyx,

also offenbar erübrigt sich dann Gimp speziell für PNG?

Für PNG ja. Aber für andere Dinge kann ich ohne GIMP nicht mehr leben. *scnr*

ich hatte
u.a. auch mit pngcrush 1.510 unerwartet etwas grössere Files als mit einer
harmloseren Software,

Dann lag das an den Einstellungen. _Alle_ PNGs, die GIMP exportiert hat, hat pngcrush (die aktuelle Version) bei mir um ca. 10-40 Bytes kleiner gemacht.

und dann gibt es noch 'tweakpng', 'pngrewrite'...

Genau. :)

Christian

[Mathias Bigge]

Hi Lactrik,

wenn ich mich nicht irre, wurde doch PNG ursprünglich mal als Web-Grafikstandard entwickelt und sollte JPEG/GIF (oder eines von beiden) ersetzen, oder?

Ja, PNG ist vielleicht tasächlich der zukünftige Standard für Grafiken im Internet. Es ist tatsächlich eine der Schweinereien von Microsoft, dass sie das nicht frühzeitig in die Volksbrwoser eingebaut haben. Per Quicktime-Plugin kann man's dann trotzdem sehen, dauert aber lange, unterstützt nicht die Alphakanal-Trnasparenz und bietet die übliche Ödnis. Also: Zur Zeit besser noch nicht einsetzen.

Lohnt es sich überhaupt, PNG zu verwenden? Im Prinzip hat man mit JPEG und GIF doch alles, was man benötigt zu einem relativ kleinen Speicherplatzverbrauch.

Es gibt einige klare Vorteile von PNG:
a) Kombination der Vorteile von GIF und PING, etwa durch die gute Komprimierung und Transparenz von GIF plus der hohen Farbenanzahl von JPEG
b) Die Transparenz ist deutlich besser gelöst als bei GIF. Bei GIF muss man, wenn man keine zackigen Kanten haben will, ein Antialiasing, also eine Kantenglättung einsetzen. Wie aber funktioniert das? Die Ränder werden um einige Pixel ergänzt, die zwischen der Kantenfarbe und der Hintergrundfarbe liegen. Diese GIFs sind dann immer nur auf Sites einsetzbar, die eben genau diese Hintergrundfarbe als Background verwenden. Wenn das "transparente" GIF nicht vor einem einfarbigem Hintergrund in der gleichen Farbe liegt, gibts leuchtende Ränder statt Einpassung in die Umgebung. Ein Kreuz, wenn man nur die mit Antialiasing behandelten GIFs zur Verfügung hat, dann muss man das Ganze nachbauen oder das Aliasing auf Pixelebene bearbeiten, beides sehr schöne Tätigkeiten, die jeden, der häufiger Grafiken bearbeitet, schonmal ein paar Stunden gekostet hat. Ich hatte zuletzt das Vergnügen mit einigen Logos von Ministerien des Landes NRW.... PNG hat 256 Transparenzstufen statt einer wie GIF und kann damit wunderbar vor jedem Hintergrund mit echter Transparenz eingesetzt werden.
c) PNG besitzt eine Gamma-Korrekturfunktion. Tatsächlich stellen Mac und Windose die Helligkeit von Grafiken verschieden dar, die Windosen tendenziell dunkler, so dass man entweder einen Konpromiss bei der Helligkeit sucht oder auf eine der beiden Welten pfeift. Das kann PNG prinzipiell ausgleichen.
d) PNG ist lizenzfrei, kann also von Open Source Programmen verwendet werden, die Grafiken dynamisch generieren. Ziert sich Microsoft vielleicht deshalb nicht bereit, das Format zu unterstützen?

Probleme bei PNG:
a) Wenn man die Vorteile nutzen will, also etwa eine hohe Farbenzahl oder viele Transparenzstufen nutzt, werden die Grafiken größer, was bei den wachsenden Bandbreiten in Zkunft vielleicht hinnehmbar ist.
b) Ping kann keine Animationen, wobei meiner Meinung nach dort ein proprietäres Format dabei ist, das gute alte Wackelgif abzulösen beginnt, nämlich Flash, auch wenn's hier im Forum einigen nicht gefällt.
c) Viele Billigtools unterstützen nicht alle Möglichkeiten von PNG wirklich zu verstehen, was man mit Alphakanälen alles so machen kann, ist nicht ganz trivial.

Viele Grüße
Mathias Bigge

[Christian Seiler]

Hallo Mathias,

b) Ping kann keine Animationen, wobei meiner Meinung nach dort ein proprietäres Format dabei ist, das gute alte Wackelgif abzulösen beginnt, nämlich Flash, auch wenn's hier im Forum einigen nicht gefällt.

Es _gibt_ animierte PNGs, die heißen bloß MNGs. Diese MNGs sind auch Pixelformate wie GIF nur unterstützen diese auch andere Effekte wie das »scrollen« von Bildern (Bei GIF musste man das manuell nachbilden) und das einfügen von JPGs, um Fotos zu »animieren«. Nachteil: AFAIK kann das im Moment nur der Mozilla.

Flash ist ein Vektorformat, kein Pixelformat. Man kann da zwar auch Pixelgraphiken einfügen, aber prinzipiell ist alles in Flash erst mal Vektor. Außerdem ist Flash scriptbar, was MNGs und GIFs definitiv _nicht_ sind. Außerdem gibt es da noch SVG, daher muss man die Aussage, »Flash beginnt das GIF abzulösen« differenzierter sehen: Das ist einerseits durchaus der Fall, andererseits gibt es auch Bestrebungen, SVG zu etablieren. Man wird sehen, was die Zukunft bringt.

c) Viele Billigtools unterstützen nicht alle Möglichkeiten von PNG wirklich zu verstehen, was man mit Alphakanälen alles so machen kann, ist nicht ganz trivial.

Naja, AFAIK können das inzwischen alle »großen« Graphikprogramme, wie Photoshop, PSP und GIMP. (und letzteres ist kostenlos)

Christian

[Alexander]

Hi,

Das ist einerseits durchaus der Fall, andererseits gibt es auch Bestrebungen, SVG zu etablieren. Man wird sehen, was die Zukunft bringt.

Auch wenn ich vom eigentlichen Thema etwas abdrifte, habe ich aber zu SVG ein paar Rückfragen:

1. Bietet SCG Animationen bzw. ist es über Skripte steuerbar?
2. Wird SVG wirklich als Grafik vom Browser eingebunden (also z.B. per <img src="hallo.svg">) oder setzt es auf Plugins auf?
   Ich glaube mich erinnern zu können, dass für SVG immer noch Plugins erforderlich sind und es von daher zu Problemem kommen kann, wenn man Plugins deaktiviert hat. Grafiken hat wohl kaum jemand deaktiviert...
3. Unterstützt SVG auch 3D oder muss ich da auf VRML zurückgreifen?
4. Wie sieht es mit Texturen aus? Werden Pixel-Texturen und Reflektionen unterstützt?

Viele Grüße...

Alex :)

[Christian Seiler]

Hallo Alex,

Auch wenn ich vom eigentlichen Thema etwas abdrifte, habe ich aber zu SVG ein paar Rückfragen:

Thread-Drift ist hier ausdrücklich erwünscht. :)

1. Bietet SCG Animationen bzw. ist es über Skripte steuerbar?

Ja. In SVG gibt es Animationselemente (die nur sehr einfache Dinge machen können) und außerdem ist es per JavaScript/DOM scriptbar.

http://www.styleassistant.de/tips/tip81.htm

2. Wird SVG wirklich als Grafik vom Browser eingebunden (also z.B. per <img src="hallo.svg">) oder setzt es auf Plugins auf?

Es gibt Mozilla-Builds, (inoffizielle) die direkte SVG-Unterstützung haben. Ich weiß allerdingst nicht, ob die <img> unterstützen. Normalerweise binden man SVG per Object ein:

<object data="..." width="..." height="..." type="image/svg+xml">

Wenn Du keinen solchen Mozilla-Build hast, dann gibt es immer noch den Adobe SVG Viewer als Plugin. Der macht aber unterm Mozilla Probleme:

http://www.styleassistant.de/tips/tip91.htm

Theoretisch kannst Du SVG auch direkt in XHTML-Seiten einbinden, nämlich über XHTML Namespaces. (AFAIK geht das aber nur in den speziellen Mozilla-Builds)

Zu Mozilla und SVG:
http://www.mozilla.org/projects/svg/

3. Unterstützt SVG auch 3D oder muss ich da auf VRML zurückgreifen?

3D: nein. Ufff, das erste Mal seit langem, dass ich wieder nur das Wort »VRML« lese.

4. Wie sieht es mit Texturen aus? Werden Pixel-Texturen und Reflektionen unterstützt?

Reflektionen bei 2D machen IMHO wenig Sinn. Muster müssten aber funktionieren.

Beim 3D kann ich mich aber auch täuschen, ich meine aber, dass das nicht geht. Man möge mich da liebend gerne korrigieren.

Christian

[Sven Rautenberg]

Moin!

3. Unterstützt SVG auch 3D oder muss ich da auf VRML zurückgreifen?

3D: nein. Ufff, das erste Mal seit langem, dass ich wieder nur das Wort »VRML« lese.

Beim 3D kann ich mich aber auch täuschen, ich meine aber, dass das nicht geht. Man möge mich da liebend gerne korrigieren.

Korrigier!

Was ist 3D auf dem Bildschirm? Zweidimensional. Und kann SVG zweidimensionale Elemente darstellen? Ja. Also kann man diese Elemente so formen, dass sie wie dreidimensionale Elemente aussehen. :)

Allerdings ist das mit Einschränkungen zu sehen: 3D-Animationen oder gar virtuelle Welten zu bereisen ist in SVG ziemlich performancefordernd, weil die Berechnung der Animation von Javascript erledigt werden muss - und das ist nicht das schnellste.

Ich hatte irgendwo mal eine SVG-Demoseite gesehen, auf der die volle Breitseite der XML-Möglichkeiten eingesetzt wurde: Eine chemische Formel in ChemML wurde mit XSLT umgeformt zu einer SVG-Grafik, die das beschriebene Molekül als dreidimensionale Struktur darstellte. Mit der Maus konnte man es auch bewegen. Allerdings: In Opera leider doch nicht, und im IE war es bei großen Molekülen (als Beispiel war unter anderem Koffein dargestellt) ziemlich lahm - und das auf einem P3-800MHz. Ich denke, VRML ist aufgrund der Tatsache, dass alle 3D-relevanten Berechnungen geschwindigkeitsoptimiert vom Plugin ausgeführt werden, derzeit noch überlegen.

- Sven Rautenberg

[Alexander]

Hi Christian,

erstmal vielen Dank für die ausführlichen Antworten.

1. Bietet SCG Animationen bzw. ist es über Skripte steuerbar?

Ja. In SVG gibt es Animationselemente (die nur sehr einfache Dinge machen können) und außerdem ist es per JavaScript/DOM scriptbar.

Das ist dann natürlich ein recht mächtiges Werkzeug, was Flash gehörig einheizen könnte.
Ich finde es im übrigen wirklich komisch, dass Vektorgrafiken im Web anscheinend kaum eine Rolle spielen. Flash wird zumeist für (einfache) Pixel-Animationen/Filmchen zweckentfremdet, andere Vektorformate wie VRML sind quasi von der Bildfläche verschwunden und SVG führt bisher auch noch eher ein Schattendasein. Dafür sind Vektorgrafiekn für jede Art an technischen Zeichnungen besser geeignet als Pixelbilder.

Normalerweise binden man SVG per Object ein:

<object data="..." width="..." height="..." type="image/svg+xml">

Und das ist leider eine Tatscahe, die mir bisher nicht so gefällt. Wie ich schon vorher geschrieben habe, werden mehr User Plug-Ins (insbesondere die IE User mit ActiveX) deaktiviert haben als Grafiken. Zudem liegt die Skepsis gegenüber PlugIns bei den meisten Usern nach den Dialer-Missbrauchen etc. sehr hoch. Das ist einer schnellen Verbreitung von SVG auch nicht sonderlich dienlich...

3D: nein. Ufff, das erste Mal seit langem, dass ich wieder nur das Wort »VRML« lese.

Nun, es war das erste Mal seit Langem, dass ich es wieder geschrieben habe ;)
Die Idee, die hinter VRML steckt, halte ich nach wie vor für recht gut und für viele Anwendungszwecke ist es ein optimales Werkzeug.

Viele Grüße...

Alex :)

[Christian Seiler]

Hallo Alexander,

Das ist dann natürlich ein recht mächtiges Werkzeug, was Flash gehörig einheizen könnte.

Es fehlen im Prinzip nur noch Methoden zur Kommunikation mit dem Server. (GET-Request ausführen, POST-Request ausführen) Der Adobe-SVG-Viewer stellt aber proprietäre Methoden zur Verfügung: http://www.styleassistant.de/tips/tip99.htm Ich hoffe, diese werden auch in den Standard aufgenommen - das ist nämlich das einzige, wo Flash für den normalen Gebrauch noch wirkliche Vorteile bietet.

Ich finde es im übrigen wirklich komisch, dass Vektorgrafiken im Web anscheinend kaum eine Rolle spielen.

Ich auch. Ich selbst verwende bisher aber noch keine Vektorgraphiken mangels Verbreitungsgrad von SVG.

Flash wird zumeist für (einfache) Pixel-Animationen/Filmchen zweckentfremdet,

Ja, leider. IMHO hat Flash durchaus seine Daseinsberechtigung - aber garantiert nicht für das, was die meisten Leute damit anstellen.

andere Vektorformate wie VRML sind quasi von der Bildfläche verschwunden

Ja, leider. Ich habe mich nie intensiv mit VRML beschäftigt (Standardausredefloskeln hier einsetzen ;)) - aber vielleicht hole ich das ja noch nach.

und SVG führt bisher auch noch eher ein Schattendasein.

Naja, vielleicht werde ich SVG einsetzen - nicht für essentielle Graphiken aber vielleicht für so, Du nennst es »technische« Zeichnungen. So ganz langsam das Format »pushen«.

Dafür sind Vektorgrafiekn für jede Art an technischen Zeichnungen besser geeignet als Pixelbilder.

In dem Fall wäre sogar Flash ein gutes Einsatzgebiet für technische Zeichnungen, alleine schon wegen des Verbreitungsgrads, zumindest im Moment.

Und das ist leider eine Tatscahe, die mir bisher nicht so gefällt. Wie ich schon vorher geschrieben habe, werden mehr User Plug-Ins (insbesondere die IE User mit ActiveX) deaktiviert haben als Grafiken.

Naja, die meisten haben wohl Plugins deaktiviert - man kann AFAIK in keinem Browser Plugins selektiv deaktivieren und die meisten Leute werden Flash installiert haben.

Zudem liegt die Skepsis gegenüber PlugIns bei den meisten Usern nach den Dialer-Missbrauchen etc. sehr hoch.

Du hast Thomas Thread zum Thema »Menschliche Dummheit« nicht gelesen? (ist gerade auf dem Weg ins Archiv, musst Dich bis morgen gedulten)

Das ist einer schnellen Verbreitung von SVG auch nicht sonderlich dienlich...

Flash hat sich auch »durchsetzen« können...

Die Idee, die hinter VRML steckt, halte ich nach wie vor für recht gut und für viele Anwendungszwecke ist es ein optimales Werkzeug.

Öhm, ja, VRML Reihe ich dann auf meiner Langen TODO-Liste gleich hinter »Perl lernen« und »FreeBSD ausprobieren« ein. ;)

Christian

[Alexander]

Hallo Christian,

Es fehlen im Prinzip nur noch Methoden zur Kommunikation mit dem Server. (GET-Request ausführen, POST-Request ausführen)

Das wäre in der Tat noch perfekter. Dann wäre ich aber schon geneigt zu sagen, dass SVG kein Grafikformat im eigentlichen Sinne mehr ist ;)

Ich finde es im übrigen wirklich komisch, dass Vektorgrafiken im Web anscheinend kaum eine Rolle spielen.

Ich auch. Ich selbst verwende bisher aber noch keine Vektorgraphiken mangels Verbreitungsgrad von SVG.

Dem kann ich mich nur anschließen. Ich habe auch einige Grafiken auf meiner Homepage, für die sich ein Vektorformat besser eignen würde. Flash ist mir aber bisher immer zu teuer gewesen. Ich hatte mal überlegt, mir Flash 4 bei ebay zu ersteigern (würde für meine Zwecke ausreichen), aber aus mir nicht mehr bekannten Gründen habe ich diese Idee wieder verworfen. *g*

Ja, leider. Ich habe mich nie intensiv mit VRML beschäftigt (Standardausredefloskeln hier einsetzen ;)) - aber vielleicht hole ich das ja noch nach.

Nun ja, wenn ein "Markt" bzw. Einsatzbereiche dafür da wären, wäre es eine Überlegung wert, es zu erlernen. Aber "nur aus Spass" Software anschaffen oder eine vermutlich recht komplexe Beschreibungssprache zu erlernen macht man nicht mal eben so. Wobei das Interesse bei mir an sich auch da ist. Nur mit der Motivation hapert es da, da ich dann keine sinnvollen Einsatzmöglichkeiten für VRML (bisher) habe.

Das ist einer schnellen Verbreitung von SVG auch nicht sonderlich dienlich...

Flash hat sich auch »durchsetzen« können...

Das lag aber vielmehr daran, dass Flash Möglichkeiten bot, die früher überhaupt nicht anders realisierbar waren (vielleicht noch mit Java-Apletts). Für einfache Aufgaben reicht heutzutage schon HTML und JS aus (z.B. eine Bilder-Slideshow oder dynamische Menüs).
Imho hat sich Flash aber nicht durchsetzen können, weil es das einzige Vektorformat war.

Öhm, ja, VRML Reihe ich dann auf meiner Langen TODO-Liste gleich hinter »Perl lernen« und »FreeBSD ausprobieren« ein. ;)

"FreeBSD ausprobieren". Uihh. Entweder Du hast schon viel Erfahrung mit anderen, ähnlichen Systemen oder aus dem ausprobieren wird ein resignieren oder erlernen. ;)

Ich für meine Teil steh auch noch immer vor so einer ähnlichen Entscheidung. Perl oder PHP? Ich bin inzwischen so "fit", dass ich fertige Skripte meine Bedürfnissen anpassen kann. Aber bei RegEx und ähnlichem bin ich noch ein totaler n00b.

Viele Grüße...

Alex :)

[Christian Seiler]

Hallo Alex,

(zum Rest des Postings sage ich nichts, ich habe nämlich nichts mehr hinzuzufügen ;))

"FreeBSD ausprobieren". Uihh. Entweder Du hast schon viel Erfahrung mit anderen, ähnlichen Systemen oder aus dem ausprobieren wird ein resignieren oder erlernen. ;)

Naja, ich verwende schon seit 5 oder 6 Jahren Linux. Außerdem bin ich recht fit in C und C++ sowie vielen UNIX-Interna. Was jetzt nicht heißen soll, dass ich Experte bin, ich kann sicherlich noch eine Menge dazulernen. ;)

Naja, viele schwören halt auf FreeBSD und da wollte ich das mal ausprobieren.

Ich für meine Teil steh auch noch immer vor so einer ähnlichen Entscheidung. Perl oder PHP? Ich bin inzwischen so "fit", dass ich fertige Skripte meine Bedürfnissen anpassen kann. Aber bei RegEx und ähnlichem bin ich noch ein totaler n00b.

Ich selbst kann »nur« PHP - aber das sehr gut. An Perl hat mich immer die etwas seltsame Syntax abgeschreckt. Aber ich will Dich keinesfalls bei Deiner Entscheidung beeinflussen.

Christian

[Rainer S.]

Hallo Lars,

ich verwende viel PNG, allerdings fast nur als GIF-Ersatz. Für die Darstellung von Fotos eignet sich meiner Meinung auf jeden Fall JPEG besser.
Im Vergleich zu GIF allerdings (Animationen mal ausgeklammert) schneidet PNG von der Komprimierung her fast immer besser ab als das Gegenstück. Und die binäre Transparenz von GIF kann man auch in PNG mit einem Schwarzweiß-Alphakanal nachbilden, das beherrschen dann auch aktuelle Internet Explorer (nur Netscape 4 nicht).
Auf der Arbeit habe ich außerdem festgestellt, daß der Microsoft Photo Editor aus Office 97 (unser einziges "Grafikprogramm") im Gegensatz zu den GIF-Bildern ganz hervorragende und kleine PNG-Grafiken exportieren kann. Für Screenshots verwende ich seitdem nur noch PNG.

Schönen Gruß aus Bilk

Rainer