`-o max` is worse than `-o 2` in some cases

[zzyyyl]

version v9.1.2

Test image 1 (1030 Bytes):

> oxipng -o max -s -Z test.png
test.png: Could not optimize further, no change written

> oxipng -o max -s test.png
test.png: Could not optimize further, no change written

> oxipng -o 2 -s test.png
1028 bytes (0.19% smaller): test.png

Test image 2 (147 Bytes):

> oxipng -o max -s -Z test.png
test.png: Could not optimize further, no change written

> oxipng -o max -s test.png
test.png: Could not optimize further, no change written

> oxipng -o 2 -s test.png
140 bytes (4.76% smaller): test.png

[ace-dent]

Further reading: https://github.com/ebiggers/libdeflate/issues/241#issue-1420436397 https://github.com/shssoichiro/oxipng/issues/545 https://github.com/shssoichiro/oxipng/issues/568#issuecomment-1764127487

[andrews05]

Hi @zzyyyl As noted in the references above, this is indeed possible on occasion and is actually pretty normal behaviour in the world of lossless data compression. The differences here are a matter of bytes and shouldn't be anything to be concerned about.

As this has come up a couple of times, I'll make a PR to note this in the read me...

[AlexTMjugador]

As noted in the references above, this is indeed possible on occasion and is actually pretty normal behaviour in the world of lossless data compression. The differences here are a matter of bytes and shouldn't be anything to be concerned about.

While I agree that this is a very reasonable expectation to have in general, I'm curious about whether these images have some technical property whose analysis could result in improvements to optimization heuristics. Did you suspect or find out anything of that sort, @andrews05?

[andrews05]

I didn't look at the first image but in the second one it selected 1-bit at -o2 and 8-bit at -o6. This can happen because the evaluation compression level changes from 7 to 8, which gives a more accurate selection most of the time but still isn't perfect of course.