Thread Starter
jshare
(@jshare)
Looking over the results, what does this mean:
Reduced by -9.4% ()
It means something happened that should not have happened… it created a larger image than the original. What kind of image was it, and what relevant options do you have enabled for that image type?
Thread Starter
jshare
(@jshare)
Even with debugging on, the log doesn’t show reduction details for each image although you might want to include an option for that, because clicking through over 100 pages of images in the table to look for this information isn’t something I was going to do.
So I just ran the S & O on my live site and copied the output to a file which I’ll send you. This reduction ‘growth’ happened quite a few times, only to gifs, looks like. In over 6000 images, it happened 48 times, usually by -0.0%-0.4% (yes, -0.0%), although there was also a -1.5% in there.
I’m assuming this was gifsicle. In terms of settings, I don’t have gifsicle disabled, and I don’t have gif-to-png conversion enabled.
Are there any other settings that could impact this?
Thread Starter
jshare
(@jshare)
BTW, are the jpegtran-ed jpgs supposed to become progressive?
I’ll have to do some checking on gifsicle then. It isn’t supposed to make images larger (I’ve never seen it do so), so there must be some sort of bug. Can you provide links to original versions of a couple gifs that this happened to?
With JPGs, they will generally become progressive, but not always. It depends on if the progressive version is actually smaller. The size checking for JPGs is quite rigorous to ensure that an empty file isn’t created, and that a smaller file IS created.
With PNGs & GIFs, they are optimized in-place, because the tools claim they will refuse to create a larger image (unless you force them to, which we don’t).
Thread Starter
jshare
(@jshare)
Just sent you some examples of gifs, before and after the negative reductions.
Hmm, on my dev site they don’t get any bigger, just show ‘No Savings’. Are these Media Library images, or were they in that other ‘images’ folder you mentioned?
Thread Starter
jshare
(@jshare)
They’re in the images folder under my site root, not the Media Library.
Ok, I think the reason for this is the ‘careful’ option, even though I can’t reproduce the results myself, here’s the description:
Write slightly larger GIFs that avoid bugs in some other GIF implementations. Some Java and Internet Explorer versions cannot display the correct, minimal GIFs that Gifsicle produces. Use the –careful option if you are having problems with a particular image.
I suspect that the glitch is for rather old versions of IE & Java, and I’m half tempted to get rid of it entirely.
I’d like you to try something if you don’t mind. Upload those ‘pre’ images to your Media Library, and confirm that you get the same (negative) results. Then download the ‘dev’ version where I’ve temporarily removed the –careful flag and upload them again to see if you still get a negative savings result.
Thread Starter
jshare
(@jshare)
The Media Library automatically generated multiple sizes of each ‘pre’ image and I can confirm the negative results for some of them, with the others were just ‘Reduced by 0.0%’.
But which dev version are your referring to? I’m already using 1.8.4.9 with the fix for Folders to Optimize.
Sorry, should have been more clear. I meant for you to grab a fresh copy from the dev link I posted previously. It will still say version 1.8.4.9, but it will call gifsicle without the –careful option now.
Thread Starter
jshare
(@jshare)
I grabbed the download again and put it on my server. I also restored the previous unoptimized versions of the images for a single directory and changed the settings so that would be the only Folder to Optimize. Next I Empty Table’d, ran ‘Import Images’ and then S & O under Optimize Everything Else.
1) Even though I only set up one folder to be optimized, Bulk Optimize also tried to optimize the active theme’s images, seems like a bug. Since those images had already been optimized, they all returned ‘No savings’.
2) For the single Folder to Optimize, the negative reductions appeared again for the exact same images and with identical percentages. There’s nothing in the debug log about the –careful option so next time I think you should update the version number somehow. Just makes tracking easier 🙂
1. the Scan & Optimize checks your theme images every time it runs against the information stored in the table. If you’ve emptied the table, it has no record of what has been done before.
2. To make sure you are indeed using the ‘un-careful’ version, you can check the file ewww-image-optimizer.php on line 1693 (or just search for careful), and verify that the line with –careful is commented out (has two slashes in front of it), and the line below it calls gifsicle without the –careful flag.
With the results that you found, it seems the –careful option is not the culprit, so something else strange is going on here. I’m at a bit of a loss to account for this, so I’ll have to stew on it a bit…
In the meantime, could you send me originals of a few other GIFs that were made larger?
Thread Starter
jshare
(@jshare)
Confirmed that I was using the ‘un-careful’ version.
Sent you more originals.
From my POV, this bug isn’t such a big deal. The big deal was not being able to optimize images outside of the active theme. That taken care of, I’m going to mark this resolved. But if you have something for me to test, I’m happy to help.
Thanks for a great plugin btw!
Aha, just discovered why I couldn’t replicate what you were seeing. I had my dev site in ‘cloud’ mode, so it was doing all optimizations via the cloud servers. The cloud servers NEVER send back a larger image…
I disabled cloud GIF processing, and now see exactly what you are seeing. I’ll do some digging and see about a fix. Yes, it’s minimal, but we shouldn’t EVER be generating a larger image. Thanks for all sample images, those will be most useful.
