There are two primary issues (probably others) with doing it all in one step:
1. The optimization is not native to PHP. We use separate tools/binaries outside of PHP to do the actual optimization.
2. The tools we use do not have native resizing capabilities, and the ones that do are lossless anyway, so it doesn’t matter in those cases.
At the end of the day, it doesn’t really matter. All the tools we use are designed to preserve the utmost in quality, so the fact that optimizing is technically a separate step has no effect on the image quality.
I don’t quite understand your point 2:
2. The tools we use do not have native resizing capabilities, and the ones that do are lossless anyway, so it doesn’t matter in those cases.
My experience tells me that even the tools that are lossless will give a better result when performing resizing+optimization at the same time… but I guess that wasn’t your point. Could you please elaborate a bit more?
And regarding:
At the end of the day, it doesn’t really matter. All the tools we use are designed to preserve the utmost in quality, so the fact that optimizing is technically a separate step has no effect on the image quality.
I disagree again. When downsizing an image pixels from the original are destroyed/lost. In the process the tool/binary has to make choices about how to compensate the loss of those pixels. Because of that, if WordPress downsizes an image and does it in a poor way then it does not matter how good is the other tool/binary that optimizes it –after it has been downsized–, the end result won’t be as good as if we had used only one tool to perform both actions in one single step.
For years I’ve used a tool that does both downsizing and optimization in one single step. In the past I made a comparison between the results for the same images having them downsized with WordPress and with my tool and the results were dramatic. I am willing to repeat that experiment if you find it useful.
Thanks!
-
This reply was modified 6 years, 9 months ago by
diegocanal.
I don’t want toe risk of getting bogged down in a debate that is not going to change anything about our plans for EWWW IO, but I will address what I believe is the primary concern:
Resizing images with PHP CAN introduce visible degradation. It is a pretty common opinion that the default image manipulation library (GD), is not the best one. There ARE better solutions. Notably, most would prefer ImageMagick (imagick) or GraphicsMagick (gmagick).
Because of that, something which IS on the roadmap, is to enable resizing via the API when a user is stuck on GD. This would allow us to use gmagick (which is what our ExactDN system uses) and deliver a cleaner image ultimately.
From your words, if I understood well, my initial enquiry would be addressed in your roadmap by “enable resizing via the API when a user is stuck on GD” (which I believe is 99.99% of the WP user base), right?
Thanks!
Wow, great! Eventually this thread is ending with good news. I suppose there is not ETA yet…
No ETA on the API functionality at this time.
However, I just remembered that this sort of thing CAN be achieved already with our ExactDN service (which already has gmagick, and does optimizing and resizing all in one).
By default, it uses the pre-generated WP thumbnails/sizes (which is why I forgot this was already possible), BUT you can tell it to derive those from the original via the EXACTDN_RESIZE_EXISTING constant: https://docs.ewww.io/article/47-getting-more-from-exactdn