Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

image/png: Decode failing on bitmap #20899

Open
vron opened this issue Jul 4, 2017 · 6 comments
Open

image/png: Decode failing on bitmap #20899

vron opened this issue Jul 4, 2017 · 6 comments

Comments

@vron
Copy link

@vron vron commented Jul 4, 2017

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
Copy link
Member

@dsnet dsnet commented Jul 4, 2017

\cc @nigeltao

@nigeltao
Copy link
Contributor

@nigeltao nigeltao commented Jul 6, 2017

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
Copy link
Author

@vron vron commented Jul 7, 2017

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 vron closed this Jul 7, 2017
@vron vron reopened this Jul 7, 2017
@vron
Copy link
Author

@vron vron commented Jul 7, 2017

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

@bradfitz bradfitz added this to the Go1.10 milestone Jul 7, 2017
@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Nov 15, 2017

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.

@bradfitz bradfitz modified the milestones: Go1.10, Unplanned Nov 15, 2017
@creichlin
Copy link

@creichlin creichlin commented Dec 8, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants