Image compresses better with libdeflate than zopfli

[Rainboom-Dash]

This may already be known, but it seems in some cases, libdeflate results in smaller file sizes than zopfli while taking much, much, much less time
When I look at the help, it says zopfli is slower and stronger compression... but in some cases that isn't even true and I really think it should say (not recommended) next to it? This is just strictly my opinion.. the reduction is usually very small if it doesn't happen to actually increase in file size!
I don't know how rare the instance of it losing to libdeflate is, but I've seen it happen multiple times

source and image https://derpibooru.org/images/3217601

I just think it should be warned more that it very well can increase the file size while taking much longer to compress but I just don't know how rare the instance is of this happening

I don't know, maybe if zopfli is used, it also tests libdeflate? I guess the question is, is it worth the time cost and how common is it that libdeflate is smaller.. or is zopfli more of an advanced usage anyway so that isn't necessary?
Here's another image, about 1% file size difference where libdeflate was smaller https://derpibooru.org/images/1079905

[ace-dent]

Thanks @Rainboom-Dash. Yes, it's possible (but uncommon) that less 'effort' in compression can yield a more optimal size. Since every compression engine (zlib, libdeflate, zopfli, etc.) may take a different approach, the only way to ensure you achieve the smallest file is to use brute force and exhaustively test every method. Oxipng takes a more sensible approach and tries to find a good solution in a reasonable amount of time.

With oxipng I always run 4 trials: with no reductions (-nx) libedeflate then zopfli; then with reductions libedeflate then zopfli.

... if zopfli is used, it also tests libdeflate ...
I'd suggest it should be left to the user to decide and run manually, but may be worth adding a comment to the Documentation...?

[TPS]

With oxipng I always run 4 trials: with no reductions (-nx) libedeflate then zopfli; then with reductions libedeflate then zopfli.

@shssoichiro @andrews05 @AlexTMjugador Shouldn't be possible to automate this process via 1 command-line? Maybe a new -o7?

... if zopfli is used, it also tests libdeflate ...
I'd suggest it should be left to the user to decide and run manually, but may be worth adding a comment to the Documentation...?

Great idea, @ace-dent. Whaddy'all think?

[andrews05]

As @ace-dent mentioned it is pretty rare for libdeflate to beat zopfli. On average, you should definitely be seeing smaller sizes with zopfli.
I don't personally use it as I don't see the value in it (or the general idea of smallest possible size with no regard for time), but I know many people like it and I wouldn't want to label it as "not recommended". The help does say "much slower", so it's really a "use at your own discretion" type of thing. We could perhaps note that it's not guaranteed to be better.

With regards to running both zopfli and libdeflate, I'd say this falls under the same category as running libdeflate at multiple different levels. See my answer in #545 as to why I don't think we need an option for that. There are other things that could be done to make oxipng more "brutish" though.

[Rainboom-Dash]

Yeah, I guess so
I really do think zopfli is pretty niche.. based on the file size reductions I'm seeing (if it does even happen to not increase the file size...), it's a little silly.... commonly 0.05 to 0.25% lower file size for 50x longer to complete
of course, in some cases it can be a percent or greater but it's... not common...
Definitely do not think it should be part of the optimization presets, too slow and the potential gains are too small

[Rainboom-Dash]

We could perhaps note that it's not guaranteed to be better.

Eh.. I'm starting to think maybe I'm taking things too seriously... like, it says higher optimization levels can yield lower file sizes but nothing about them potentially raising... yet, I got over 1% higher file size on an image with -o4 than with -o2 because it wanted sub which -o2 tests but not -o4
I think anything should be taken as "generally" if it says it can be smaller.. meaning it could also be bigger
So maybe just... leave it how it is? It is an advanced usage setting, after all.. and I need to stop reading everything so literally

[andrews05]

I think that's a good answer 🙂

As I alluded to earlier, it's also possible for libdeflate 11 (-o3) to be better than libdeflate 12 (-o4) simply because it's different, however rare it may be.

Feel free to close if you're satisfied that this is resolved.

[ace-dent]

I was going to suggest a tweak to Documentation. Happy to create a PR if desired?

[Rainboom-Dash]

As I alluded to earlier, it's also possible for libdeflate 11 (-o3) to be better than libdeflate 12 (-o4) simply because it's different, however rare it may be.

