Repository navigation
Get "Invalid PNG data." exception during Identify phase of loading PNG image when image contains sBIT chunk #2018
Description
Activity
Unfortunately, I don't have permission to upload the image that is causing this problem.
You cannot attach the image here? Just drag and drop it in the text box should work.
It's not that I'm unable to attach the image -- it's a copyright image that I don't have permission to upload here.
It's not that I'm unable to attach the image -- it's a copyright image that I don't have permission to upload here.
Ok, I misunderstood that. Then we need to find another image with the same chunk for a unit test.
Thanks for opening a PR for this.
- linked a pull request that will close this issueFix issue in PNG identify method to skip "uninteresting" chunks, incl… #2019
on Feb 19, 2022 It looks like I'll need to figure out why the three resolution tests are failing.
Reacted by Brian PopowIt looks like there's some other reason my file isn't working right. Several of the test files also have sBIT chunks and they work fine. However, Windows and Chrome can both open my file just fine, and a file analyzer I used on it didn't find any problems, so I'll see if I can find an alternate solution.
It looks like there's some other reason my file isn't working right. Several of the test files also have sBIT chunks and they work fine. However, Windows and Chrome can both open my file just fine, and a file analyzer I used on it didn't find any problems, so I'll see if I can find an alternate solution.
Maybe it has todo with chunk ordering? It could be that a chunk is in an unexpected position of the stream.
I can't provide the actual image file, but below is the first 48 bytes of the file -- all that follows is a series of IDAT chunks and an IEND chunk. The identify method starts at byte 8, so it skips the magic. When it reads the IHDR chunk, the stream position is 33, which is the start of the sBIT chunk. However, when it's reading the sBIT chunk, the position should be 48, but it's 41, which is the start of the data for the chunk -- 08 08 08.
In the other files with sBIT chunks, it works correctly; e.g. the ratio-1x4.png file in the test images.
I'm going to continue investigating this to see if I can find a solution.
89 50 4E 47 0D 0A 1A 0A PNG Magic
00 00 00 0D 49 48 44 52 IHDR
00 00 01 AD 00 00 02 11
08 02 00 00 00 76 D4 75
F300 00 00 03 73 42 49 54 sBIT
08 08 08 DB E1 4F E0The PR should fix the problem at this time.
I have been unable to create a new file that exhibits this same issue. I opened the errant file in PS and blurred it so I could share it and replaced the chunks before the IDAT chunks with the data from above, and it loads just fine.
I've also been unable to reproduce the problem in a minimal application using the errant PNG. I still believe there's a bug somewhere in ImageSharp, but I can't pinpoint it. I'll try to find some time this week to trace through things a little more closely, but I'm going to have to set this aside for now.
You could try out what libpng and see what it reports. It comes with
pngtestutil which reports errors.This is the output from pngtest:
Testing libpng version 1.6.38.git with zlib version 1.2.11 libpng version 1.6.38.git Copyright (c) 2018-2020 Cosmin Truta Copyright (c) 1998-2002,2004,2006-2018 Glenn Randers-Pehrson Copyright (c) 1996-1997 Andreas Dilger Copyright (c) 1995-1996 Guy Eric Schalnat, Group 42, Inc. library (10638): libpng version 1.6.38.git pngtest (10638): libpng version 1.6.38.git Testing ../bad.png: Pass 0: rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw PASS (788 zero samples) libpng passes test Default limits: width_max = 1000000 height_max = 1000000 cache_max = 1000 malloc_max = 8000000And from pngcheck:
File: ../bad.png (158774 bytes) chunk IHDR at offset 0x0000c, length 13 429 x 529 image, 24-bit RGB, non-interlaced chunk sBIT at offset 0x00025, length 3 red = 8 = 0x08, green = 8 = 0x08, blue = 8 = 0x08 chunk IDAT at offset 0x00034, length 8192 zlib: deflated, 32K window, default compression chunk IDAT at offset 0x02040, length 8192 chunk IDAT at offset 0x0404c, length 8192 chunk IDAT at offset 0x06058, length 8192 chunk IDAT at offset 0x08064, length 8192 chunk IDAT at offset 0x0a070, length 8192 chunk IDAT at offset 0x0c07c, length 8192 chunk IDAT at offset 0x0e088, length 8192 chunk IDAT at offset 0x10094, length 8192 chunk IDAT at offset 0x120a0, length 8192 chunk IDAT at offset 0x140ac, length 8192 chunk IDAT at offset 0x160b8, length 8192 chunk IDAT at offset 0x180c4, length 8192 chunk IDAT at offset 0x1a0d0, length 8192 chunk IDAT at offset 0x1c0dc, length 8192 chunk IDAT at offset 0x1e0e8, length 8192 chunk IDAT at offset 0x200f4, length 8192 chunk IDAT at offset 0x22100, length 8192 chunk IDAT at offset 0x2410c, length 8192 chunk IDAT at offset 0x26118, length 2826 chunk IEND at offset 0x26c2e, length 0 No errors detected in ../bad.png (23 chunks, 76.7% compression).Ok, if libpng does not report errors, it really means there is an issue somewhere in ImageSharp. Its hard to tell without a test file.
I'm trying to see if I can get permission to share the image. However, as I stated above, I also haven't been able to demonstrate the error in a minimal test -- it's only occurring in my larger application, which I definitely can't share. When I get some time, I'll try to create a minimal app that triggers the bug.
Reacted by Brian Popow
Prerequisites
DEBUGandRELEASEmodeImageSharp version
v2.0.0
Other ImageSharp packages and versions
ImageSharp.Drawing v1.0.0beta14
Environment (Operating system, version and so on)
Windows 10, Rider
.NET Framework version
6.0.1
Description
When loading an image that contains an sBIT chunk, the Identify phase throws an exception stating that the data is invalid. The switch statement in the identify function (around line 250 of PngDecoderCore.cs) does not include the PngChunkType.SignificantBits as a case, nor does it have a default clause. Adding a default clause as follows fixes the issue:
default: this.SkipChunkDataAndCrc(chunk); break;I may try to submit a PR if I can figure out how to do so.
Unfortunately, I don't have permission to upload the image that is causing this problem.
Steps to Reproduce
Image.Load(stream) from a stream that has a PNG with a sBIT chunk.
Images
No response