Kompressionsvergleich: Jpeg vs. Jpeg 2000 (vorsicht, große Datenmengen)

[san.salvador]

Hoi!
Mir war fad, deshalb hab ich mir jpeg 2000 mal näher angesehen.
Als Ausgangsbild dient ein RAW aus meiner Canon G10. Die Bilder sind in mehreren Stufen komprimiert, mit Lightroom 3 Beta 2 nach Jpeg und mit Faststone nach Jpeg (YCbCr) und Jpeg 2000 (RGB). Die 2000er musste ich leider wieder nach png ändern, da sie sonst hier nicht sichtbar wären.
Die LR3-Bilder werde ich vorerst nicht uppen, der unterschied scheint mir zu gering. Selbiges gilt für die Jpegs aus paint.net

Quelle:

http://dl.dropbox.com/u/4162752/Bilder/jpg/2.png

50kb

jpeg2000
http://dl.dropbox.com/u/4162752/Bilder/jpg/2fs50.png

jpeg
http://dl.dropbox.com/u/4162752/Bilder/jpg/2fs50.jpg


100kb

jpeg2000
http://dl.dropbox.com/u/4162752/Bilder/jpg/2fs100.png

jpeg
http://dl.dropbox.com/u/4162752/Bilder/jpg/2fs100.jpg


150kb

jpeg2000
http://dl.dropbox.com/u/4162752/Bilder/jpg/2fs150.png

jpeg
http://dl.dropbox.com/u/4162752/Bilder/jpg/2fs150.jpg


200kb

jpeg2000
http://dl.dropbox.com/u/4162752/Bilder/jpg/2fs200.png

jpeg
http://dl.dropbox.com/u/4162752/Bilder/jpg/2fs200.jpg


300kb

jpeg2000
http://dl.dropbox.com/u/4162752/Bilder/jpg/2fs300.png

jpeg
http://dl.dropbox.com/u/4162752/Bilder/jpg/2fs300.jpg


400kb

jpeg2000
http://dl.dropbox.com/u/4162752/Bilder/jpg/2fs400.png

jpeg
http://dl.dropbox.com/u/4162752/Bilder/jpg/2fs400.jpg

[huha]

Beeindruckend, insbesondere die 50 kiB und 100 kiB-Bilder. Darüber wird's dann IMHO schon wieder uninteressant.
Könnte sich gut für großflächige Hintergrundbilder eignen.

-huha

[san.salvador]

Jep, besonders bei flächigen Farbverläufen fährt jpeg2000 Schlitten mit seinem Vorgänger.

€dit:
Noch ein schönes Beispiel:

http://dl.dropbox.com/u/4162752/Bilder/jpg/x.png

28kb (!)

jpeg 2000
http://dl.dropbox.com/u/4162752/Bilder/jpg/xfs28.png

jpeg
http://dl.dropbox.com/u/4162752/Bilder/jpg/xfs28.jpg

[HeldImZelt]

Die Vorteile gegenüber JPEG-1 sind zu gering, die Patentsituation umstritten (U-Boot Patente) und Adobe hat selbst optionale Plugins aus der Photoshop Distribution genommen. Das Format kam daher wahrscheinlich nie richtig in Fahrt.

Für große Bilder wahrscheinlich keine schlechte Option, aber ohne anständige Verbreitung und Akzeptanz nicht wirklich empfehlenswert.

[san.salvador]

Die Vorteile gegenüber JPEG-1 sind zu gering, die Patentsituation umstritten (U-Boot Patente) und Adobe hat selbst optionale Plugins aus der Photoshop Distribution genommen. Das Format kam daher wahrscheinlich nie richtig in Fahrt.

Für große Bilder wahrscheinlich keine schlechte Option, aber ohne anständige Verbreitung und Akzeptanz nicht wirklich empfehlenswert.
Weiß ich, mir gings rein ums technische. Jpeg2000 Ist genau so tot wie es immer war, und das wird auch so bleiben.
Der Thread soll nur für ein paar Tränen sorgen. :D

[samm]

Ja schade, dass es tot bleibt... Auch die Theorie hinter der Kompression ist bei jpg2000 weitaus schöner. Btw finde ich nicht nur die flächigen Verläufe, sondern auch die Detailschärfe auch bei der 400kb-Variante noch merklich besser. Erinnert mich dort gewissermassen an Transparenz-AA (ja klar ist es nicht vergleichbar, aber ich seh in den Blättern mehr Details ;))

