mikrocontroller.net

Forum: www.mikrocontroller.net Werden Bildanhänge in der Größe optimiert?


Autor: HildeK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe zu einem Post ein Bild (PNG) hinzugefügt:
Beitrag "Re: Inverter in CMOS - Funktioniert das?"
Interessanterweise ist es bei mir auf der Platte 11k groß - im Forum hat 
es noch 4,4k.
Optimiert die Forensoftware die Bilder? Schönes Feature!
Ich war zu bequem, vorher optipng darüber laufen zu lassen - diese SW 
hätte es noch auf 3,6k verkleinern können.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leider sind gewisse Optimierungen und Konvertierungen notwendig, da es 
hier in der Vergangenheit immer wieder Deppen gegeben hat, die Fotos im 
BMP-Format bei Dateigrößen von mehreren Megabytes und Auflösungen von 5 
Megapixel hochgeladen haben.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Gast (Gast)

>Leider sind gewisse Optimierungen und Konvertierungen notwendig, da es
>hier in der Vergangenheit immer wieder Deppen gegeben hat, die Fotos im
>BMP-Format bei Dateigrößen von mehreren Megabytes und Auflösungen von 5
>Megapixel hochgeladen haben.

Aber wie kann ein PNG noch weiter verkleinert werden? Der 
Kompressionsargorithmus ist doch fix.

MfG
Falk

Autor: Malte __ (malte) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner wrote:
> Aber wie kann ein PNG noch weiter verkleinert werden? Der
> Kompressionsargorithmus ist doch fix.
>
Also bei GIMP kann ich auch bei PNG den Kompressionsgrad in 10 Schritten 
einstellen. Dabei ist die Dateigröße bei einem Kompressionsgrad von 0 
genau so groß wie ein bmp.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://de.wikipedia.org/wiki/Portable_Network_Grap...

Die Vorfilter sind der Grund für den meist geringeren Platzbedarf von 
PNG-Dateien gegenüber GIF-Dateien. Allerdings speichern viele Programme 
PNG-Bilder nicht optimal ab, was zu unnötig großen Dateien führt. 
Verschiedene Programme wie beispielsweise PNGOUT, pngcrush, OptiPNG oder 
andere[2] ermöglichen eine verlustfreie Neukomprimierung und oft 
wesentlich kleinere Dateien.

Das könnte ein Grund sein

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, eines dieser Tools wird hier verwendet.

Autor: HildeK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke!

Gast (Gast) schrieb:
> ... Fotos im BMP-Format ...
Werden die auch beim Hochladen optimiert / kompromiert?
Ich will's nicht unbedingt ausprobieren!

Falk Brunner schrieb:
>Aber wie kann ein PNG noch weiter verkleinert werden? Der
>Kompressionsargorithmus ist doch fix.
Dem scheint nicht so zu sein, denn, wie gesagt, optiPNG schaffte an dem 
Beispiel die ursprünglichen 11k runter auf 4k Dateigröße zu bringen.

Andreas Schwarz (andreas) (Admin) schrieb:
>Ja, eines dieser Tools wird hier verwendet.
Dann brauche ich den Umweg über Optipng für die png-Dateien in meinen 
Posts zukünftig nicht mehr zu gehen, dank deines Tools.
Das kommt mir durchaus entgegen :-)

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
BMP und TIFF wird beim Hochladen in PNG umgewandelt.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Aber wie kann ein PNG noch weiter verkleinert werden? Der
> Kompressionsargorithmus ist doch fix.

Gähn. Das weis doch jedes Kind, dass es da Software zur weiteren 
verlustfreien Optimierung gibt.

Beitrag "PNG Files Optimieren"

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ HildeK (Gast)

>>Aber wie kann ein PNG noch weiter verkleinert werden? Der
>>Kompressionsargorithmus ist doch fix.
>Dem scheint nicht so zu sein, denn, wie gesagt, optiPNG schaffte an dem
>Beispiel die ursprünglichen 11k runter auf 4k Dateigröße zu bringen.

