Different PNG results under Windows / .net core and Mac, Linux, .net47

[jherby2k]

Description

I've noticed through some unit tests that I get a different PNG image when running my tests on Windows under .net core (2.1). Every other platform (OSX, Ubuntu, even .net framework on Windows) gets a different result. Both files are valid (decode back into the source bmp perfectly), they're just different. Maybe not a bug, but seems odd to me.

Steps to Reproduce

1. Convert my test bitmap (attached, with a .txt extension because GitHub doesn't like .bmp files) to PNG using something like this:

using (var image = Image.Load(inputStream))
image.SaveAsPng(pngStream, new PngEncoder { ColorType = PngColorType.Rgb });

2. Compare the resulting files. (Both results are attached)

System Configuration

• ImageSharp version: 1.0.0-beta0005
• Environment (Operating system, version and so on): Windows 10
• .NET Framework version: .net core 2.1, .net framework 4.7.2
  Original.bmp.txt
  
  

[dlemstra]

Did you attach the correct result files? Because ImageMagick thinks they are the same:

compare -metric rmse 45563771-5b96ba80-b81c-11e8-9946-c983bad52834.png 45563772-5b96ba80-b81c-11e8-80af-43989dae45a6.png null:
0 (0)

[jherby2k]

My binary editor disagrees, as does Windows Explorer (they're different sizes).

[JimBobSquarePants]

@dlemstra I had a look at the two output images and they're an exact match when you compare the pixels. If you compare the image bytes though they are vastly different.

@jherby2k The 18kb difference leads me to believe there must be something different in the underlying DeflateStream implementation as they are both using the same compression flag 0x9C. I'm fairly certain Corefx is currently using a managed implementation rather than the native implementation used on other platforms. Perhaps the interpretation of CompressionLevel.Optimal is somehow different?

I'm not concerned about this though unless you cannot decode the NET Core versions on other platforms. Would you be able to check this for me?

[jherby2k]

If anything I’d assume (different) native implementations would give different results, but in this case net472 on Windows gives the same result as netcoreapp2.1 on Linux. Windows netcoreapp2.1 is the only outlier. Both images seem perfectly valid on my Mac, so I don’t think this is a concern so much as an unexpected behavior.

[JimBobSquarePants]

If anything I’d assume (different) native implementations would give different results, but in this case net472 on Windows gives the same result as netcoreapp2.1 on Linux.

You've got me then, I don't know what the underlying behaviour is for NET Core on different platforms.

If it's not an issue to decode the images on different platforms then I'm happy to close this (though it might be an idea to create a test case for deflate stream to see if we need to raise an issue on CoreFX repo). Out of curiosity, which platform created the smaller file?

[jherby2k]

Aha, I have tracked down the history on this, just for posterity. CoreFX’s System.IO.Compression.DeflateStream got some performance love in this commit (vs the old netfx code). This change was Windows-specific. dotnet/corefx#5674 There is a rejected PR to add this optimization to Linux. The preference is to lean on the shared system implementation, and I would assume the same applies to OSX. dotnet/corefx#6876 So the Windows corefx version got a 20-30% speed bump but doesn’t quite compress this image as well as the system zlibs used elsewhere (which all seem to generate identical output).

[JimBobSquarePants]

@jherby2k Great find! That clears that up then. 👍