[Gast]

Schaut euch mal ein Bild mit feinem Karomuster (z.b. fein kariertes Hemd an).

Da sieht JPEG2000 und jeder sonstige Waveletcodec aufgrund der Kringelbildung alt aus.


Zumindest ist mir das mal bei einem Vergleich zwischen den Videocodecs H.264 AVC und H.253 ASP aufgefallen.

H.253 ASP neigte zwar zur Blockbildung, aber es konnte die Karohemden wenigstens einigermaßen darstellen, während es bei H.264 vor lauter Kringelbildung weichgezeichnet wurde.

[san.salvador]

H.264 hat nichts mit Wavelet zu tun. Da fällt mir nur dirac ein.

[(del)]

Soll h.265 nicht Wavelet machen? Naja, egal.

Außer des Probs mit den Patenten - die mittlerweile wohl schon "Hello World!" betreffen könnten - hat -huha das Problem mit Jpeg2000 eigentlich direkt erkannt. Einsame Spitze um große Bilder stark zu komprimieren. Wofür man gegenüber Jpeg1 bei "400kb" schon recht genau hinschauen muß. 50KB saugen beide. Am besten kommt es bei 100kb zur Geltung.

Ist im Gründe aber nichts anderes als mit PNG. Das sollte das Netz von GIFs und JPEGs befreien, letztendlich nimmt man es nur für kleinere Screenshots.

@-huha
Bist du dir da auch wirklich sicher, daß so ein Hintergrundbild für die Darstellung dekodiert weniger RAM braucht? =) Oder meinst du nur das Laden/Dekodieren gegenüber z.B. BMP? Naja, ich weiß nicht...

[mbee]

Ist im Gründe aber nichts anderes als mit PNG. Das sollte das Netz von GIFs und JPEGs befreien, letztendlich nimmt man es nur für kleinere Screenshots.

Das ist Blödsinn: Von GIFs (PNG ist ein lossless Format), nicht von JPGs.
Und das hätte es auch schon lange, wenn es da nicht eine Krankheit namens IE 6 existieren würde, welche auf nativem Wege keine Transparenzen in PNGs unterstützt. Ohne IE 6 würde kein Mensch, der sich ein bischen auskennt, noch GIFs verwenden.
Mittlerweile pfeifen allerdings auch einige drauf oder verwenden für den IE6 eben ein Filter-Script.

[Pinoccio]

Schaut euch mal ein Bild mit feinem Karomuster (z.b. fein kariertes Hemd an).

Da sieht JPEG2000 und jeder sonstige Waveletcodec aufgrund der Kringelbildung alt aus.Es gibt für jeden verlustbehafteten Codec Beispielbilder, wo er an seine visuellen Grenzen stößt.Auch die Theorie hinter der Kompression ist bei jpg2000 weitaus schöner.Geschmackssache. ^^
Ich finde die Theorie hinter JPEG (also oldschool) eleganter.

mfg

[Mr. Lolman]

Das ist Blödsinn: Von GIFs (PNG ist ein lossless Format), nicht von JPGs.
Und das hätte es auch schon lange, wenn es da nicht eine Krankheit namens IE 6 existieren würde, welche auf nativem Wege keine Transparenzen in PNGs unterstützt. Ohne IE 6 würde kein Mensch, der sich ein bischen auskennt, noch GIFs verwenden.
Mittlerweile pfeifen allerdings auch einige drauf oder verwenden für den IE6 eben ein Filter-Script.

Je nach Bildinhalt die die gif-Kompression aber immernoch besser als bei png. Wenn man allerdings mehr als 256+Transparenz braucht, kommt man um png nicht herum.

[mbee]

Je nach Bildinhalt die die gif-Kompression aber immernoch besser als bei png. Wenn man allerdings mehr als 256+Transparenz braucht, kommt man um png nicht herum.
Bei großen Flächen mit einfarbigen Bildinhalten ein klein wenig, aber auch da ist der Unterschied meist mehr als nur minimal. Es gibt allerdings viele Programme, die PNG nicht optimal speichern, daher rührt auch größtenteils dieser "Ruf", schlechter als GIF zu komprimieren.

[Pinoccio]

