Thumb properties stripped even without stripping enabled

[chrysn]

When oxipng is let lose on a file that contains Thumb::* metadata, things get lost (the example is utilizing that imagemagick's converter is producing Thumb::URI, Thumb::MTime and others automatically according to the thumbnail specification):

$ convert -thumbnail 128x128 rose: out.png
$ exiftool out.png |grep Thumb
Thumb Document Pages            : 1
Thumb Image Height              : 46
Thumb Image Width               : 70
Thumb Mimetype                  : image/pnm
Thumb Size                      : 9673BB
Thumb URI                       : file://rose:
$ oxipng out.png
Processing: out.png
    128x84 pixels, PNG format
    4x8 bits/pixel, RGBA
    IDAT size = 19588 bytes
    File size = 20091 bytes
Reducing image to 3x8 bits/pixel, RGB
Trying: 8 combinations
Found better combination:
    zc = 9  zs = 3  f = 5        16773 bytes
    IDAT size = 16773 bytes (2815 bytes decrease)
    file size = 16962 bytes (3129 bytes = 15.57% decrease)
Output: out.png
$ exiftool out.png |grep Thumb
Thumb URI                       : file://rose: 
$

Setting --strip=none or similar doesn't change anything here.

What's curious is that I find no mention of these particular names (or really anything "thumb" related) in oxipng, but still, that's what I get.

(Use case for reference: I've tried to use https://github.com/jesjimher/genthumbs/ with oxipng instead of optipng, and it took me quite some while to find why the newly generated thumbs weren't taken any more).

[edit: Note about file://rose: not being really correct removed, it just distracted from the difference]

[andrews05]

The issue here is that the thumb properties are all stored in separate tEXt chunks but oxipng currently only supports one chunk of each type. Some refactoring will be required to resolve this...

[TPS]

Some refactoring will be required to resolve this...

@andrews05 I think the same work would benefit #79?