OK, dann ist es wohl wie beim ZIP, wo man verschiedene Kompressionstufen 
einstellen kann, auch wenn alle verlustfrei sind.

MFG
Falk

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner wrote:
> OK, dann ist es wohl wie beim ZIP, wo man verschiedene Kompressionstufen
> einstellen kann, auch wenn alle verlustfrei sind.

Sehr wahrscheinlich ist das so, denn PNG benutzt den ZIP Algorithmus zur 
Kompression.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon K. wrote:

> Sehr wahrscheinlich ist das so, denn PNG benutzt den ZIP Algorithmus zur
> Kompression.

Genauer: den "deflate"-Algorithmus.  Der stammt ursprünglich vom gzip,
wurde dann später aber auch von anderen zip-Tools als Standardalgo-
rithmus übernommen.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wikipedia meint es sei für das ZIP Archivformat zuerst entwickelt worden 
und nachher der Public Domain zugeführt.

http://de.wikipedia.org/wiki/Deflate

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich mag hier die Darstellung in Wikipedia anzweifeln.  PKZIP ist kein
Opensource, insofern kann man dort die exakte Versionsgeschichte nicht
nachvollziehen, aber selbst Wikipedia dokumentiert die PKZIP-Version
2 (bei der deflate dann dabei war) mit einem Erscheinungsjahr 1993,
während gzip 0.1 vom 31. Oktober 1992 ist.  Zumindest hat gzip dem
deflate-Algorithmus seinerzeit sehr schnell zur Verbreitung geholfen,
während ich das bei PKZIP erst später beobachten konnte.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wer es besser weiß als Wikipedia, möge es dort bitte korrigieren (und 
gegebenenfalls in der Kommentarfunktion näher erläutern).

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gast wrote:
> Wer es besser weiß als Wikipedia, möge es dort bitte korrigieren (und
> gegebenenfalls in der Kommentarfunktion näher erläutern).

Da es in meinem Fall nur Erinnerung ist und mir ein belegbares Datum
für PKZIP fehlt, halte ich mich da eher zurück.  Man könnte allerdings
den Autor von gzip noch fragen.

Autor: Εrnst B✶ (ernst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hehe... Wenn Leute BMPs anhängen wollen, dann schaffen die das auch, 
allen Auto-Rekomprimierern zum Trotz…

z.B. der Anhang hier:

Beitrag "EEProm - Problem"

Schwubs die BMPs nochmal in einem Zip versenkt, und schon greift die 
schöne Automatik ins Leere.

Besonders elegant bei dem Beispiel Oben:
Bei einem von den BMPs handelt es sich um den Source-Code, in 
Screenshot-Form. 1.4MB für 10 Zeilen Code!

Wenigstens ist der Zip-Container aussenrum komprimiert ;)

Autor: Kachel - Heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Bei einem von den BMPs handelt es sich um den Source-Code, in
> Screenshot-Form. 1.4MB für 10 Zeilen Code!

Sei froh, dass es nicht als Video hochgeladen wurde...

Duck & weg...

KH

Autor: HildeK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ernst Bachmann (ernst) wrote:
>Hehe... Wenn Leute BMPs anhängen wollen, dann schaffen die das auch,
>allen Auto-Rekomprimierern zum Trotz…

>z.B. der Anhang hier:

>Beitrag "EEProm - Problem"

Ja, du hast recht. Abgesehen von der Tatsache, dass hier ja ein reines 
Textfenster als Bild mit angehängt wurde, hat die Verpackung in ZIP in 
dem Beispiel schon eine Berechtigung:
- drei Bilder wurden mit einem Post komprimiert übertragen
- einige Registerfenster wurden mit dargestellt
- die Verwandlung vorher in PNG wäre auch nicht (viel) platzsparender 
gewesen (für den Übertragungsweg und für Andreas' Server)
- es zeigt, dass ZIP auf BMP angewandt nicht ganz das Ergebnis liefert 
wie die Konversion von BMP auf PNG - ok, je nach verwendeter SW kann 
auch ein Gewinn um Faktor 2 für PNG herauskommen.

Also, kein soooo großer Grund zum Schimpfen :-)

Übrigens:
anhand des Beispiels von Ernst Bachmann habe ich mal folgende Versuche 
gemacht, mit dem JmpTable.bmp:
- Bitmap komprimiert mit ZIP, wurde von 1,8MB auf 48k reduziert (97%)
- Bitmap konvertiert in PNG, wurde von 1,8MB auf 45k reduziert
- 45k PNG in ZIP: 41k (10%)
- 45k PNG mit optipng -o7: 21k (52%!)
- 21k PNG mit ZIP: 20k (5%)

Da optipng einmal mehr kann als WinZip und dann wieder umgekehrt, 
scheint zu zeigen, dass nicht derselbe Algorithmus zur Anwendung kommt.

Ich will mir sparen, die 1,8MB JmpTable.bmp hochzuladen, um 
herauszufinden, was die Forensoftware kann ...

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Also, kein soooo großer Grund zum Schimpfen

Aber ehrlich, wer BMP benutzt hat einen an der Waffel. Für dieses Format 
gibt es überhaupt keine Berechtigung. Bin mir nicht mal sicher ob es da 
für alle gängigen Betriebssysteme überhaupt Viewer gibt.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Unklar bleibt, wieso Grafikprogramme kein optipng oä eingebaut haben.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ gast (Gast)

>Aber ehrlich, wer BMP benutzt hat einen an der Waffel.

Naja, mal langsam mit den jungen Pferden.

> Für dieses Format
>gibt es überhaupt keine Berechtigung.

Was es nicht daran hindert, eines der ältesten zu sein. Windows 95 & Co 
konnte/wolle nur BMPs als Desktophintergrund anzeigen.

> Bin mir nicht mal sicher ob es da
>für alle gängigen Betriebssysteme überhaupt Viewer gibt.

Aber sicher.

Das Format hat schon seine Berechtigung, u.a. als Quick And Dirty 
Datenträger für Testzwecke. Ein BMP ist ein sehr einfacher Header mit 
Farbtabelle (bei 256 Farben BMPs) gefolgt von den rohen Bilddaten. Kann 
man kinderleicht erzeugen und lesen, in so ziemlich allen 
Programmiersprachen, incl. VHDL & Co.

MFG
Falk

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Gast (Gast)

>Unklar bleibt, wieso Grafikprogramme kein optipng oä eingebaut haben.

Weil die Standardkomprimierung von PNG gut genug ist?

MFG
Falk

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Was es nicht daran hindert, eines der ältesten zu sein. Windows 95 & Co
> konnte/wolle nur BMPs als Desktophintergrund anzeigen.

Und wieso ist das dann ein Grund, heute BMPs zu verbreiten? Irgendwelche 
alten Murkssysteme a la  Windows 9x als Maßstab zu nehmen, ist ja wohl 
ziemlich lächerlich. Damals gab es ja auch schon kostenlose und 
kostenpflichtige Grafikprogramme, die anständige Grafikformate ausgeben 
konnten. Und heute verwendet fast keiner mehr Win9x. Aber auch wenn es 
noch jemand benutzt, gibt es keinen Grund, BMP als Austauschformat zu 
verwenden!

>> Unklar bleibt, wieso Grafikprogramme kein optipng oä eingebaut haben.

> Weil die Standardkomprimierung von PNG gut genug ist?

Wie man am zusätzlichen Kompressionsfaktor dieser Zusatzprogramme sieht, 
ist die Standardkomprimierung von PNG eben nicht gut! Nur in wenigen 
Fällen spielt der zusätzliche Rechenaufwand/Zeitaufwand eine Rolle. 
Dabei kann man die Kompressionsstärke der Grafikprogramme ja wie bisher 
variabel, also einstellbar, machen. Wenn es also ganz schnell gehen 
muss, nimmt man eben eine schlechte Komprimierung wie bisher.

> Das Format hat schon seine Berechtigung, u.a. als Quick And Dirty
> Datenträger für Testzwecke.

