-
-
Notifications
You must be signed in to change notification settings - Fork 343
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
Enhance ZnEasy getPng:
to handle some problematic PNGs
#12261
Comments
Thanks andrei. |
Nice error report (as usual ;-) Let's try hacking along your suggestion (that everything after IEND can be ignored, I did not read any specs). Change:
and
and then it works for me. It is not super clean as before self was returned in all cases, but #processNextChunk is internal, so we can get away with that I think. All 42 PNGReadWriterTest tests are green (not sure that means much, but still). What do you think ? |
For me that looks better than the current version. Not sure how other decoders handle this case but I imagine they ignore what comes after the end. Might also make sense to have a "strict" mode or a way to parse that fails with an error in this case. From what is mentioned in https://www.w3.org/TR/png If I look at the structure of the file, all looks ok, with But then we seem to get a lot of empty chunks for some reason. No idea if that has any meaning. Seems to happen for many PNGs on Twitter.
|
Unrelated, but for more testing of PNG parsing, trying the image at http://www.schaik.com/pngsuite/ might be interesting.
|
See https://github.com/DraagrenKirneh/PngSuiteExplorer we used to score 100% percent IIRC
|
In a recent Pharo, you can simply inspect the directory:
Those starting with an x are supposed to give an error. |
I finally did a PR: #13049 |
merged |
When using
ZnEasy class>>getPng:
for some PNGs there is an error. For example for the Pharo logo from Twitter (https://pbs.twimg.com/profile_images/541743734/icone-pharo-1.png):The underlying issue is that
PNGReadWriter
cannot parse the picture.We can also save the image to disk and attempt to parse it using
PNGReadWriter
to get the same error.Using
pngcheck
shows that there is someadditional data after IEND chunk
.In the PNG specs
The IEND chunk must appear LAST. It marks the end of the PNG datastream. The chunk's data field is empty
. However it seems that some PNGs can have data afterwards. Not 100% sure this is the case here, but seems to be. Would be more resilient ifPNGReadWriter
would have a mode to handle these cases.Tested in Pharo-11.0.0+build.418.sha.d5b3b17a7491bb98ea70539a9198163b938a7d0b (64 Bit)
The text was updated successfully, but these errors were encountered: