Hi @dustdfg
See #640 where --zi was added. The reason for the restriction is that the API currently uses a U8 and raising it would be a breaking change, so it's been deferred until the next major release (no timeline for that yet though).
If you want to change it yourself, take a look at the diff in the above PR. You'll need to change one reference of "255" to something higher, and also change all references of NonZeroU8 to NonZeroU64`.

Thanks. It worked. I've run it with parameter 10240 just for fun and saved 2 bytes in comparison to already optimized image with 255 🤣 🤣 🤣 But it worked!

Out of curiosity, how much time did it take to run 10240 iterations with respect to "just" 255? 😂

Out of curiosity, how much time did it take to run 10240 iterations with respect to "just" 255? 😂

& on what spec'ed image (dimensions & color depth, mostly)?

It was a Godot icon previously optimized by setting --zi 255 to 3683 bytes. When I ran --zi 10240 it gave me 2 bytes difference. It took more than compiling Godot for this one image. When I ran --zi 255 for all png files in Godot it also took more than compiling Godot. I can say that running --zi 10240 was at least 34 times slower than running --zi 255 for all Godot icons

I've also ran it on another icon (also from godot):

It also previously was optimized with --zi 255. And running it with --zi 102400 (102400 it is not a mistake there are two zeroes in the end!) it didn't have any effect but took 6-9 hours

But I have a low-end device so it is not that bad result. And I've also ran it without --fast

Is there an iteration counter displayed saying which round produced the savings?

If not, could there be, for this & the eventual --zi brute option?

Try RUST_LOG=debug oxipng …

RUST_LOG=debug

It is actually not what user expects:

Iteration 9: 6354 bit
Iteration 253: 6352 bit
Iteration 0: 1303 bit
Iteration 22: 1270 bit
Iteration 0: 6570 bit
Iteration 1: 6553 bit
Iteration 2: 6514 bit
Iteration 3: 6488 bit
Iteration 4: 6407 bit
Iteration 5: 6377 bit
Iteration 6: 6347 bit
Iteration 7: 6334 bit
Iteration 8: 6265 bit
Iteration 9: 6235 bit
Iteration 10: 6228 bit
Iteration 11: 6212 bit
Iteration 12: 6201 bit
Iteration 41: 6197 bit
Iteration 0: 8523 bit
Iteration 1: 8374 bit
Iteration 2: 8248 bit
Iteration 3: 8225 bit
Iteration 4: 8220 bit
Iteration 5: 8219 bit
Iteration 16: 8212 bit
Iteration 17: 8197 bit
Iteration 18: 8180 bit
Iteration 19: 8167 bit
Iteration 21: 8165 bit
Iteration 32: 8163 bit
Iteration 33: 8160 bit
Iteration 129: 8155 bit
Iteration 150: 8154 bit

RUST_LOG=debug

It is actually not what user expects:

…

Iteration 150: 8154 bit

I was thinking, when displaying the final summary, just this last info nicely presented.

For (very) small images, I have used a Zopfli compressor with 512 iterations. It's not something I've extensively tested...

@TPS - +1 Yes! In the most verbose mode, it'd be great to have the final number of Zopfli iterations output (just like we reveal the winning Palette structure). Ideally this would be formatted to allow scripts to extract the text and number easily 🙏

If it's not what the user expects I'm afraid that probably means the user doesn't understand how zopfli works 😂

The data is first split into some number of "blocks" and each block is then compressed by iterating the specified number of times. The printout that you see with RUST_LOG=debug shows every iteration of every block that found some improvement. (If you do RUST_LOG=trace it will print all iterations, including ones that did not find improvement).

In the above output, the last line Iteration 150: 8154 bit means the 151st iteration (it counts from 0) was the best for the last block. But we can also see one of the previous blocks found improvement on the 254th iteration.

Note though that the output here is all part of the zopfli library - oxipng neither controls it nor knows anything about it.

@andrews05 So, the debug info or Zopfli library could potentially be parsed or queried to provide the info as requested, i.e., the last iteration to show any improvement?