Image Compression - Filesizes increasing
Hi Guys,
So I have just implemented some Responsive Images in my perch template using srcset and sizes with picturefill as a polyfill. I am creating 4 different sizes plus the original file that I am uploading. However, I am a little concerned by the output file sizes. I fully appreciate that image tools like ImageAlpha, ImageOptim etc will do a better job on compression than the likes of server tools. But I thought I should ask about this and raise this anyway.
So the original file I am uploading is a transparent PNG file that is 1600px wide. After exporting from PS and running through ImageAlpha and ImageOptim my filesize for the graphic was 365KB.
In my template I have settings to create the image at 1200, 900, 640 and 320px wide. On uploading the image, here are the results of the filesizes.
1600px - 365KB (original and untouched by perch)
1200px - 1MB
900px - 616KB
640px - 318KB
320px - 89KB
As a result my biggest image is only slightly larger (filesize) than the 640px equivalent, which kind of makes this whole process and technique redundant.
I m not sure of an answer or if there even is one? With performance in mind are there any plans for better compression techniques? I don't suppose there is an option/ability to integrate imageAlpha/ImageOptim via the server/upload process is there?
Perhaps this is a unique use case as clients would perhaps start of with larger images initially, but wanting to use Perch for my site and save me the hassle of generating 10 images (5 for the banner and 5 for the main image) per portfolio item would been a great time saver.
Any thoughts or suggestions or future plans?
Thanks. Terry
Not sure if this helps at all? https://stackoverflow.com/questions/13257405/why-is-resized-png-image-so-much-bigger-than-original-image
Perhaps the imagecreate rather than imagecreatetruecolor might be the anwser?
As PNG8 gets re-encoded as PNG24? - I might change this in the perch Imageclass to run a test and report back with the results...
Does it make a difference if you switch to imagick?
Will check this later Drew. I did a test using just imagecreate - whilst this kept the image sizes nice and small, it didn't look great as it changed the palette (reduced) so the colours were off and looked 'rendered'. I will read up a little more on this.
Will come back to you shortly.
Just wanted to chime in that I'm having the exact same issue. I have both ImageMagick and GD installed.
I don't have anything constructive to add at the moment, but I'm exploring options and will post back here if I come up with anything.
Thanks David. Did you try it with ImageMagick? I have yet to to try. Were the image sizes very similar to that of GD?
I think so… I thought Perch used ImageMagick by default if it was installed, and only used GD if ImageMagick was missing, but maybe I'm mistaken. I'll try to get some tests in this week and post the results.
I think you need to set it in the preferences. https://docs.grabaperch.com/docs/installing-perch/configuration/images/
Ah, thanks. GD is the default; I had it backwards in my head. Will double check my setup and report back soon.
Still haven't had a chance to test yet, but I found another potentially relevant StackOverflow thread while checking on a similar issue that was occurring in my grunt tasks. From this it looks like ImageMagick may very well be affected, too.
I have just this second tested ImageMagick. Whilst the file sizes are slightly smaller than that of GD they are still way bigger than the original. Here are my results.
1600px - 365KB (original and untouched by perch)
1200px - 914KB
900px - 540KB
640px - 289KB
320px - 85KB
I have also uploaded all the images online here - https://www.amasci.co.uk/perch-images/
So you can see these for reference if it helps at all?
Thoughts Drew? Any Suggestions for Moving Forward?
I was sent these resources via twitter if of any use/insightful?
pngquant (that powers ImageAlpha) can be used server-side from PHP: pngquant.org/php.html
ImageAlpha ~= github.com/pornel/pngquant UI, you could maybe give that a whirl.
What you are describing sounds like the PNG8 with full alpha gets reencoded to PNG24, thereby bloating filesize.You can daisy-chain pngout & pngcrush to achieve the same effect as ImageAlpha on the server (CLI). See speakerdeck.com/tbaldauf/image… for a code example.
The issue is that Perch really is at the disposal of what's available on the server. It's good and well that
pngquantexists, but if it's not on your hosting, there's not a lot Perch can do about it.Even if something like that happened to be available, or was installable, the next limitation is the ability for PHP to call out and use them. That sort of thing tends to work ok if you have full control of the server, but is a non-starter on shared hosting.
Perch can only do what PHP on your server can do.
OK thats understandable. But is there anything we can do about GD or ImageMagik ramping up the image sizes when it converts? Is there another method of saving. Like on GD it seemed to be creating them as PNG24? Could it be done to save as PNG8? Or a setting to control this?
Just thinking aloud really.
Anything you can suggest from a GD/ImageMagik perspective to help with this?
Thanks.
There's quite possibly improvements that can be made, and we'd be keen to do that if possible. It's just a question of finding the time to focus on it.
Hi Drew,
Don't suppose you had any further thoughts on this at all?
Appreciate you are busy, but thought I would just 'check-in'.
Thanks, Terry
Not currently - we do log all requests however so there isn't any need to keep chasing.
For ImageMagick, you might want to look at resizing using sampleImage(). In the CLI for ImageMagick, this is producing much smaller file sizes than a plain resize for me.
Hi David,
Can you elaborate for me at all? I am not too sure where/how I would do this.
Thanks Terry
I haven't made any progress, but I have looked into it. The issue I've run up against is how to determine an image needs to have true colour processing. If I could crack that one, we could switch between using
imagecreateandimagecreatetruecoloras needed.Terry—ignore my previous comment, I was wrong. I'm looking into different ways to use ImageMagick's various functions to get decent results. Will ping you/post here when I've finished going through stuff.
The best results so far—and Drew, you may be interested in this too, since it address your issue a bit—are from the following steps:
identify -verbose [file]$type = 'Grayscale'and$depth = 8$type = 'Palette'and$depth = 8$type = 'PaletteMatte'and$depth = 8$type = original typeand$depth = original depth$quality = 95$quality = 60$colours = original # of colours$size = target sizeconvert -resize [$size] -quality [$quality] -type [$type] -depth [$depth] -colors [$colours] -stripI'm not convinced those are the best possible results, but so far they're decent.
I haven't looked yet at how that equates to GD or how it translates to the PHP implementation of ImageMagick, but I'll get there hopefully soonish.
Hey all. I have no further input having not really looked at this and it going a little over my head too.
But thought I would see if anyone had any further findings or anything to share?
David, how did you get on with your imageMagick functions tests?
I think for now I am going to create one version that is super optimised (using local tools) and use this across the board, rather than using srcset as it will smaller as a result.
Thanks.