• Herzlich willkommen im "neuen" DSLR-Forum!

    Wir hoffen, dass Euch das neue Design und die neuen Features gefallen und Ihr Euch schnell zurechtfindet.
    Wir werden wohl alle etwas Zeit brauchen, um uns in die neue Umgebung einzuleben. Auch für uns ist das alles neu.

    Euer DSLR-Forum-Team

  • In eigener Sache!

    Liebe Mitglieder, liebe Besucher und Gäste
    ich weiß, es ist ein leidiges Thema, aber ich muss es ansprechen: Werbung, Werbeblocker und Finanzierung des Forums.
    Bitte hier weiterlesen ...

  • DSLR-Forum Fotowettbewerb neu erfunden!
    Nach wochenlanger intensiver Arbeit an der Erneuerung des Formates unseres internen Fotowettbewerbes ist es Frosty als Moderator
    und au lait als Programmierer gelungen, unseren Wettbewerb auf ein völlig neues Level zu heben!
    Lest hier alle Infos zum DSLR-Forum Fotowettbewerb 2.0
    Einen voll funktionsfähigen Demowettbewerb kannst du dir hier ansehen.
  • Neuer Partner: AkkuShop.de
    Akkus, Ladegeräte und mehr (nicht nur) für Digitalkameras und Drohnen
  • Neuer Gutscheincode unseres Partners Schutzfolien24:
    DSLR-Forum2024
    Dauerhaft 10% Rabatt auf alle Displayschutzfolien der Eigenmarken "Upscreen", "Brotec", "Savvies".
    Der Code ist für alle Geräteklassen gültig.
  • Stimmt ab über die Sieger des DSLR-Forum Fotowettbewerbs April 2024.
    Thema: "Sprichwörtlich"

    Nur noch bis zum 30.04.2024 23:59!
    Jeder darf abstimmen!
    Zur Abstimmung und Bewertung hier lang
WERBUNG

Guetzli Jpeg Encoder von Google

Berlin

Themenersteller
Google hat einen neuen Jpeg Encoder veröffentlicht, ich habe mal ein Binary auf Windows 10-64 getestet. Nach ca. 30 min !! :grumble: Laufzeit für ein (1) Bild der GX80 war er fertig, das Ergebnis war etwas besser als aus Photoshop, aber es ist schwer die Qualitätsstufen zu vergleichen. Für Laufzeit und Speicherbedarf müssen die Erfinder noch einiges tun


http://winfuture.de/news,96688.html

http://www.edugeek.net/forums/downl...hly-optimized-jpeg-encoder-windows-linux.html
 
Zuletzt bearbeitet:
Erkläre doch bitte wozu das Ding gut ist.
Was geht in den Encoder herein und was kommt heraus.
 
Kannst du nicht selbst lesen, da sind doch 2 Links.
 
Zuletzt bearbeitet von einem Moderator:
Google hat einen neuen Jpeg Encoder veröffentlicht, ich habe mal ein Binary auf Windows 10-64 getestet. Nach ca. 30 min !! ...war er fertig

Was hast du denn da für ein Bild genommen? Ein Gigabyte-Bild?

Klar ist, dass dieser JPEG-Encoder zum Erstellen der JPEG-Datei länger braucht. Schon mal 2 Minuten für ein 4K-Bild. Du darfst dabei aber nicht vergessen, dass die Zielgruppe nicht diejenigen sind, die ihre Fotos in höher Auflösung archivieren wollen. Dazu gibt es große und preiswerte Festplatten.

Das Ziel ist eindeutig das WEB. Also relativ kleine JPEG-Bilder, die nur ein einziges Mal in JPEG umgewandelt werden und dann tausend- oder millionenfach heruntergeladen werden. Und da es sich immer noch um ein Bild nach dem JPEG-Standard handelt, geschieht das genauso schnell wie bei anderen JPEG-Bildern auch.

Nur, dass es eben deutlich kleiner bei besserer Bildqualität ist (z.B. weniger Artifakte) .
 
