Weird PNG resaving issue, broken image?

[KLuuKer]

Prerequisites

• I have written a descriptive issue title
• 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
• I have searched open and closed issues to ensure it has not already been reported

ImageSharp version

3.0.1 \ 3.0.2-alpha.0.27

Other ImageSharp packages and versions

Drawing 1.0.0-beta15.1 \ 15.14 Fonts 1.0.0-beta18 \ 19.19

Environment (Operating system, version and so on)

Windows 11 x64 AMD Ryzen

.NET Framework version

.net core 7.0.9

Description

input png gets turned into a purple mess
probably a broken file

looking at the original trough multiple image viewers works fine

• windows explorer preview
• irfanview 64 bit 4.54
• irfanview 32 bit 4.62 (windows store app version)

p.s. hi i'm back with another random weird issue 😄 still love you guys and imagesharp
i already have the new feedz to test the latest builds if available

Steps to Reproduce

doesn't matter if converting 1 or multiple images at the same time

using var img = await Image.LoadAsync("original.png");

// this broken
await img.SaveAsPngAsync("output.png", new PngEncoder() { CompressionLevel = PngCompressionLevel.BestCompression });

// work around (i don't want to do this because i might end up using a higher amount of bits)
await img.SaveAsPngAsync("workaround.png", new PngEncoder() { CompressionLevel = PngCompressionLevel.BestCompression, ColorType = PngColorType.RgbWithAlpha });

// jpg is fine
await img.SaveAsJpegAsync("works.jpg", new JpegEncoder { SkipMetadata = false, Quality = 100 });

// webp also works
await img.SaveAsWebpAsync("lossy.webp", new WebpEncoder { EntropyPasses = 1, FileFormat = WebpFileFormatType.Lossy, Method = WebpEncodingMethod.BestQuality, NearLossless = true, Quality = 100, TransparentColorMode = WebpTransparentColorMode.Preserve });

Images

original input (also zipped to prevent "optimization"):
original.zip

broken output png:

working jpg (quality doesn't matter):

webp also works but file is not support 😄

[JimBobSquarePants]

If it encodes fine with the other encoders, then the source image isn't a problem.

Does explicitly setting the color mode on png encoding make a difference? I'm wondering if it's a metadata thing. I'm assuming the compressions level is irrelevant (it should be).

[KLuuKer]

compressionlevel doesn't change anything

new PngEncoder() { CompressionLevel = PngCompressionLevel.BestSpeed });
new PngEncoder() { CompressionLevel = PngCompressionLevel.DefaultCompression });

it does take WAY WAY to long for them to finish processing on a machine that runs at 4.7ghz...
release mode no debugger attached (but launched from visual studio)

1. image is being loaded internally as a Image<Rgba32>, but I am only treating it as a generic Image
2. NO Exif or *Profile data

---

setting color type WORKS
THIS WORKS!

new PngEncoder() { CompressionLevel = PngCompressionLevel.BestCompression, ColorType = PngColorType.RgbWithAlpha });

[KLuuKer]

it does take around 50 seconds for that working line to finish processing (just that saveasasync method)

irfanview tells me this about the original input image

[KLuuKer]

there is a PLTE Palette chunk inside apparently

i used this random site to check it
https://www.nayuki.io/page/png-file-chunk-inspector

[brianpopow]

The issue seems to be a regression introduced between version 2.1.4 and 3.0.0.
It seems the quantization process is what takes so long here and I would assume could also be a reason for the wrong colors (but this is only a guess at this point)

[KLuuKer]

confirming 2.14 works
works 3.0.0-alpha.0.1 ~ 3.0.0-alpha.0.61

BROKEN\SLOW 3.0.0-alpha.0.62 ~ 3.0.0-alpha.0.90

3.0.0-alpha.0.61+451a713fc11f2825946350c8f02c25b310509f57
3.0.0-alpha.0.62+b40482642cf264df87e96addfcfdf6120dc608dc

[KLuuKer]

Seems to be this +1,430 -1,610 massive pull request 😭
Normalize and cleanup encoders #2269

[JimBobSquarePants]

Should be simple enough to profile.

[JimBobSquarePants]

OK. The issue is exposed within that commit but was preexisting.

The WuQuantizer does not currently work well with the default pixel sampling strategy as it attempts to rebuild the histogram each time for each sampled region. I need to figure out a way to allow that.

[JimBobSquarePants]

I don't know how to fix the quantizer (yet) but I've changed the default strategy in #2485 to avoid the issue.

[KLuuKer]

Never knew my "small" problem would end up having this much code changed.
But seeing as it's by the big cleanup pull I can understand why.

[JimBobSquarePants]

Tiny code change for your issue (though I fear much greater change in the future). I'm just fixing a bunch of other stuff at the same time.