Für den internen Gebrauch vielleicht. Aber wer BMP als Austauschformat 
für alle möglichen Zwecke, so z.B. in Foren, benutzt. Naja, da muss man 
in der Tat an der geistigen Zurechnungsfähigkeit des Verursachers 
zweifeln. Das ist besonders in einem technischen Forum wie diesem nicht 
entschuldbar. Solche Kenntnisse gehören heutzutage zur Allgemeinbildung.

Autor: HildeK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Unklar bleibt, wieso Grafikprogramme kein optipng oä eingebaut haben.
>Weil die Standardkomprimierung von PNG gut genug ist?

und

>Wie man am zusätzlichen Kompressionsfaktor dieser Zusatzprogramme sieht,
>ist die Standardkomprimierung von PNG eben nicht gut! Nur in wenigen
>Fällen spielt der zusätzliche Rechenaufwand/Zeitaufwand eine Rolle.

Nehmt mal ein 5Mpixel Foto von der Digicam, das 
Bildverarbeitungsprogramm Eurer Wahl und speichert es unter BMP und dann 
unter PNG.
Anschließend lasst das entstandene PNG nochmals über z.B. optipng 
laufen.

Das habe ich gestern versucht - ich wollte aber nicht die halbe Stunde 
(vielleicht wäre es auch nur eine viertel Stunde gewesen - bin dann 
Schlafen gegangen :-)) abwarten, bis optipng fertig war mir noch mageren 
7% Reduktion. Nicht mal das schlechter komprimierte PNG meiner 
Bildverarbeitung war für meine Begriffe ausreichend schnell auf der 
Platte gespeichert.
Für reine Grafiken sind aber PNG oder GIF ideal - hier scheint auch die 
Optimierung mehr zu bringen.

>Und wieso ist das dann ein Grund, heute BMPs zu verbreiten?
Zum Verbreiten gibt es sicher keinen Grund. Da aber der von Ernst 
Bachmann zitierte Poster die BMPs gezippt hatte, kann man ihm verzeihen. 
Auf das bisschen (temporären) Plattenplatz kommt es wirklich nicht an.

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
BMPs in einer ZIP-Datei mag man verzeihen.

Aber 10 Zeile Quellcode als BMP und das dann ins ZIP-File, DAS GEHT DOCH 
NICHT!!!

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ HildeK

Aber verstanden hast du meinen Beitrag nicht!

Dazu empfehle ich nochmal folgenden Text von mir zu lesen:

| Wie man am zusätzlichen Kompressionsfaktor dieser Zusatzprogramme sieht,
| ist die Standardkomprimierung von PNG eben nicht gut! Nur in wenigen
| Fällen spielt der zusätzliche Rechenaufwand/Zeitaufwand eine Rolle.

Und jetzt der wichtige Teil, den du unterschlagen hast, weil nicht 
verstanden:

| Dabei kann man die Kompressionsstärke der Grafikprogramme ja wie bisher
| variabel, also einstellbar, machen. Wenn es also ganz schnell gehen
| muss, nimmt man eben eine schlechte Komprimierung wie bisher.

Also die Option, den Kompressionsfaktor einzustellen soll ja weiter 
vorhanden sein!!!

> Da aber der von Ernst
> Bachmann zitierte Poster die BMPs gezippt hatte, kann man ihm verzeihen.
> Auf das bisschen (temporären) Plattenplatz kommt es wirklich nicht an.

Trotzdem ist soviel Dummheit in einer Person nicht verzeihbar. Allein 
die Verwendung von BMP ist nicht akzeptabel. Da gibt es keine 
Entschuldigung, auch kein zip-Packer.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
HildeK wrote:

> Nehmt mal ein 5Mpixel Foto von der Digicam, das
> Bildverarbeitungsprogramm Eurer Wahl und speichert es unter BMP und dann
> unter PNG.

Das ist sinnlos.

Deine Digiknipse verwurschtelt das Bild ja bereits als JPEG.  Die
daraus resultierenden JPEG-Artifakte nochmals durch einen Algorithmus
für eine lossless compression zu ziehen, kann nicht ernsthaft
funktionieren.

