Imagesharp: Decoding malformed iPhone generated PNG throws 'Bad compression method for ZLIB header: cmf=237'

Created on 22 Dec 2017  路  8Comments  路  Source: SixLabors/ImageSharp

Prerequisites

  • [X] I have written a descriptive issue title
  • [X] I have verified that I am running the latest version of ImageSharp
  • [ ] I have verified if the problem exist in both DEBUG and RELEASE mode
  • [X] I have searched open and closed issues to ensure it has not already been reported

Description

Try loading the attached image and see that it generates a 'Bad compression method for ZLIB header: cmf=237' error. System.Drawing can open this image.

Steps to Reproduce

Image.Load(File.OpenRead("1.png"))

System Configuration

.NET Standard 2.0 Dll hosted in a .NET Framework 4.6.1 windows service

  • ImageSharp version: 1.0.0-beta0002
  • Other ImageSharp packages and versions: Sizlabors.Core 1.0.0-beta0004
  • Environment (Operating system, version and so on): Windows 10
  • .NET Framework version: 4.6.1
  • Additional information:

1

png

Most helpful comment

These files have been processed with an Apple-variation of pngcrush.

You can use PNGDecrush (source) to decrush the image, which can then be fed to other image libraries.

E.g.:

using (Stream input = File.OpenRead("34303888-73d65ca6-e705-11e7-88cf-6c16ad871172.png"))
using (MemoryStream decrushed = new MemoryStream())
{
    PNGDecrusher.Decrush(input, decrushed);
    decrushed.Position = 0;

    var image = Image.Load(decrushed);
}

All 8 comments

Hi @zeus82

Thanks for the detail and the input image. It turns out that image is not a valid png.

cgbi

http://iphonedevwiki.net/index.php/CgBI_file_format

There's quite a few differences between the format

  • extra critical chunk (CgBI)
  • byteswapped (RGBA -> BGRA) pixel data, presumably for high-speed direct blitting to the framebuffer
  • zlib header, footer, and CRC removed from the IDAT chunk
  • premultiplied alpha (color' = color * alpha / 255)

@antonfirsov @tocsoft @dlemstra

Theoretically it looks like we could potentially handle these changes with some updates to our decoder based on the following, it looks like a lot of work though for all our different color types:

http://www.axelbrz.com.ar/?mod=iphone-png-images-normalizer

I don't know if we should attempt this for V1 though. What do you think?

seeing as chrome doesn't seem to even seem to render it then i'm inclined to think we should defiantly push it past v1 and even then see how much of an issue its causing in the future and make a another call then.

Ha! Doesn't it! I only have Edge installed at the mo cos I had to get my laptop replaced. That renders something but it ain't pretty. Yeah let's leave it for now then.

Only Windows + GDI based decoders seem do decode it properly. I consider this issue as low-priority one, definitely not a show-stopper for V 1.0.

Ok, have moved it to futures. Gonna do a little cleanup in the png decoder around the zlib headers to remove an allocation I saw that we don't need anyway.

I would detect this specific format, but just to throw a more specific exception, like "malformed iPhone PNG detected", I think it's Apple's responsability to write proper PNGs, not the responsability of others to read their malformed files.

These files have been processed with an Apple-variation of pngcrush.

You can use PNGDecrush (source) to decrush the image, which can then be fed to other image libraries.

E.g.:

using (Stream input = File.OpenRead("34303888-73d65ca6-e705-11e7-88cf-6c16ad871172.png"))
using (MemoryStream decrushed = new MemoryStream())
{
    PNGDecrusher.Decrush(input, decrushed);
    decrushed.Position = 0;

    var image = Image.Load(decrushed);
}

@qmfrederik Thanks for the input; that a really useful tool! 馃憤

I'm going to get around to natively handling this one day, need to do some cleanup of the decoder first though.

Was this page helpful?
0 / 5 - 0 ratings