A customer of mine had problems that their PNG images were far too big after Neos created thumbnails for them.
So a 300kb original image could lead to a 3mb thumbnail with smaller dimensions.
During my research I found that one of their system used GD and another Vips.
Both had the same problem.
At the end created a small test script to see whether Neos did something wrong or something else is at fault.
Results when only setting png_compression_level to 0:
Original - 1400x878 - 584kb
GD - 700x439 - 1.231kb
IMagick - 700x439 - 268kb
Vips - 700x439 - 1.231kb
So Vips uses less resources but has the same bad result as GD.
I checked the implementation of rokka/vips and it seems it doesn’t run pngquant (when compiled into vips) when png_quality is 100. See https://github.com/rokka-io/imagine-vips/blob/master/lib/Imagine/Vips/Image.php#L979
Now Neos has a default quality of 90 but doesn’t set png_quality as it’s not a default imagine variable.
So changing the png_quality to 99 or down to 90 suddenly makes a big change and the file size goes down to 300kb. Still more than IM but much better. With an image comparison tool both version look pixel level identical.
To finally get a better result with Vips that all others increasing the png_compression_level 1 makes another big change:
GD - 700x439 - 184kb
IMagick - 700x439 - 193kb
Vips - 700x439 - 66kb
But this actually now leads to a slightly reduced image quality.
I tested everything then in the Neos.Demo project with Neos 5 and in my customers project.
I would be interested whether you use Vips yet and had similar issues and get better results with changing your image default settings like this:
Media:
image:
defaultOptions:
quality: 90
png_quality: 90
png_compression_level can be increased by lowering quality to 88.
You have to run flow media:clearthumbnails to force Neos to regenerate the images. My test script can be found here https://gist.github.com/Sebobo/94dd8ea909d2ed6ae813b7df70c20dc1