Wenn schon, müsstest du als Ausgangsbasis eine 24-bit-TIFF- oder
Targa-Datei nehmen, wie sie beispielsweise beim Scannen eines analogen
Fotos entsteht.  Aber nichtsdestotrotz ist es sinnvoller, auch dieses
Ergebnis am Ende als JPEG zu speichern, da das nun einmal für Fotos
optimiert worden ist.

Für die Bildinhalte, für die PNG sinnvoll ist, habe ich noch keinen
nennenswerten Unterschied in den Speicherzeiten feststellen können in
Abhängigkeit von der Kompression.  Ein GIMP speichert auch standard-
mäßig mit Level 9.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
p.s.: Habe gerade ein 2-Mpixel-Bild genommen, das ich noch in /tmp
liegen hatte.  Mit GIMP aufgemacht und als PNG abgespeichert, alle
Voreinstellungen gelassen (also auch Kompressions-Level 9), ist es
in 3 Sekunden gespeichert.  Logischerweise ist das PNG natürlich
viel größer als das originale JPEG.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Das ist sinnlos.
>
> Deine Digiknipse verwurschtelt das Bild ja bereits als JPEG.  Die
> daraus resultierenden JPEG-Artifakte nochmals durch einen Algorithmus
> für eine lossless compression zu ziehen, kann nicht ernsthaft
> funktionieren.

Wenn die Knipse nur jpeg erzeugen kann, man aber das Bild nachbearbeiten 
möchte, ist es sinnvoll, es erst als png zu speichern.
jpg verschlechtert sich bei jedem Speichervorgang. Bei Bildbearbeitung 
speichert man normalerweise öfter. Das sollte man in png machen. Erst 
die letzte Version kann man dann wieder nach jpg wandeln und 
abspeichern.
Zum Datenaustausch (in Foren) nimmt man natürlich die jpg-Version, 
sofern nicht ausdrücklich anders gewünscht.
Das nochmal zur Ergänzung.

@HildeK
> Für reine Grafiken sind aber PNG oder GIF ideal - hier scheint auch die
> Optimierung mehr zu bringen.

Lies nochmal diverse Artikel über Bildformate, nur um weitere Blamagen 
zu vermeiden. Mir scheint, auch du hast die Grundlagen nicht verstanden. 
Natürlich ist png und gif nicht für Fotos geeignet, sondern für Grafiken 
mit hohen Kontrasten und wenig Farbverläufen. Also sowas wie 
Schaltpläne, Skizzen,...
jpg hingegen taugt nicht für Schaltpläne oder Layouts, weil jpg keine 
hohen Kontraste darstellen kann und somit die Linien in Schaltplänen 
verwaschen werden. Außerdem ist ein Schaltplan in png kleiner als in 
jpg, gemeint ist die Dateigröße.
Schlimm, schlimm, dass man hier die allereinfachsten Dinge erklären 
muss, obwohl es hier sogar ein Kapitel über Bildformate gibt. Eigentlich 
sollte man von einem mündigen Bürger erwarten, dass er fähig ist, dieses 
Wissen sich selber anzueignen. So neu sind die verschiedenen Bildformate 
nun wirklich nicht.
kopfschüttel

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gast wrote:

>> Deine Digiknipse verwurschtelt das Bild ja bereits als JPEG.  Die
>> daraus resultierenden JPEG-Artifakte nochmals durch einen Algorithmus
>> für eine lossless compression zu ziehen, kann nicht ernsthaft
>> funktionieren.

> Wenn die Knipse nur jpeg erzeugen kann, man aber das Bild nachbearbeiten
> möchte, ist es sinnvoll, es erst als png zu speichern.
> jpg verschlechtert sich bei jedem Speichervorgang.

Wenn es dir nur darauf ankommt, kannst du auch gleich TIFF nehmen. :)

Autor: HildeK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gast wrote:
>@HildeK
>> Für reine Grafiken sind aber PNG oder GIF ideal - hier scheint auch die
>> Optimierung mehr zu bringen.