Das Ziel ist eindeutig das WEB. Also relativ kleine JPEG-Bilder
Google selber ist da aber anderer Meinung: "Note that Guetzli is designed to work on high quality images". Damit dürften wohl keine 600x400 Vorschaubildchen gemeint sein. Es ist eben dazu gedacht, Bilder für HighDPI-Anwendungen nahezu ohne visuellen Qualitätsverlust kleiner zu speichern wie es JPG tut. Welchen Encoder Google als Vergleich für die versprochenen 20-30% Ersparnis heran zieht, weiss ich nicht.

Das ganze ist aber derzeit eher ein Prove of Concept. Dass Google so eine Software ohne jegliche Parallelisierung veröffentlicht wundert mich schon sehr.

An meinem 11 MPix Bild rechnet er mit 2.4 GB Speicherverbrauch und einem CPU-Kern geschlagene 12 Minuten herum (und der i7-2600k langweilt sich zu tode). Das Ergebnis ist zwar bei q=90, im Vergleich zu IrfanView 4.40, um 42 % kleiner (823 KB zu 1,15 MB), dafür sieht man bei genauer Betrachtung, dass er nicht nur in leicht verrauschten Flächen das Rauschen reduziert, sondern auch gesamthaft die Schärfe des Bildes leicht reduziert. Beides ist sicherlich fürs Internet akzeptabel, die Komprimierungszeiten dagegen nicht.

Und ja, 11 MPix sind realistisch, 4k sind 8,8 MPix bei 16:9, beim 5K-Monitor ist man schon bei 14,7 MPix (und immer noch 16:9).
 
Ich habe damit mal herum gspielt gerade.

Ein Bild in 6000 x 4000 als 16-bit tiff war das Ausgangsbild, so wie man es eben normal hat, wenn man seine RAWs aus der Kamera entwickelt und bearbeitet hat. Daraus wurde dann erst mal ein lossless png mit 2048 x 1533 px per Photoshop, diese Größe hat man oft mal im Netz - und Guetzli rechnet dann nicht so lange.

aus diesem png wurde dann erst mal:

* ein jpg mit maximaler Qualität in Photoshop, das dann 2.8MB groß war.
* ein jpg mit maximaler Qualität (-- quality 100) aus Guetzli, das war damit 3,8MB groß.

==> Hier sind keinerlei Unterschiede in der Qualität zu erkennen. Beides ist ziemlich gut. Aber Guetzli ist eine ganze Ecke größer...

Dann habe ich die minimale Qualität bei Guetzli verwendet (--quality 84, weniger geht nicht wenn man nicht im code was ändert), das ergab ein Bild das 688kB groß war. Analog dazu habe ich in PS aus dem png dann ein Bild mit ungefähr dieser Dateigröße als Optimierungsziel erstellt, das ergab ein Bild mit 680kB. Wobei PS das in 1s hatte, Guetzli hat ewig gerechnet dafür, mehrere Minuten trotz FX8350 @ 5GHz (der deutlich unterfordert und kein bisschen ausgelastet war, das Problem sind wohl extrem viele Speicheroperationen...).

==> Hier sind die jpg mit dem Algorithmus von Photoshop einen ticken besser.
Aber das Bild ist jeweils voller sichtbarer Artefakte.

Anschließend habe ich noch Guetzli mit default einstellungen verwendet, das gab ein jpg mit 1.25MB. Parallel habe ich noch in PS auf eben diese Dateigröße optimiert. Das gab auch 1.25MB beim Bild. Auch hier: PS hat das in 1s. Guetzli braucht mehrere Minuten.

==> Hier ist das Guetzli-jpg einen Hauch von minimal besser. Aber PS (mit Qualität 75 dann...) eben kaum schlechter. Gegenüber einem jpg, das in PS mit maximaler Qualität erstellt wurde sind die Unterschiede jedenfalls extrem deutlich sichtbar.

