image/png: Decode failing on bitmap

[vron]

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

go version go1.8.3 windows/amd64

What operating system and processor architecture are you using (go env)?

set GOARCH=amd64
set GOOS=windows

What did you do?

See https://play.golang.org/p/-1XYQAzugF

Trying to decode a bitmap png file which both chrome and photoshop can open without errors.

What did you expect to see?

A decoded png image, since no bitmap format is defined mapped to a 8-bit file?

What did you see instead?

png: invalid format: too much pixel data

To my understanding this is a valid png file and according to the spec a decoder should be able to read all valid png files though it may not be able to encode them.

[dsnet]

\cc @nigeltao

[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.

[vron]

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 :-)

[vron]

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

[bradfitz]

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.

[creichlin]

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.