>Lies nochmal diverse Artikel über Bildformate, nur um weitere Blamagen
>zu vermeiden.
.
.
>kopfschüttel

Ich kenne mich mit den diversen Bildformaten ganz gut aus. All das, was 
du geschrieben hattest, ist mir längst bekannt. Deine Belehrung, dein 
Tonfall und dein Kopfschütteln waren unangebracht bzw. überflüssig.

Ich wollte nur deutlich machen, dass BMP (oder auch TIFF, wobei hier 
schon mal das eine oder andere Programm Interpretationsschwierigkeiten 
hat) als Zwischenformat auf dem Rechner seine Berechtigung hat und nicht 
grundsätzlich durch PNG ersetzt werden kann bzw. soll!
Ich habe hier zum ersten Mal überhaupt versucht, ein Foto als PNG zu 
speichern - einfach, um z.B. zu sehen, was Sache ist.

Mit PNG ist es möglich, ein True-Color-Farbfoto zu speichern - ohne 
Verluste an Qualität - aber es ist nicht sinnvoll. Dass ein 
Digicam-Bild vorher in JPEG war und bereits Artefakte hat, ist auch 
klar. Es sollte in dem Beispiel nur als Ausgangsmaterial dienen (ich 
habe kein Foto, welches niemals in einem Zwischenschritt JPEG-codiert 
war) für den kleine Test und die Beantwortung der Frage, warum keine 
bessere Optimierung in den BB-Progs eingebaut ist: weil es, je nach 
Vorlage lange dauern kann, weil es zum weiteren Platz sparen ev. zu 
wenig effektiv ist und weil es für reine Grafiken bereits ganz brauchbar 
implementiert ist.

> Wenn die Knipse nur jpeg erzeugen kann, man aber das Bild nachbearbeiten
> möchte, ist es sinnvoll, es erst als png zu speichern.

Nein, nicht sinnvoll!
Weil es dauert und weil bei dem heute verfügbaren Plattenplatz dieser 
Größengewinn von 'nur' 60% die Wartezeit nicht aufwiegt. Hier hat u.a. 
BMP eine Berechtigung.
Es könnte noch mehr Sinn machen, das bearbeitete Foto im programmeigenen 
Format zu speichern, um weitere Korrekturen anbringen oder bereits 
vorgenommene Änderungen zurücknehmen zu können, ohne wieder ganz von 
vorne beginnen zu müssen.

Karl (Gast) wrote:
>Also die Option, den Kompressionsfaktor einzustellen soll ja weiter
>vorhanden sein!!!
Ich habe nichts dagegen! Erschien mir aber deshalb nicht sooo wichtig, 
weil die absoluten Zeiten und auch der Platzgewinn bei reinen 
Grafikvorlagen gering sind für unterschiedliche Optimierungsstufen.

Und - die Forensoftware optimiert nach! Das war der Beginn des Threads.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Karl (Gast)

>noch jemand benutzt, gibt es keinen Grund, BMP als Austauschformat zu
>verwenden!

Sicher.

>> Weil die Standardkomprimierung von PNG gut genug ist?

>Wie man am zusätzlichen Kompressionsfaktor dieser Zusatzprogramme sieht,
>ist die Standardkomprimierung von PNG eben nicht gut!

Mach mal halblang. Wir reden hier über ein paar Dutzend kb, das ist im 
DSL-Zeitalter nun wirklich Peanuts. Ob ein Bild nun mit Standard-PNG 
Kodierung 150k oder mit OptiPNG 100k hat ist vollkommen egal.

>variabel, also einstellbar, machen. Wenn es also ganz schnell gehen
>muss, nimmt man eben eine schlechte Komprimierung wie bisher.

Ist wünschenswert, aber nicht zwingend notwendig.

>zweifeln. Das ist besonders in einem technischen Forum wie diesem nicht
>entschuldbar. Solche Kenntnisse gehören heutzutage zur Allgemeinbildung.