Und insgesamt wirken die Guetzli-jpg leicht flau und kontrastarm, auch die Farben passen nicht mehr 100% (im Gegensatz zu jpg aus PS).

Anschließend habe ich das noch mit verschiedenen Bildern und verschiedenen Auflösungen gerechnet. Wobei sich die Berechnungszeit von Guetzli und auch der Speicherhunger von Guetzli exponential mit der Größe des Bildes zu erhöhen scheint. Schon für ein 2048x1566 px Bild sind es mehrere Minuten und mehrere hundert MB, die benötigt werden. Und ein png in 6000 x 4000, das als original 140MB groß ist, das dauert wirklich ewig. Und Guetzli belegt eben mal bis zu rund 6GB RAM dafür.

Mein Fazit:
Guetzli is noch nicht so wirklich das gelbe vom Ei. Ich werde erst mal bei PS bleiben. Da habe ich zu 99,99% die selbe Qualität in < 0,1% der Rechenzeit.
 
Zuletzt bearbeitet:
Die Sache ist halt die, das Adobe einen extrem guten JPEG-Encoder hat, der aber eben closed source ist und somit für die meisten im Netz nicht benutzbar.
 
nach kurzen weiteren Tests, wieder mit einem kleineren Bild:

Die jpg aus Guetzli default sind 1.25MB groß, wie gehabt.
Ein jpg in gleicher Qualität ist aus PS auch 1.25 groß. Hier eben 75% Qualität.

Nimmt man aber Gimp, muss man auf 96% Qualität gehen für ebenso wenige Artefakte. Und kriegt dann 1.9 MB große Bilder. Gegenüber Gimp und damit libjpeg hat also guetzli durchaus Vorteile.
 
Also ich kauf mit lieber eine neue Festplatte, statt alle meine jpeg's durch dieses Teil zu jagen.
Da bin ich ja noch übermorgen dran.
Aber danke für teilen.
 
Zuletzt bearbeitet:
Noch jemand der nicht lesen kann:(
Als ob wir jede Kamera ausweendig kennen und dann noch wissen, was Du an der Kamera eingestellt hast. Deinen Rechner dürfen wir auch erraten.

Aber es ist natürlich einfacher den User auf Google suchen und den Rest erraten zu lassn anstatt die Daten hier rein zu schreiben. Auf meinem Atom-Tablet wird das ganze Sicherheit länger brauchen und mit der allgemeinne Performancesteigerung sollte mein 11 MPix Bild auf einer ansatzweise modernen CPU (i7-7700K) in unter 6 Minuten berechnet sein.

Das ganze im Batchbetireb (wieviel Bilder werden wohl täglich auf Facebook oder schon nur Google+ hochgeladen) und die Laufzeit für ein einzelnes Bild ist nicht mehr ganz so wichtig.

Sehr viel zu langsam und imho nicht konkurrenzfähig.
Es ist halt keine Konkurenz zum 1000 Euro PS, sondern u.U. ein Ersatz für einen automatisierten Workflow zur Komprimierung der Bilder beim Einsatz im Internet.

Wenn das Thema Perfromance mal korrigiert wurde, steht zu befürchten, dass solch ein Algorithmus beim Upload in Facebook und co. schlicht Standard wird....vollkommen egal, wie das Bild vorher schon komprimiert wurde. Spätestens bei automatisch verkleinerten Versionen.

Es wird niemand jemals PS zur Automatisierung dieses Vorgehens auf einem Unix-Server integrieren.
 
Ich denke die Frage, ob der veröffentlichte Algorithmus zum jetzigen
Zeitpunkt irgentwo sinnvoll eingesetzt werden kann, stellt sich so gar
nicht, insofern ist auch jegliche Aussage darüber irrelevant.

Interessant sind (m.M.n.) folgende Fakten:

1) Der Vergleich mit der libjpeg, die auch quelloffen verfügbar ist (im
Gegensatz zu anderen Implementierungen), fällt bzgl. der Bildqualität
bzw. dem benötigten Speicherplatz zugunsten von Guetzli aus. Dagegen
fällt der Performance-Vergleich eindeutig zugunsten der Libjpeg aus.
(*1)

