\cc @nigeltao

After saving your "idat" bytes via ioutil.WriteFile, I see that ImageMagick (which uses libpng) does print some warnings:

$ convert x.png y.jpeg
convert.im6: Extra compressed data. `x.png' @ warning/png.c/MagickPNGWarningHandler/1752.
convert.im6: Extra compression data. `x.png' @ warning/png.c/MagickPNGWarningHandler/1752.

I'm not sure if the spec explicitly disallows extra data, but that particular image is at least skirting the boundary of validity.

Noted,

I just noticed that all the other imaging software I use handled it. No problem for me if you decide not to support it, just thought I ought to report it :-)

Closed by mistake. Will let you decide what to do with it

I seem to recall some similar bugs that were arguing for a new png.Decoder type where we could add some fields. One such field could be Tolerant bool to accept things we'd normally reject.

Maybe somebody could find those bugs.

I'm kicking this to Unplanned since there's been no activity here. If somebody wants to prepare a CL we can evaluate how invasive it'd be.

I took a closer look at the image and it seems that there is pixel data for 418 rows but the header says it's 417 rows. I assume that this is a bug of the tool used to create the image. When I search google for "invalid format: too much pixel data" i find only this issue, so this specific case doesn't seem to be a common issue.