Eigentlich schon. Aber wie man sieht, gibt es da bisweilen noch einiges 
an Nachholebedarf.

MFG
Falk

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Wie man am zusätzlichen Kompressionsfaktor dieser Zusatzprogramme sieht,
>>ist die Standardkomprimierung von PNG eben nicht gut!
>
>Mach mal halblang. Wir reden hier über ein paar Dutzend kb, das ist im
>DSL-Zeitalter nun wirklich Peanuts. Ob ein Bild nun mit Standard-PNG
>Kodierung 150k oder mit OptiPNG 100k hat ist vollkommen egal.
>

>>variabel, also einstellbar, machen. Wenn es also ganz schnell gehen
>>muss, nimmt man eben eine schlechte Komprimierung wie bisher.
>
>Ist wünschenswert, aber nicht zwingend notwendig.


 Falk du widerspricht dir selber.
Erst hälst du eine bessere Komprimierung nicht für nötig, obwohl diese 
nichts zusätzlich kosten würde und auch keine wesentlich höhere 
Rechenpower benötigen würde.

Dann sagst du, ein einstellbarer Komprimierungsfaktor wäre nicht 
notwendig. Obwohl dann jeder zwischen eigenen Bedürfnissen an Dateigröße 
und notwendiger Rechnzeit auswählen könnte.

Es ist auch ziemlich arrogant, zu behaupten, jeder hätte DSL und 
Speicherplatz wäre heutzutage nicht mehr wichtig.

Im Ganzen ist dein Posting hier nicht mehr als geschmackloses Getrolle.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Gast (Gast)

> Falk du widerspricht dir selber.

Kommt selten vor.

>Erst hälst du eine bessere Komprimierung nicht für nötig, obwohl diese
>nichts zusätzlich kosten würde und auch keine wesentlich höhere
>Rechenpower benötigen würde.

>Dann sagst du, ein einstellbarer Komprimierungsfaktor wäre nicht
>notwendig.

Darin liegt kein Widerspruch.

>Es ist auch ziemlich arrogant, zu behaupten, jeder hätte DSL und
>Speicherplatz wäre heutzutage nicht mehr wichtig.

Ihr irrt euch, mein Herr. Schau mal nach wer den Artikel Bildformate 
geschrieben hat . . . und wer ihn des öfteren zur Lektüre empfiehlt . . 
.

MfG
Falk

Autor: Heinrich (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
>>Es ist auch ziemlich arrogant, zu behaupten, jeder hätte DSL und
>>Speicherplatz wäre heutzutage nicht mehr wichtig.
>
>Ihr irrt euch, mein Herr. Schau mal nach wer den Artikel Bildformate
>geschrieben hat . . . und wer ihn des öfteren zur Lektüre empfiehlt . .
.
Tja, wer schrieb jetzt nochmal:

> Mach mal halblang. Wir reden hier über ein paar Dutzend kb, das ist im
> DSL-Zeitalter nun wirklich Peanuts. Ob ein Bild nun mit Standard-PNG
> Kodierung 150k oder mit OptiPNG 100k hat ist vollkommen egal.

Ja, dann mach mal halblang. So langsam machst du dich hier wirklich 
lächerlich. Wenn doch die Möglichkeit einer besseren Komprimierung 
besteht, warum sollte man sie nicht nutzen können und je nach Bedarf die 
Kompressionsrate einstellen dürfen? Tut doch niemanden weh, wenn die 
Grafikprogramme eine bessere Komprimierung eingebaut haben. Weiter oben 
hat wer gezeigt "45k PNG mit optipng -o7: 21k (52%!)", also so 
unwesentlich ist das nicht. Oder ist das eine krankhafte Veranlagung bei 
dir, immer das letzte Wort zu haben?

Weiteres Beispiel (willkürliche Datei genommen): 
http://www.dzionsko.de/elektronic/usbinterface/usb...
Originaldatei: 79074 Bytes
optimierte Version: 30883 Bytes

Autor: Benedikt K. (benedikt) (Moderator)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Heinrich wrote:

> Weiteres Beispiel (willkürliche Datei genommen):
> http://www.dzionsko.de/elektronic/usbinterface/usb...
> Originaldatei: 79074 Bytes
> optimierte Version: 30883 Bytes

Und als gif 19611 Bytes...
OK, ich habe gemogelt. Daran sieht man aber: Ein noch so gutes 
Bildformat bringt nichts, wenn der Benutzer nicht damit umgehen kann.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> OK, ich habe gemogelt.

Wendest du die gleiche Mogelei auf das PNG an, reduziert sich die Größe
sogar auf 10453 Bytes ;-)

