Besseres Image-Processing - Alternativen zu GD Lib?

[voodoopupp]

Aktuell ist die integrierte GD Lib ja nicht so wirklich das Gelbe vom Ei, sei es nun Bildgröße oder Qualität.

Selbst bei 100% Qualität wird ein pixel(gleichgroßes) Bild nachher datenmengentechnisch größer als das Original.

Bsp: wenn ein Bild (z.B. 1200 x 1200px) vorher bereits optimiert wurde - photoshop, jpegmini, tinypng oder was auch immer - und man lädt das Bild im Artikel hoch, wird ein gleichgroßes Popup Bild (1200 x 1200 px) eine größere Datenmenge haben und gleichzeitig qualitativ (minimal) schlechter geworden sein.

Stelle ich die Werte so ein, dass das Bild auch wirklich datenmengenbezogen kleiner wird, dann muss man schon auf Werte um die 80% gehen, aber dann leidet gerade bei den kleineren Bildern die Qualität doch sehr stark.

Es wäre wünschenswert, wenn es irgendeine bessere Alternative zum aktuellen Weg gibt, so dass die Datenmenge verkleinert werden kann und gleichzeitig die Qualität nicht dermaßen darunter leidet...

[Simon Heinrich]

GD Lib wird ja von PHP ausgeliefert und ist bei nahezu allen Webhosting-Tarifen Standard. Welche Alternative sollte man denn hier sonst nehmen?

[Torsten Riemer]

Es gibt hier Dienste, die per API angesprochen werden können und die Bilder entsprechend verlustfrei optimieren, aber das ist mit Kosten verbunden. Ob es hier auch eine entsprechende PHP-Klasse gibt weiss ich nicht bzw. habe ich bisher noch nichts gefunden.

[Volker Strähle]

Ist was für 2.1. Könnte man als AutoInclude-Erweiterung anbieten mit Fallback auf GDLib

[Torsten Riemer]

Kennst du denn hier eine PHP-Klasse, die man benutzen könnte?

[Ines Willenbrock <ines@…>]

Habt Ihr Euch eigentlich jemals Imagemagick angesehen? Die ist auch bei recht vielen Hostern vorhanden, wenngleich man die besser mit allen Parametern füttert beim Bilder umrendern, sonst gehts schonmal schief.
Und: sie kommt mit Farbprofilen zurecht. Das kann der Shop zur Zeit nicht wirklich.

Grüße
Ines

[Torsten Riemer]

Das Problem bei ImageMagick ist, dass es nicht Teil von PHP ist und daher nicht auf jedem Server immer aktuell gehalten wird bzw. dessen Aktualisierung sehr stiefmütterlich behandelt wird.

Aber optional sollte man es natürlich mit anbieten!

[voodoopupp]

Also ich denke, da geht schon was, wenn man etwas will :D

z.B. hier resizing mit imagemagick: ​http://www.smashingmagazine.com/2015/06/efficient-image-resizing-with-imagemagick/

Dazu dann vielleicht noch eine Idee vom gleichen Autor: ​https://github.com/technopagan/cjpeg-dssim

Ebenso scheint ja mozjpeg ne ganz gute Sache zu sein: ​https://github.com/mozilla/mozjpeg

[Torsten Riemer]

Bitte bedenke, dass aus guten Gründen die wenigsten Zugang zur Konsole des Servers haben!

[voodoopupp]

Servus Torsten,

das ist mir klar, ich denke eben nur laut und eventuell kann man ja z.B. einen "lossless-Komprimierer" irgendwie noch mit einbauen, so dass nach der Umwandlung eben noch unnötige KB eliminiert werden können.

Eventuell halt so, dass dieses separat noch aktiviert werden müsste. Und natürlich dann auch nur funktioniert, sofern das entsprechende Modul auf dem Server läuft....

[voodoopupp]

Ebenso sollte es möglich sein, Bilder auch interlaced (progressive) zu speichern: siehe z.B.
​http://blog.patrickmeenan.com/2013/06/progressive-jpegs-ftw.html
​http://www.bookofspeed.com/chapter5.html

[certis]

Von tinypng.com gibt's ein Plugin für Magento, keine Ahnung, ob man das so auch für modified verwenden/anpassen könnte?

Zu finden unter ​https://packagist.org/packages/tinify/magento2

[anonymous]

Jeder Shopbetreiber müsste sich einen Entwickler-Account bei tinyPNG erstellen:
​https://tinypng.com/developers
500 Bilder sind kostenlos, danach kann es richtig teuer werden.

Das lässt sich bei eigenem Server oder gutem Hoster auch direkt auf dem Server einrichten, auch wenn die Kompression nicht ganz so gut ist wie durch TinyPNG.

[timm@…]