Bei großen Flächen mit einfarbigen Bildinhalten ein klein wenig, aber auch da ist der Unterschied meist mehr als nur minimal. Es gibt allerdings viele Programme, die PNG nicht optimal speichern, daher rührt auch größtenteils dieser "Ruf", schlechter als GIF zu komprimieren.Jau, mit z. B.pngpngcrush (http://www.neilturner.me.uk/2005/02/05/quickly_compress_png_images.html) kann man einiges rausholen.
-brute dauert aber echt ganz schön lange.

mfg

[san.salvador]

Jau, mit z. B.pngpngcrush (http://www.neilturner.me.uk/2005/02/05/quickly_compress_png_images.html) kann man einiges rausholen.
-brute dauert aber echt ganz schön lange.

mfg
Lustig, dass du das ansprichst - ich lasse die PNGs hier im Fred gerade durch optipng laufen. Dadurch werden die Files im Schnitt um 40% kleiner. Ich hab die Ursprungsdateien allerdings weder mit sub noch mit paeth gespeichert.

[Pinoccio]

Lustig, dass du das ansprichst - ich lasse die PNGs hier im Fred gerade durch optipng laufen. Dadurch werden die Files im Schnitt um 40% kleiner. Ich hab die Ursprungsdateien allerdings weder mit sub noch mit paeth gespeichert.Muhaha, dann kann ich ja damit aufhören.^^

mfg

[DanMan]

JP2k ist mMn nicht überall einfach besser. Bei kleinen Dateigrößen eindeutig ja, aber je weiter die Zeit voranschreitet, umso weniger spielt das noch eine Rolle, weil sowohl Speicherplatz immer billiger als auch Interverbindungen immer schneller werden. Wenn man dann noch dazunimmt, dass JP2k aufwändiger zu dekodieren ist, und mobile, schwachbrüstige Geräte immer mehr Verbreitung finden...

Ich hatte auch schon so meine Tests gemacht und bin zu dem Ergebnis gekommen, dass man mit JP2k die Bilder nicht ausreichend gegenüber JPEG ohne sichtbaren Qualitätsverlust verkleinern kann, um einen Umstieg zu rechtfertigen. Das 50kB Bild sieht mit JP2k zwar um Längen besser aus, absolut gesehen aber trotzdem schlecht. Ab 150kB machts schon keinen nennenswerten Unterschied mehr.

Microsoft will scheinbar ein neues Bildformat mit IE9 in Internet etablieren (http://ie.microsoft.com/testdrive/Graphics/48ImageSupport/Default.html). Nennt sich JPEG XR (http://de.wikipedia.org/wiki/JPEG_XR).

[san.salvador]

Eigentlich wollte ich gerade einen Blindtest für euch zusammenschustern. Dabei habe ich eine interessante Entdeckung gemacht.
Ziel war es, beide Jpegs möglichst nahe an die Transparenz (also vom Original nicht unterscheidbar) zu bringen.
Das bemerkenswerte: Jpeg2000 will ums verrecken nicht transparent werden.
Während Jpeg mit ~500kb schon sehr nah dran ist (zumindest für mich), sehe ich bei Jpeg2000 mit ~800kb noch gewisse Mängel (auf hohem Niveau, freilich).

Ich schmeiß sie euch mal blind rein, die Auflösung kommt später (oder auf Wunsch per PN, für die Ungeduldigen ;)).

Ihr seht hier das Original, je ein Jpeg und ein 2000er mit ~300kb, ~500kb und ~800kb - ohne Reihenfolge natürlich. Viel Spaß beim Raten. ;)

Blindtest:

1.
http://dl.dropbox.com/u/4162752/Bilder/jpg/blind1/1.png

2.
http://dl.dropbox.com/u/4162752/Bilder/jpg/blind1/2.png

3.
http://dl.dropbox.com/u/4162752/Bilder/jpg/blind1/3.png

4.
http://dl.dropbox.com/u/4162752/Bilder/jpg/blind1/4.png

5.
http://dl.dropbox.com/u/4162752/Bilder/jpg/blind1/5.png

6.
http://dl.dropbox.com/u/4162752/Bilder/jpg/blind1/6.png

7.
http://dl.dropbox.com/u/4162752/Bilder/jpg/blind1/7.png

[(del)]

Das ist Blödsinn:Hört hört

Von GIFs (PNG ist ein lossless Format), nicht von JPGs.Bist du echt noch so jung, um die damaligen Diskussionen rund um PNG nicht mitbekommen zu haben? :| =)