Autor: Gast (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
> Wendest du die gleiche Mogelei auf das PNG an, reduziert sich die Größe
> sogar auf 10453 Bytes ;-)

Nö. Mit gimp auf 2 Farben reduziert, als png abgespeichert, dann mit 
optipng optimiert, macht 10247 Bytes.

Autor: Gast (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich war dumm. Man müsste halt gimp bedienen können:
9651 Bytes

Autor: Gast (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
> Und als gif 19611 Bytes...

Bei mir 18474 Bytes. Ohne spezielle Optimierungen.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Heinrich (Gast)

>lächerlich. Wenn doch die Möglichkeit einer besseren Komprimierung
>besteht, warum sollte man sie nicht nutzen können und je nach Bedarf die
>Kompressionsrate einstellen dürfen?

Hat jemand das Gegenteil behauptet?
Nein.
Aber wenn siese Option nicht besteht, ist das kein wirklicher Verlust.

>Grafikprogramme eine bessere Komprimierung eingebaut haben. Weiter oben
>hat wer gezeigt "45k PNG mit optipng -o7: 21k (52%!)", also so

Schön, aber ein 45kB Bild kann man selbst per Modem laden.

>Weiteres Beispiel (willkürliche Datei genommen):
>http://www.dzionsko.de/elektronic/usbinterface/usb...
>Originaldatei: 79074 Bytes
>optimierte Version: 30883 Bytes

Ja, aber wie  Benedikt K. seht treffend schrieb

>OK, ich habe gemogelt. Daran sieht man aber: Ein noch so gutes
>Bildformat bringt nichts, wenn der Benutzer nicht damit umgehen kann.

Hätte der Ersteller den Schaltplan gleich im CAD (Egale?) mit zwei 
Farben generiert, wäre das Standard-PNG so klein und minimal, dass sich 
jegliche
Diskussion erübrigt. Und es gäbe auch keine Fransen an Strukturen.

MFG
Falk

Autor: Heinrich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Hat jemand das Gegenteil behauptet?
> Nein.

Doch. Lies dein eigenes Getrolle.

> Aber wenn siese Option nicht besteht, ist das kein wirklicher Verlust.

Es wäre aber trotzdem gut wenn es die Option gäbe, dazu noch kostenlos 
und ohne dass sich der User ein zusätzliches Programm suchen muss. Wenn 
die Möglichkeit besteht, die Dateien kleiner zu bekommen, dann kann man 
das auch nutzen. Es handelt sich hierbei ja nicht um die Einsparung von 
1% oder 2%, sondern um viel mehr!

>>Grafikprogramme eine bessere Komprimierung eingebaut haben. Weiter oben
>>hat wer gezeigt "45k PNG mit optipng -o7: 21k (52%!)", also so
>
>Schön, aber ein 45kB Bild kann man selbst per Modem laden.

Es geht nicht darum, ob für ein 45kB Bild ein Modem schnell genug ist. 
Es geht ums Prinzip, um die Möglichkeit ohne Mehraufwand für den User 
kleinere Dateien zu erzeugen und somit Datenmüll zu reduzieren. Bei 
vielen Dateien hat das dann auch einen sehr signifikanten Nutzen.


> Hätte der Ersteller den Schaltplan gleich im CAD (Egale?) mit zwei
> Farben generiert, wäre

Ja da hast du recht, aber auch im diesen Falle hätte optipng was 
gebracht.

Und jetzt troll dich.

<°)))o><

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.