[Feature request] Allow specifying a range for -zc.

[ace-dent]

Using optipng, I found that the different Deflate strategies of zlib work better with some images. Looking at libdeflate, the method changes with levels: Fastest -> Greedy -> Lazy -> Near_optimal see here.

I expected -o max would test --zc 1 to --zc 12, but I understand why this is not implemented; (1) extreme and niche, (2) complicates use with -Z.

Would it be possible to specify ranges for oxipng (e.g. --zc 1-12, or --zc 1,3,5-9), for the more efficient evaluation of these settings? i.e. avoids doing it via scripting outside the program. ... In the past, there was more flexibility in the low-level settings for zlib.

Historic edge case by @andrews05 here.

[andrews05]

Yeah, good question. See #463 where I removed this feature.
The additional savings found by iterating zlib compression levels were already minuscule but after switching to libdeflate they became far less still. Removing the feature was a big help for technical reasons but besides this there's a few reasons why I don't think we need to bring it back:

1. As you noted it is possible to script this outside the program.
2. If oxipng really wanted to squeeze every last possibly byte out of a png with no regard for time (which is not really the goal - it's perhaps more like libdeflate than zopfli 😄), this is perhaps the least effective/efficient addition that could be made - there are other things that could be done first. (If you're interested I could expand on this more, though it would involve some technical details about oxipng's internals)
3. Most importantly: Why would you not just use zopfli instead?

Btw, just out of interest, have you been testing oxipng for use with pngslim? I'd be curious to know how you've found it so far and whether it can wholly replace any of your other tools.

[ace-dent]

Thanks @andrews05. Makes sense - please Close.

...testing oxipng for use with pngslim...

Early days... I like to test for a few years between releases... 😅
In all seriousness, I really like the palette sorting and dirty alpha optimizations. Plan is to supplement other tools with these unique benefits.
I'm building up a little collection of images that benefit from oxipng, but not yet analysed the specific source of improvements.

[andrews05]

Cool, good to hear.

[ace-dent]

... there are other things that could be done first.

@andrews05 - I'd like to know your dream list of features!

I'm curious: when setting --zc, is that level used for the earlier optimization steps (palette / filter/ alpha, etc.) ?
Ideally I want to specify the compression method used to evaluate the transformation steps. e.g. filtering might be more or less optimal with a greedy or lazy approach, etc.

[andrews05]

So there's essentially 3 places where we compress the image data:

1. Reduction evaluations.
2. The Brute filter.
3. Filter evaluations (main compression trials).

The reduction evaluator currently runs with a fixed set of filters (None and Bigrams) and libdeflate compression at either level 7 or level 8, depending on the o level. A hypothetical brute mode would run using all selected filters at the selected compression level (or zopfli). Main compression trials would then be skipped as we would already have the final result (as happens at -o0 currently).

The Brute filter currently runs at libdeflate level 1 and compresses 4 lines at a time (the current line, plus 3 previous ones to provide context). A stronger version might, e.g., run at level 5 and compress 8 lines at a time.

Other areas where there's room for improvement, in order of highest benefit (assumed):

• Palette sorting algorithms, as you're well aware.
• Some minor reductions that aren't currently performed (Chooses 2-bit grayscale over 1-bit indexed #515).
• Genetic filtering algorithm?