Es gibt allerdings viele Programme, die PNG nicht optimal speichern, daher rührt auch größtenteils dieser "Ruf", schlechter als GIF zu komprimieren.Ich kenne diesen Ruf nicht. Nachdem 89a frei wurde ist es wieder schnell still um PNG geworden. Es funktioneirt einfach, die Werkzeuge stimmen und dafür wofür man es gebrauchen kann und wie groß es danach ist reicht es dicke. Bis auf IE6 steckt mehr nicht dahinter. Man braucht nicht nur Transparenz, wenn man GIF statt PNG nimmt.

[HeldImZelt]

Jau, mit z. B.pngpngcrush (http://www.neilturner.me.uk/2005/02/05/quickly_compress_png_images.html) kann man einiges rausholen.
-brute dauert aber echt ganz schön lange.

mfg
Aktuelle win32 binaries gibt's nicht mehr? :confused:
http://pmt.sourceforge.net/pngcrush/

[mbee]

Hört hört

Bist du echt noch so jung, um die damaligen Diskussionen rund um PNG nicht mitbekommen zu haben? :| =)
Mein Alter siehst Du in meinem Profil ;)
Aber mir geht's um den praktischen Einsatz auf den Online-Bereich bezogen und dass eine lossless Komprimierung i.d.R. ineffizienter ist als eine verlustbehaftete, sollte wohl klar sein. PNG war nie ein "JPG"-Killer, auch wenn das manche damals so gesehen haben mögen.

Ich kenne diesen Ruf nicht.
Aber ich, kann auch daran liegen, dass Du in der Hinsicht eher "branchenfremd" bist, wenn ich mich nicht irre.

Nachdem 89a frei wurde ist es wieder schnell still um PNG geworden. Es funktioneirt einfach, die Werkzeuge stimmen und dafür wofür man es gebrauchen kann und wie groß es danach ist reicht es dicke. Bis auf IE6 steckt mehr nicht dahinter. Man braucht nicht nur Transparenz, wenn man GIF statt PNG nimmt.

Das ist schon wieder ziemlicher Blödsinn. Kaum jemand, der im Web-Bereich professionell tätig ist, setzt noch auf GIF, wenn nicht besagtes Transparenz-Problem im IE 6 stört und sich nicht sauber durch einen Workaround lösen lässt: GIFs kannst Du jeweils nur auf ein feste Hintergrundfarbe transparent machen, dumm nur, wenn transparente Grafiken vor einem Hintergrund liegen, der nicht einfarbig sein soll oder diese Position wechseln sollen...
Genau deshalb bietet PNG einen Alpha-Kanal, das ist ja das "GIF-Killer"-Argument für dieses Format.

Da aktuelle recht viele Layouts mit solchen Transparenzen arbeiten, ist der Aufwand solche mit GIFs zu erzeugen (der "Filter-Script-Trick" funktioniert nicht immer) gigantisch und wäre ohne IE6 (der im B2B-Bereich noch bis zu 30% Marktanteil hat) völlig überflüssig.

Die Werkzeuge sind übrigens die selben wie für GIF auch, wo soll dessen Vorteil also bitteschön liegen?

BTW: Mit den damaligen Lizenzkosten für GIF hat das auch nichts zu tun. Die wurden nur fällig, wenn GIFs erzeugt wurden, fielen also für Bildbearbeitungsprogramme oder Komponenten/Programme an, die GIFs dynamisch auf dem Server erzeugt hatten und waren dort im Preis enthalten. Wenn man so etwas also nicht gerade selbst entwickelt hatte, gab's in der Hinsicht auch kein Problem.

[Pinoccio]

Aktuelle win32 binaries gibt's nicht mehr? :confused:
http://pmt.sourceforge.net/pngcrush/Unter Win7 x64 laufen die Binaries. Ist das aktuell genug?

mfg

[(del)]

Das ist schon wieder ziemlicher Blödsinn. Kaum jemand, der im Web-Bereich professionell tätig ist, setzt noch auf GIFEcht? Ich finde jede Woche Tonen davon im Browsercache.

[HeldImZelt]

Aktuelle win32 binaries gibt's nicht mehr? :confused:
http://pmt.sourceforge.net/pngcrush/Unter Win7 x64 laufen die Binaries. Ist das aktuell genug?

mfg
Nicht das OS... Die Kompilate.
Die in dem Blog verlinkten Binaries sind von 2005. Die aktuellen Sourcen hingegen sind nur wenige Tage alt. Ich glaube schon, dass man in 5 Jahren einige Verbesserungen einfließen lassen kann....

