-
Notifications
You must be signed in to change notification settings - Fork 125
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Probably regression in v9.0.0 compared to v8.0.0, compression became worse #579
Comments
Hi @aleksusklim This seems quite strange, I ran that same command on oxipng 9 on aarch64-apple-darwin and it came to 6468192, the same as you showed for v8. [edit] Scratch that, I downloaded the v9 binary from releases (instead of building myself) and got the larger 6534517 result. Something strange may be happening in the build workflow? Seems to be specific to zopfli - using libdeflate I get the same result from both my own build and the release binary. |
I can reproduce the issue when generating and running the v9 binary on Linux with The latest Zopfli update has been careful to not change how the same input with the same configuration parameters is compressed. Given that there were no other relevant changes since |
Weird, I just ran that exact command (now on x86_64-apple-darwin, 1.66.0-nightly) and got the smaller 6468192 result. [edit] Aha! Upgrading to latest rust now gives me the larger result. pngcheck shows the filters are identical, so it seems the toolchain is somehow affecting Zopfli's behaviour. |
Wow, I really hope Zopfli is not relying on some sort of undefined behavior then... 😅 Do you remember what Rust version did not exhibit this problem? Both me and CI used nightly Rust to compile binaries, so that may explain why I was not able to reproduce it. |
Unrelated to the buffer changes by @Pr0methean ...? |
I was on 1.66 nightly before I upgraded. (I think my arm machine was slightly newer, but can’t check right now) [edit] The change appears to be in 1.74 which gives the larger result, vs 1.72 which gives the smaller. |
@AlexTMjugador Any ideas on how we can track down the cause of this? I found a smaller (faster) test case: issue-29.png also shows a small increase between 1.72 and 1.74. |
We could locally patch the dependency on Zopfli to use a local checkout of its source code, and then |
@AlexTMjugador Narrowed it down to this commit: zopfli-rs/zopfli@90cfdd4 |
Thanks for bisecting @andrews05! I hope I'm able to take a more in-depth look at what's going on with that commit later this week. I totally did not expect safe code for this straightforward change to cause this regression 😂 |
Have anybody found a culprit code so far? |
Not yet as far as I know, @aleksusklim - I've clearly been pretty busy lately 😅 |
@aleksusklim Does https://github.com/shssoichiro/oxipng/releases/tag/v9.1.0 do anything to resolve this for your test cases? There is a lot contained therein, though I'm not sure I saw anything specific to this issue specifically. |
Version 9.1.0 still isn't released on crates.io, so anyone wanting to test it would currently have to use this ugly workaround:
|
Nothing has changed in v9.1.x to address this, sorry. |
This is the command that was used to convert an album of anime screenshots:
oxipng.exe --verbose --threads 8 --alpha --force --interlace 1 -f 0-9 --zopfli --strip safe --preserve *.png
Here is the output from new
oxipng-9.0.0-x86_64-pc-windows-msvc.zip
:And here is the output from old
oxipng-8.0.0-x86_64-pc-windows-msvc.zip
I am attaching this image along with its compressed versions in zip here:
HenSuki.zip
This problem is happening with other similar images too, which were not specifically crafted to trick oxipng. Actually, the new version was checked against images that were already compressed by the old version to see if it would improve the compression ratio, but instead of
0 bytes decrease
/0.00% decrease
it showedlarger
/increase
.You can find the full album compressed with the old version here:
https://telegra.ph/HenSuki-03-08
The problem happens on all images except for one (that depicts a letter and has large similarly-colored areas).
The text was updated successfully, but these errors were encountered: