Image shouldn't reduce to palette if the palette header would increase total size

[bvinc]

You may feel differently, and that's fine. But personally I was shocked to find out that after executing oxipng -i 0 -o 6 -Z --strip all *.png, some of my png files were bigger than they were before! I knew I hadn't specified --force. I had to dig into the specific png files and dig into the source code to figure out it was the -i 0 option that was causing it. I just specified -i 0 in case any of the png files were interlaced and removing it made them smaller.

I'm advocating that a larger png file should never be written unless --force is used.

The only reason I can guess for the current behavior is that it covers the case of someone wanting to use oxipng as an interlace-changing tool. If someone wants this, I think they simply need to use -i 1 --force. Since this is primarily a png optimizing tool, this makes sense to me.

[shssoichiro]

Interlacing does generally add to the filesize, and this is noted in the readme (and this is also how optipng functions), although I am surprised that there are cases where removing interlacing increases the filesize. Could you post an interlaced image where removing the interlacing increases the filesize? I'd be curious to see what might be causing this.

[bvinc]

Sorry I wasn't clear about the reason that the png files were getting bigger. It had nothing to do with interlacing. In fact, most of the png files I was using it on didn't use interlacing. I wanted to keep this issue focused on the problem of rewriting the file even when oxipng comes up with something bigger and --force isn't used.

The reason they were getting bigger could be considered a different issue altogether. The reason was that it was making very small images use palettes, which used more space even though the IDAT decreased in size.

$ wget -qO next_16x16.png https://image.ibb.co/m5N6MF/next_16x16.png
brain@brain-zbook:~/zk-web-images/oxi$ ls -l next_16x16.png 
-rw-r--r-- 1 brain brain 517 Mar  5 20:50 next_16x16.png

$ oxipng -i 0 -o 6 next_16x16.png 
Processing: next_16x16.png
    16x16 pixels, PNG format
    4x8 bits/pixel, RGBA
    IDAT size = 460 bytes
    File size = 517 bytes
Reducing image to 8 bits/pixel, 121 colors in palette
Trying: 648 combinations
Found better combination:
    zc = 1  zm = 8  zs = 1  f = 5        133 bytes
    IDAT size = 133 bytes (327 bytes decrease)
    file size = 698 bytes (181 bytes = 35.01% increase)
Output: next_16x16.png

$ ls -l next_16x16.png 
-rw-r--r-- 1 brain brain 698 Mar  5 20:50 next_16x16.png

Does this deserve a different issue?

[shssoichiro]

Thanks, that makes more sense. I think this can be kept as the same issue, I'll just rename it to show the root cause.

[bvinc]

Hmm.. I still think my original issue description deserves consideration. You can't always guarantee that oxipng will always produce a png file of equal or lesser size, right? If you can't guarantee that, then there's still a possibility that running oxipng -i 0 -o 6 *.png might leave you with some png files becoming larger, which would be extremely surprising and frustrating for someone attempting to optimize png files, especially when they read the help and see that a --force option exists that they aren't using.

It almost makes it oxipng unusable for a large collection of png files of different interlace settings. If I want to try optimizing them all with -i 0 and some small amount of them get bigger, what recourse is there? There is no --dont-replace-with-bigger option. You have to manually go through the png files one at a time, or write a size-comparing script, or more realistically, find another png optimizer that knows to never overwrite files with bigger ones.

[shssoichiro]

Yes, that's reasonable. I think going from 0 to 1 should allow a size increase, but going from 1 to 0 should forbid it without --force. That's probably not what anyone would want. I'll create a separate issue for that change.