Der Programmierer sagt folgendes dazu:
I can't make them so I depend on volunteers. No volunteer has made new ones lately.

Glenn

[mbee]

Echt? Ich finde jede Woche Tonen davon im Browsercache.
Ja, weil's a) viele Leute nicht besser wissen und b) viele noch den IE6 berücksichtigen und deshalb den kleinsten Nenner fahren, anstatt 2 Versionen zu basteln ;)
Ändert auch nichts an dem Rest, den ich dazu geschrieben habe inklusive meiner Frage, auf den Du überhaupt nicht eingegangen bist...
Thema war ja, dass GIF ohne den IE 6 eigentlich so gut wie überflüssig ist. Aber so langsam ist das ziemlich OT, hier ging's ja auch um JPEG 2000 ursprünglich.

[Pinoccio]

Nicht das OS... Die Kompilate.
Die in dem Blog verlinkten Binaries sind von 2005. Die aktuellen Sourcen hingegen sind nur wenige Tage alt. Ich glaube schon, dass man in 5 Jahren einige Verbesserungen einfließen lassen kann....

Der Programmierer sagt folgendes dazu:Achso.
Ich kanns auch nicht. ;-)
Optipng (http://optipng.sourceforge.net/) (siehe san.salvador) wäre eine Alternative, aktuelle Binaries und - zumindest laut Beschriebung - mehr Optionen.

mfg

[(del)]

Ja, weil's a) viele Leute nicht besser wissen und b) viele noch den IE6 berücksichtigen und deshalb den kleinsten Nenner fahren, anstatt 2 Versionen zu basteln ;)Mir sind die Gründe warum ich keinen Blödsinn erzähle eigentlich egal ;)

[HeldImZelt]

Achso.
Ich kanns auch nicht. ;-)
Optipng (http://optipng.sourceforge.net/) (siehe san.salvador) wäre eine Alternative, aktuelle Binaries und - zumindest laut Beschriebung - mehr Optionen.

mfg
Laut LibPNG gibt's noch mehr: Pngrewrite, pngcrush, PNGOUT und OptiPNG. Ich wollte die mal testweise vergleichen/kaskadieren. Gestört hat aber die 2005'er Version von Pngcrush.

Ich habe inzwischen die aktuelle Version kompiliert und verschickt. Der Coder soll aber erst mal die Compilerwarnungen deuten.

[pest]

Geschmackssache. ^^


nun der Kodierungsschritt bietet weitaus mehr Möglichkeiten.
Die Wavelettransformation an sich, macht nicht besonders viel aus.
Man kann die DCT-Koeffizienten so anordnen das eine Struktur
ähnlich der Wavelet-Pyramide entsteht, dadurch lassen sich sogar
ähnliche Kompressionsergebnisse erziehlen.

Je nach Bildinhalt die die gif-Kompression aber immernoch besser als bei png.

LZW vs. LZ77+Static Huffman, das bezweifle ich, und wenn dann nur in hoch synthetischen Testbeispielen.

Jpeg2000 will ums verrecken nicht transparent werden.


das liegt imo am Quantisierungsschritt bei JPEG2000 und dem verwendeten Dead-Zone-Quantizer.

[san.salvador]

Interessiert sich denn gar niemand für den Blindtest? :usad:

[pest]

7 Bilder? mach mal 3 :) oder 4
original, jpeg, jpeg2000 in 2 stufen

wenn man sich ein bisschen auskennt (bzw. die Artefakte kennt, ist es nicht schwer)

[san.salvador]

Nagut, ich verrate mal einen Teil.
1: Jpeg 300kb
6: J2000 500kb
7: Jpeg 800kb

Zu erraten bleiben also noch Original, Jpeg 500kb, J2000 800kb und J2000 300kb.

[pest]

also die tipps, habe ich jetzt nich verwendet ;)


2 ist original
5 ist lq-jpeg2000

man mein tft ist echt dreckig :freak:

3 ist jpeg
4 ist jpeg2000

[san.salvador]

also die tipps, habe ich jetzt nich verwendet ;)


2 ist original
5 ist lq-jpeg2000

man mein tft ist echt dreckig :freak:

3 ist jpeg
4 ist jpeg2000


Das sagen sie alle! :D


2: :up:
5: :up:

das merkt man, denn...

3: :down:
4: :down:

[pest]

verdammt ich habe das smearing mit blocking verwechselt :(
4 hat auf jeden fall mehr ringing

[san.salvador]

verdammt ich habe das smearing mit blocking verwechselt :(
Hast du denn garnichts gelernt? Wofür mach ich das hier? :unono:

[pest]

???

[HeldImZelt]

ich lasse die PNGs hier im Fred gerade durch optipng laufen. Dadurch werden die Files im Schnitt um 40% kleiner. Ich hab die Ursprungsdateien allerdings weder mit sub noch mit paeth gespeichert.
Photoshop v11.0.1 (CS4) PNGs (als Original) werden bei mir nur um die 10% kleiner. Optipng kriegt aber meist nicht so viel raus wie die Anderen.

Hier ist eine Batchdatei für Drag&Drop. Erstellt 3 neue Versionen. Die Bilder müssen im gleichen Ordner liegen oder man fügt manuell die absoluten EXE-Pfade ein.

Download:
PNG-Optimizer (pngcrush, pngout, optipng) (http://rghost.net/1694001/private/f54c7913e8629cf0256485e14a03a4cc)

[san.salvador]

???
Ich spiele darauf an, dass genau dieser Unterschied der Kern dieses Threads ist. Verwechseln ist. ;)
Photoshop v11.0.1 (CS4) PNGs (als Original) werden bei mir nur um die 10% kleiner. Optipng kriegt aber meist nicht so viel raus wie die Anderen.

Hier ist eine Batchdatei für Drag&Drop. Erstellt 3 neue Versionen. Die Bilder müssen im gleichen Ordner liegen oder man fügt manuell die absoluten EXE-Pfade ein.

Download:
PNG-Optimizer (pngcrush, pngout, optipng) (http://rghost.net/1694001/private/f54c7913e8629cf0256485e14a03a4cc)
Danke, seh ich mir mal an.

[pest]

Ich spiele darauf an, dass genau dieser Unterschied der Kern dieses Threads ist. Verwechseln ist. ;)


naja das ist bei bestimmten kombinationen von kompressionsverhältnissen garnicht richtig möglich weil beide codecs ähnliche artefakte zeigen.

übertreibt man es bei jpeg hat man halt starkes blocking
(lustigerweise hat man das bei x264, was intern auch so ähnlich wie jpeg auf i-frames arbeitet nicht)

smearing & ringing treten bei beiden auf

besser wäre es imo eh die kompression in bits/pixel anzugeben, und auch da nur gleiche kompressionen zu vergleichen.

[Kinman]

Sollte man zum Vergleich nicht die EXIFs rausnehmen? Vor allem bei der 50k Version.

lg Kinman

[san.salvador]

Sollte man zum Vergleich nicht die EXIFs rausnehmen? Vor allem bei der 50k Version.

lg Kinman
Wieso? Meinst du, dass die soviel Platz einnehmen?

[Gast]

Wieso? Meinst du, dass die soviel Platz einnehmen?

Bei kleinen Dateigrößen schon, bei großen sind sie natürlich vernachlässigbar.

[san.salvador]

Bei kleinen Dateigrößen schon, bei großen sind sie natürlich vernachlässigbar.
Ich hab auf die Schnelle ein Bild mit und ohne EXIF aus LR3 exportiert. Der Größenunterschied ist kleiner als 1kbyte, insofern würd ich sagen: vernachlässigbar.
Da ist mir ein Fehler unterlaufen: Ich habe ein JPEG exportiert, dass keine EXIF hat. X-D
Beim zweiten Versuch komm ich auf 7kb Differenz.

[Gast]

Beim zweiten Versuch komm ich auf 7kb Differenz.

Also bei meiner Kamera sind es ca. 20-30kB, die von den Metadaten gebraucht werden. Also bei Dateigrößen unter 100KB sicher nicht mehr vernachlässigbar.

[Kinman]

Ah, interessant. Danke ;)
Ich hatte 4-6kB geschätzt. Da es sogar 7 kB sind, machts durchaus einen Unterschied bei 50kB Bilder..

lg Kinman

[san.salvador]

Ich bin mir allerdings beinahe sicher (ganz rekonstruieren kann ichs derzeit nicht), dass ich sowohl die JPEGs als auch die 2000er von einem PNG gezogen habe, womit beide keine EXIFs enthalten sollten.