Etwas bessere, schärfere Bilder für info und thumbnail_images erhält man wenn man in der image_manipulator_GD2_advanced.php folgenden code einfügt

        // Any other images
        default:
          $dest = imageCreateTrueColor($d_w, $d_h);
        // Sharpen small images
        // return imagecopyresampled($dest, $source, $d_x, $d_y, $s_x, $s_y, $d_w, $d_h, $s_w, $s_h);
        if ($d_w <400) {
            $sharpenMatrix = array
            (
                array(-1.2, -1, -1.2),
                array(-1, 20, -1),
                array(-1.2, -1, -1.2)
            );

            // calculate the sharpen divisor
            $divisor = array_sum(array_map('array_sum', $sharpenMatrix));

            $offset = 0;

            // apply the matrix
            imagecopyresampled($dest, $source, $d_x, $d_y, $s_x, $s_y, $d_w, $d_h, $s_w, $s_h);
            return imageconvolution($dest, $sharpenMatrix, $divisor, $offset);
        }
        else
            return imagecopyresampled($dest, $source, $d_x, $d_y, $s_x, $s_y, $d_w, $d_h, $s_w, $s_h);
      }
        // End of sharpening 

siehe: ​https://www.modified-shop.org/forum/index.php?topic=37084.0

[Torsten Riemer]

Ich habe noch nicht erlebt, dass es einen anderen Grund für unscharfe Bilder gibt als den, dass die Einstellungen für die Größe der Bilder unter "Konfiguration" -> "Bild Optionen" nicht zum Template gepasst haben.

[FräuleinGarn]

Replying to Tomcraft:

Ich habe noch nicht erlebt, dass es einen anderen Grund für unscharfe Bilder gibt als den, dass die Einstellungen für die Größe der Bilder unter "Konfiguration" -> "Bild Optionen" nicht zum Template gepasst haben.

Sorry jetzt erst gesehen.

Die Einstellungen unter Bildoptionen sind bei mir die gleichen, wie im Demoshop, bei gleichem responsive Template, wie im Demoshop und die Bilder sind nun eindeutig schärfer.
Man kann nun die Qualität auf 80% senken, um wesentlich kleinere Bilder von der kilobytegrösse zu erhalten, bei gleicher Qualität, ohne dass google speedpage noch rummeckert, wegen der Größe.

Das wurde von anderen vielschreibern im oben genannten Thread auch bestätigt.

Das ihr eure Bilder im Demoshop nicht mit dem eigenen Imageprocessing erstellt, wird doch einen Grund haben. (Bildernamen enthalten pagespeed ;))

[Torsten Riemer]

Replying to FräuleinGarn:

Replying to Tomcraft:
[...]
Das ihr eure Bilder im Demoshop nicht mit dem eigenen Imageprocessing erstellt, wird doch einen Grund haben. (Bildernamen enthalten pagespeed ;))

Das hat nichts mit der Erstellung der Bilder zu tun, sondern ist ein Mod für den Apache namens "mod_pagespeed". ;-)

[p3e]

@Tomcraft: Teste mal die Änderung der image_manipulator_GD2_advanced.php und vergleiche!
Der Unterschied der Bildqualität ist bei 80% enorm, ohne dass die Datei dadurch größer wird.

[Torsten Riemer]

Im folgenden Modul für WordPress sind ganz interessante Binärdateien für PHP enthalten, die eine Komprimierung lokal auf dem Server ermöglichen: ​EWWW Image Optimizer

[Torsten Riemer]

Hier gibt es bereits eine bereitgestellte Version für unser Shopsystem: ​Bildverarbeitung mit ImageMagick

[voodoopupp]

Replying to Tomcraft:

Es gibt hier Dienste, die per API angesprochen werden können und die Bilder entsprechend verlustfrei optimieren, aber das ist mit Kosten verbunden. Ob es hier auch eine entsprechende PHP-Klasse gibt weiss ich nicht bzw. habe ich bisher noch nichts gefunden.

Ich öffne das Thema nochmal.

Durch die auto_include Funktionalität sollte eine Möglichkeit eingebaut werden, dass man solche APIs von verschiedenen Anbietern updatesicher einbinden könnte.

Grundsätzlich sind diese sicher nicht verkehrt und jeder Shopbesitzer kann dann frei wählen, ob er einen solchen Anbieter nutzen möchte oder nicht.

Ich persönlich bin gerne bereit monatlich dort meinen kleinen Obulus zu entrichten, sofern meine Bilder dadurch von der Datenmenge her kleiner werden und somit meine Webseite schneller wird.

Gerade da nun die Seitenladezeit auch als Rankingkriterium immer wichtiger wird, sind die Bilder immer noch eine große (wenn nicht die größte) Baustelle, die dringendst Beachtung erhalten muss!