Getting bad color results compared to imagemagick

[Rabcor]

Source Image (Note: Browser will likely not render colors correctly (they will be desaturated), this is probably related to the issue):

Output of pngquant --nofs test.png :

Output of magick test.png +dither PNG8:magickout.png:

I am not sure what exaclty the problem is, the source image was created with this command:

ffmpeg -ss 1 -i in.mp4 -frames:v 1 -pix_fmt rgb24 test.png

However what I noticed is that if I simply pass the image through imagemagick first before passing it through pngquant, I get correct results (better than former magick example) with pngquant.

magick test.png test2.png
pngquant --nofs test2.png

So there is some step that imagemagick takes to fix an issue with the PNG that pngquant is not taking which is causing this issue, I'm not entirely sure what though.

[kornelski]

Your file defines color using cICP chunk, which is a very recent addition to the PNG standard.

I can't see the difference on my machine, probably because I don't have any image viewer that supports the cICP color definition.

[Rabcor]

Your file defines color using cICP chunk, which is a very recent addition to the PNG standard.

I can't see the difference on my machine, probably because I don't have any image viewer that supports the cICP color definition.

The latter 2 images both look correct even in a browser, .e.g. they are the desired result, the image viewer I typically use is qimgv, but mpv renders the source PNG correctly if you need a viewer that can.

[kornelski]

Oh, sorry, I haven't the difference in the browsers. I was expecting a bigger saturation change, and I didn't notice the gamma difference from looking at images by side by side. I more carefully flipped between images in macOS Preview.app, but it didn't show any difference between the original image and pngquant's output.

If I edit out the cICP chunk, the file matches colors of pngquant's output in Firefox and Chrome too:

The cICP chunk has value 0x06010001, which asks for BT.709 gamma curve. The curve is y=1.0993 * x^0.45 - 0.0993. The file also has a fallback gAMA chunk with value 50994, which means gamma y=x^0.50994. The curves are reasonably close for high values, but disagree for low values. I suspect this is what causes the difference, but it's hard to say, because the cICP versions look different.

The gAMA chunk was the correct one to use according to the PNG spec between 1996 and June 2025.

Your example of processing with magick first looks like it's ignoring both cICP and gAMA and uses sRGB gamma curve instead. If I destroy all color information in the input file, I get a result close to what magick produces. This is definitely an bad interpretation of the original image, in every version of the PNG spec. You get a consistent results in that case, because in magick's output there's no cICP nor gAMA any more, so and there's nothing left to misinterpret any further.

So yeah, the image requires support for the cICP chunk. It's not backwards compatible, and every tool that doesn't support PNG3 spec released in June 2025 will find misleading color fallback in the file. pngquant interprets the fallback correctly according to the rules that have been valid for 29 years before. magick messes up both.

[Rabcor]

It makes sense, passing the image through magick slightly alters the colors too, at least for the source image in the question. The source image itself is also inaccurate thanks to -pix_fmt rgb24, because the source is a 10bit video ffmpeg defaults to a rgb48 and that gives right colors. It retains them even when passed through magick, e.g.

ffmpeg -ss 1 -i in.mp4 -frames:v 1 test.png # creates in this case an rgb48be image

Followed by

magick test.png +dither PNG24:test2.png # convert to rgb24 image

In a viewer with proper support for the former image (e.g. mpv, or qimgv) those 2 images look completely identical, can't see any color difference at all, the browser renders the former one wrong for the same reasons I would assume. The rest follows the same pattern though, but what's interesting here is that in this case there was no observable color change when passing the image through imagemagick like in the original question, although I didn't post any of the images passed through magick in that one except for the ones converted to 8 bit format.

Not sure if that holds any relevance but I thought it was interesting.

The latter image here is rendered completely correctly by the browser too. So imagemagick seems to be failing it's way to success. It's a bit intriguing how the color gets perfectly preserved by both ffmpeg and magick in this sequence, but if I use -pix_fmt rgb24 in the ffmpeg frame extraction, both ffmpeg and magick mess up the result in their own ways.

[kornelski]

Color metadata in videos is even messier problem than in images. For example, lots of video files lack sufficient metadata to distinguish between BT.601 (analog TV) and Rec.709 color (HDTV) color gamut, so there's an informal de-facto standard of assuming <=480p is the old standard, and >480p is HDTV. On top of that video players often don't want to apply expensive non-linear color conversions, so they either ignore them or apply only partially.

So if the image from imagemagick that ignored the gamma curve looks "correct" like the video, the chances are that your video player ignored the gamma metadata too.

[Rabcor]

Color metadata in videos is even messier problem than in images. For example, lots of video files lack sufficient metadata to distinguish between BT.601 (analog TV) and Rec.709 color (HDTV) color gamut, so there's an informal de-facto standard of assuming <=480p is the old standard, and >480p is HDTV. On top of that video players often don't want to apply expensive non-linear color conversions, so they either ignore them or apply only partially.

I don't think it did, mpv has a reputation for being really good at this stuff.

Here's what it says about the source video file

Using ffprobe to further investigate the file:

Pixel Format: yuv420p10le
Colorspace: smpte170m (BT601-525)
Color Primaries: smpte170m (BT601-525)
Color Transfer: bt709
Color Range: tv (limited)
Chroma Location: left

I believe bt1886 has complete backwards compatibility with bt709 for color transfer, so it is actually recommended to do exactly what mpv is doing here.

I've seen what you're talking about, videos missing a lot of this metadta, where fpfrobe just returns 'unknown' for some of these values, but this video doesn't appear to be such a case.

By default, i think mpv also uses non-linear color conversion. They have always been about quality first, performance second.

---

Also, this might deserve a separate issue, or not one at all depending on how much you care about pngquant color selection failures for specific images, because I've found an image where pngquant botches the color selection for the main focal point of the image but does it more or less right for the rest of the image.

Here is the source image, similar to before, it was extracted with ffmpe then optimized with imagemagick to ensure pngquant will read it right (so no cicp or gama factor in play):

Here it is after pngquant --nofs --speed=1, take note of the eye color, it turns from blue to green.

Here it is after magick in.png +dither PNG8:mout.png the eye retains the original color, though dulled, rest is similar to pngquant.

[kornelski]

Your video player may be displaying the metadata, but does it actually apply it? Does the video look like the exported PNG in Chrome (which seems to have correct handling of cICP), or like the imagemagick version?

[Rabcor]

Your video player may be displaying the metadata, but does it actually apply it? Does the video look like the exported PNG in Chrome (which seems to have correct handling of cICP), or like the imagemagick version?

The character is meant to have cyan eyes according to her text description, so I'm inclined to believe that mpv is displaying the correct colors. the way that first image in my last post looks (even in the browser) is how it looks in mpv

Either way though, that's kinda irrelevant, if you want to know the intricacies of mpv's color handling you can check it's code: https://github.com/mpv-player/mpv

The issue with this particular case isn't really about whether the source image has accurate colors or not compared to the source video, it's more about how pngquant fails to represent the color on the image's main focal point correctly according to this source.

E.g. the input image is the first image in the post, and the output image from pngquant was the second one, and arguably the most important color of the source image was poorly represented was my point.