2) Da Google die quelloffene Veröffentlichung wählt, kann ein geneigter
Leser/Tester eigene Änderungen ausprobieren, und diese ggf. auch
veröffentlichen. Das ist aus naheliegenden Gründen mit einer nicht
quelloffenen Implementierung nicht möglich.

Ob das Verfahren jemals wirkliche Relevanz erhält, liegt ganz wesentlich
an seiner weiteren Entwicklung bzgl. Performance, und ggf. an Googles
Lizenzpolitik. (Allein dass es quelloffen ist, heisst ja nicht, dass es jeder nach
gutdünken nehmen darf).

Ich würde das Verfahren jedenfalls jetzt (so kurz nach seiner Geburt)
noch nicht gleich totsagen.

*1: Ein ähnliches Verhalten (bzw. eine ähnliche Entwicklung) sieht man
übrigens bei der Entwicklung von neuen verlustfreien Kompressionsmethoden.
Auch hier sind Neuerungen oft bzgl. der Kompressionsleistung hergebrachten
Verfahren überlegen, an der Performance hapert es aber oft. Andererseits
zeigt die Entwicklung von 7zip (und den darin eingebetteten Verfahren (lzma xz
und ppmd) dass die weitere Entwicklung von Algorithmen ihnen oft
Anwendungen eröffnet, die zu Beginn nicht im Bereich des möglichen lagen.
(Und wer weiss, was aus zpaq und bsc noch wird).
 
Zuletzt bearbeitet:
(...)
Ob das Verfahren jemals wirkliche Relevanz erhält, liegt ganz wesentlich
an seiner weiteren Entwicklung bzgl. Performance, und ggf. an Googles
Lizenzpolitik. (Allein dass es quelloffen ist, heisst ja nicht, dass es jeder nach
gutdünken nehmen darf).

Doch, das genau heißt es mehr oder weniger hier, Google hat die Software ja unter der Apache 2.0 Lizenz veröffentlicht. Was bedeutet, dass erst mal jeder die Software nehmen und verwenden darf und auch für eigene Projekte abändern und das dann weiter geben darf, solange er sich an die Vorschriften der Lizenz hält. Die sagen aber im Wesentlichen aber nur, dass man die mitgelieferten Lizenzinformationen nicht entfernen darf und dass man die mitgelieferten "Notice" Textdatei nicht entfernen darf und um einen Eintrag mit Hinweisen auf die eigenen Änderungen ergänzen muss.
Und eigene Software, die Teile von Apache 2.0 Software enthält, muss eben nicht zwingend unter Apache Lizenz stehen.

So dass man hier mit etwas Glück wohl durchaus noch Weiterentwicklungen sehen wird. Allerdings ist das Verfahren hier im Vergleich zu anderen Verfahren zur jpeg-Erzeugung schon vom Prinzip her extrem aufwendig (Details siehe Paper hier: https://arxiv.org/abs/1703.04421 ), sowohl was die Rechenzeit als auch was die Speicherverwendung an geht. Und selbst mit neueren Rechnern, besseren Parallelisierungen usw. wird es durch die ganzen Optimierungs-Loops immer um Welten langsamer und Ressourcenfressender sein als libjpeg, mozjpeg und Co.
 
Doch, das genau heißt es mehr oder weniger hier, Google hat die Software ja unter der Apache 2.0 Lizenz veröffentlicht.

Das ist doch was ich meinte...was macht dich so sicher, dass Google es unter dieser
Lizenz lässt? ... Dass das Verfahren aktuell nicht wirklich zu gebrauchen ist,
steht ausser Frage ... aber wenn die Verbesserungen gedeihen, könnte sich
durchaus die Lizenz ändern.
 
WERBUNG
Zurück
Oben Unten