Unfortunately this is similarly deferred until the next major release as it would also be a breaking change to the API. I'm tempted to start a v10 branch though so you can at least play around with some builds...

Yes, I think this and #658 should be implemented for the next major release, which I don't know when will it be.

I didn't try it on different images. Maybe it will work well on photos but on a "cartoon" like images which consist primarily from solid areas 255 is enough

@andrews05 - neat; just wanted to keep it on the road map.
BTW, why would it be API breaking? I presumed a new parameter would be added, (e.g. --zz) that would override --zi. Or is you plan to overload the existing iterations function, where --zi 0 forces it to brute force? Cheers :-)

@ace-dent It is talked here about allowing user to set values great than 255 up to 2^64. Currently parameter is u8 so it is bound to 255 if it is changed to u64, it brakes API/ABI. I am sure that you doesn't really need something bigger than 2^24. Brute force would mean all possible paths...

If you need good compression just use webp which is widely supported and if to believe to internet is faster. After using 255 you won't squeeze much (I guess so). Or use JPEG XL which compresses even better than webp but is almost unsupported by software and is slower...

@ace-dent The issue is that the zopfli API option iterations_without_improvement is not currently exposed in the oxipng API.
When using the oxipng API you may do something like this:

    opts.deflate = Deflaters::Zopfli {
        iterations: NonZeroU8::new(15).unwrap(),
    };

But if we add iterations_without_improvement into the API, the above code will suddenly become invalid because it is incomplete.
So while adding new command line switches is not a breaking change, adding new options to the internal API is. The --zi switch was an easy add because the iterations option already existed in oxipng's API.