Yeah, I just got one like that... the source wasn't well compressed to begin with (even re-saving with paint.net resulted in a nice reduction)

--zc 1=18.25% decrease
--zc 2=24.14% decrease
--zc 3=23.97% decrease
--zc 4=23.85% decrease
--zc 5=25.29% decrease
--zc 6=24.24% decrease
--zc 7=25.02% decrease
--zc 8=32.02% decrease
--zc 9=32.74% decrease
--zc 10=25.93% decrease
--zc 11=27.92% decrease
--zc 12=34.84% decrease

[TPS]

@Rainboom-Dash Would you be willing to provide the original image these results are from?

[Rainboom-Dash]

Sure! https://www.deviantart.com/shootingstarsentry/art/Nightverse-Greeta-994587848

[Rainboom-Dash]

I should note that with simplistic images created from vector art (like this), generally optipng wins by a tiny amount over -o6 oxipng from what I've seen and I wonder if the --zc 10 and beyond don't handle them well.. but I didn't test all the --zc levels with others where optipng won...

Although, I have tested --zc 11 and --zc 12 on others where optipng beat oxipng and usually there isn't much difference between those levels, no more than a percent or two, a lot of times less, so this is still an interesting case since it beat it by almost 7%

[TPS]

If you're on Windows, a run through FileOptimizer would be instructive. Also, max-compression lossless conversion to WebP &/or JxL would potentially give a great comparison.

[TPS]

I should note that with simplistic images created from vector art (like this)

I just realized, if there's an original source conversion to SVG/SVGz, that would be the best possible version to use online (& potentially for size comparison), & there're multiple dimensions of filesize optimizations for those.

[Rainboom-Dash]

If you're on Windows, a run through FileOptimizer would be instructive. Also, max-compression lossless conversion to WebP &/or JxL would potentially give a great comparison.

lol, 1.7MB to 550KB (optipng/oxipng -o6) versus WebP level 6 compression
JXL level 7 (so not even the max level 9) is 475KB :)

[Rainboom-Dash]

oh crap, the WebP was lossless but the JXL was accidentally set to lossy

Apologies, JXL was 520KB lossless

[Rainboom-Dash]

whelp, I think IrfanView may have taken the alpha layer out... despite saving as 32-bit... so not lossless :(

Shouldn't have assumed it was preserving that...

But the alpha layer shouldn't take that much data anyway... so still safe to say, MASSIVE file size decrease over PNG

I just saved with paint.net, it did save the alpha layer and it's not even a kb difference in file size

[TPS]

whelp, I think IrfanView may have taken the alpha layer out... despite saving as 32-bit... so not lossless :(

The way to do these conversions best is to use cwebp & cjxl to prevent that.

[Rainboom-Dash]

This one has svg available and I exported to 3952x3541 and I got similar results to the other image https://derpibooru.org/images/3229907
--zc 12 is better than --zc 9 but --zc 11 is significantly worse than --zc 9

I tried a more complex image but still a vector https://derpibooru.org/images/3222687 and not surprisingly, --zc 10 is quite a bit better than --zc 9

So yeah... it's the simplicity and the way the lines are that causes this...

Also, -o3 is worse on the more complex vector than -o2... seems it wanted sub... I really feel like sub should be added to -o3 but... eh... I've seen this happen multiple times
It's about 2% higher file size with -o3 than -o2

[TPS]

@Rainboom-Dash I think you misunderstood me? The SVG(z) itself, when properly optimized, is likely the best-filesize lossless representation, especially @ larger dimensions.

[Rainboom-Dash]

Ah, right Yes, of course SVG>WebM/JXL>PNG aaaand, I ment WebP... also, note to self: do not reply to email (or at least, remove the other junk)

…

On Wed, Nov 15, 2023, 7:43 PM TPS ***@***.***> wrote: @Rainboom-Dash <https://github.com/Rainboom-Dash> I think you misunderstood me? The SVG(z) *itself*, when properly optimized, is likely the best-filesize lossless representation, especially @ larger dimensions. — Reply to this email directly, view it on GitHub <#568 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJCTFTNDCNDHUI4IAOSV4FTYEVVSXAVCNFSM6AAAAAA6BTDTA2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJTGYYTSMJRG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>