Repository navigation
Image.Load() throws InvalidImageContentException: CRC Error. PNG IDAT chunk is corrupt! #2570
Description
Activity
The IDAT is indeed corrupt.
We'll need to have a look at libpng to see if they have some special handling of this.
Reacted by NayukiLibpng also "throws an exceptions":
C:\Users\Dirk\Desktop>magick 277674454-e24cc769-3dbd-420b-977f-7f7b6dbec05c.png info: magick: Expected 4 bytes; found 0 bytes `277674454-e24cc769-3dbd-420b-977f-7f7b6dbec05c.png' @ warning/png.c/MagickPNGWarningHandler/1526. magick: Read Exception `277674454-e24cc769-3dbd-420b-977f-7f7b6dbec05c.png' @ error/png.c/MagickPNGErrorHandler/1492.
This file, and the two above can be partially displayed by chrome, that uses libpngCan they be opened by other imaging libraries? Chrome looks to have turned of the safety checks. (There’s a compiler option in libpng)
MagicScalar uses libpng and can handle the last image that i posted
MagicScalar uses vcpkg precompiled version of libpng. What is the compiler option called can't seam to find it here?
Ah not a compiler option it seems. Look for
png_set_crc_actionSo this explains why it works in MagicScalar then.
Would it be possible to consider this for ImageSharp?
After further investigation into MagicScaler, it turns out that using default settings on windows will result in native WIC codecs being used. This png codec is forgiving.
Instead when libpng is used with "codecs.UseLibpng()" no CRC error is thrown but the resulting image is all black.
nevermind. this works as expected.Any input?
This is precisely the kind of thing I designed ISpecializedDecoderOptions for. There's no reason we cannot define rules for handling Crc and Adler validation on decode.
Would you be interested in creating a PR?
Tried it a bit but got stuck by the fact that IDAT and IEND is considered critical chunks and found no way of ignoring that fact if the file is truncated, IDAT is cut off and IEND is missing.
Maybe you have some pointers for me here
PR not yet posted to here because it is work in progress still.Reacted by James Jackson-SouthSorry for the slow reply @svenclaesson I've been off the boil for the last few weeks with sickness.
If you actually open a PR I can commit directly to your fork to help finish it off.
Reacted by Sven Claesson- linked a pull request that will close this issueRelaxed handle of corrupt png files #2589
on Nov 29, 2023 3 remaining items
@JimBobSquarePants What is the easiest way to make use of the new options? Ideally I would like to be able to pass something through via
Image.IdentifyorImage.Load, but they only take a basicDecoderOptions.Would it be reasonable to add overloads that take
ISpecializedDecoderOptionssince that already contains aDecoderOptionsproperty? Or maybe some other concept of aggregated specialized decoder options?@JimBobSquarePants What is the easiest way to make use of the new options? Ideally I would like to be able to pass something through via
Image.IdentifyorImage.Load, but they only take a basicDecoderOptions.Would it be reasonable to add overloads that take
ISpecializedDecoderOptionssince that already contains aDecoderOptionsproperty? Or maybe some other concept of aggregated specialized decoder options?Ideally, we'd add a general equivalent to
DecoderOptionsbut we're stuck with the problem of what to choose... The specialized, or general version of the enum. Implementing it would require a breaking change to either remove or make nullable the specialized enum.Just so I understand, you would like to add a new property to
DecoderOptions, a new enum e.g.CrcChunkHandling.
This could then be used in place ofPngCrcChunkHandling, and maybe also in other decoders?Maybe the new one could be added and mapped to the specialized enum to save a breaking change? If I get time I could make an attempt at that.
So this issue is still pending, right? And no workaround in sight?
Possibly its not, there is a PR merged for it as I see now.
I do get the same exception on.Identify()not on.Load(), guess its fixed on one path only.Feel free to PR a fix for
IdentifyReacted by Hefaistos68bOuch, I am working full time employed plus on 3 Github projects on my "spare" time already. Hard to find time for another one.
Then you wait and hope for the best
Possibly its not, there is a PR merged for it as I see now. I do get the same exception on
.Identify()not on.Load(), guess its fixed on one path only.Done some more investigation here and it seems to be an deeper issue.
The images where we can see the issue are actually saved with ImageSharp as PNG.
We do receive the image, usingvar loaded = Image.Load(imageStream).Clone(i => i.AutoOrient());
Then we determine the format fromvar format = loaded.MetaData.DecodedImageFormat, if it is an acceptable format we then store it into a memory stream from where we save it to cloud storageloaded.Save(targetStream, format);So the issue happens somewhere between those lines. Will have to try and run an
.Identify()after each step to get to the bottom of it.As far as I can see, this is fixed. However it does require passing
SegmentIntegrityHandling.IgnoreImageDataThe default options throws InvalidImageContentException("CRC Error. PNG IDAT chunk is corrupt!"):
using var image = Image.Load("Issue_2589.png"); ImageInfo info = Image.Identify("Issue_2589.png");Passing decoder options avoids the throw:
DecoderOptions options = new() { SegmentIntegrityHandling = SegmentIntegrityHandling.IgnoreImageData }; using var image = Image.Load(options, "Issue_2589.png"); ImageInfo info = Image.Identify(options, "Issue_2589.png");Output:
I will try that out, but it does not explain how come that the image gets saved by ImageSharp with a corrupt IDAT block. As mentioned ->
Load()->Clone(AutoOrient())->Saveand the incoming image has no defects.Ok, it wasn't clear to me that you were starting with a good image that was maybe getting a corrupt IDAT during the ImageSharp processing.
When exactly do you get the exceptions? Do you do an
Identify()afterloaded.Save(targetStream, format);? Is the input image definitely well formed?Yes, input images are definitely good. Created a console app to read a bunch of the ones that are saved with IDAT errors, all fine.
The Identify() is separate from the load/clone/save cycle, different modules even, same ImageSharp library ( we are still on the latest 3.x version though)
we are still on the latest 3.x version though
Stop wasting everyone’s time then
Stop wasting everyone’s time then
So its already fixed in the 4.x version? Great. Then its just a license question.
Prerequisites
DEBUGandRELEASEmodeImageSharp version
3.0.2
Other ImageSharp packages and versions
None
Environment (Operating system, version and so on)
Windows 11 Version 22H2
.NET Framework version
.net 7
Description
I have two png images that opens fine with System.Drawing.Common, but that fails to open with ImageSharp, and instead throw an InvalidImageContentException: CRC Error. PNG IDAT chunk is corrupt! Both files can be viewed in windows.
Steps to Reproduce
Just point to the filePath with Image.Open(filePath) and it should throw the exception when running the code.
Images