montage: 8-bit PNG images incorrectly converted into 48-bit PNG images

[neofuji]

ImageMagick version

7.1.0-21

Operating system

Windows

Operating system, version and so on

Windows 11 Pro x64 22000.593

Description

From 7.1.0-21, montage converts 8-bit PNG images into 48-bit PNG images with corrupted color.
The output images of 7.1.0-20 were 8-bit PNG, the same format as input images.

Steps to Reproduce

7.1.0-20

C:\Program Files\ImageMagick-7.1.0-Q16-HDRI\images>magick -version
Version: ImageMagick 7.1.0-20 Q16-HDRI x64 2022-01-22 https://imagemagick.org
Copyright: (C) 1999-2021 ImageMagick Studio LLC
License: https://imagemagick.org/script/license.php
Features: Cipher DPC HDRI Modules OpenCL OpenMP(2.0)
Delegates (built-in): bzlib cairo flif freetype gslib heic jng jp2 jpeg jxl lcms lqr lzma openexr pangocairo png ps raqm raw rsvg tiff webp xml zip zlib
Compiler: Visual Studio 2022 (193030709)

C:\Program Files\ImageMagick-7.1.0-Q16-HDRI\images>magick identify convex-hull-blocks.png
convex-hull-blocks.png PNG 128x128 128x128+0+0 8-bit sRGB 7257B 0.000u 0:00.000

C:\Program Files\ImageMagick-7.1.0-Q16-HDRI\images>magick montage convex-hull-blocks.png -geometry 128x128 C:\convex-hull-blocks_7.1.0-20.png

C:\Program Files\ImageMagick-7.1.0-Q16-HDRI\images>magick identify C:\convex-hull-blocks_7.1.0-20.png
C:\convex-hull-blocks_7.1.0-20.png PNG 128x128 128x128+0+0 8-bit sRGB 7418B 0.000u 0:00.000

7.1.0-21

C:\Program Files\ImageMagick-7.1.0-Q16-HDRI\images>magick -version
Version: ImageMagick 7.1.0-21 Q16-HDRI x64 2022-01-28 https://imagemagick.org
Copyright: (C) 1999-2021 ImageMagick Studio LLC
License: https://imagemagick.org/script/license.php
Features: Cipher DPC HDRI Modules OpenCL OpenMP(2.0)
Delegates (built-in): bzlib cairo flif freetype gslib heic jng jp2 jpeg jxl lcms lqr lzma openexr pangocairo png ps raqm raw rsvg tiff webp xml zip zlib
Compiler: Visual Studio 2022 (193030709)

C:\Program Files\ImageMagick-7.1.0-Q16-HDRI\images>magick identify convex-hull-blocks.png
convex-hull-blocks.png PNG 128x128 128x128+0+0 8-bit sRGB 7257B 0.000u 0:00.000

C:\Program Files\ImageMagick-7.1.0-Q16-HDRI\images>magick montage convex-hull-blocks.png -geometry 128x128 C:\convex-hull-blocks_7.1.0-21.png

C:\Program Files\ImageMagick-7.1.0-Q16-HDRI\images>magick identify C:\convex-hull-blocks_7.1.0-21.png
C:\convex-hull-blocks_7.1.0-21.png PNG 128x128 128x128+0+0 16-bit sRGB 29887B 0.000u 0:00.000

Images

convex-hull-blocks_7.1.0-20.png

convex-hull-blocks_7.1.0-21.png

[snibgo]

Please show your input image, convex-hull-blocks.png.

[neofuji]

Please show your input image, convex-hull-blocks.png.

Here is from built-in images in ImageMagick.

[fmw42]

It is normal for ImageMagick to make the output depth the Q depth of your compile when new colors are introduced. So if you are on Q16, then he output from some processing would be 16-bits per pixel per channel.

I am not sure why your IM 7.1.0.20 is giving 8-bits. That is not typical and was likely corrected in 7.1.0.21.

If you want to keep 8-bits, then add -depth 8 to your command line (3x8=24-bit color or use PNG8: for 8-bit color)

[snibgo]

magick montage convex-hull-blocks.png -geometry 128x128 C:\convex-hull-blocks_7.1.0-21.png

This command will slightly shrink the input, and add a border. Shrinking (by resizing) is re-sampling, which usually adds new colours "between" existing colours.

When IM saves a PNG, by default it will use 8 bits/channel/pixel unless that would lose precision. If it would lose precision, it will use 16 bits/channel/pixel.

As fmw42 says, use "-depth 8" before the output if you want to force just 8 bits.

[neofuji]

magick montage convex-hull-blocks.png -geometry 128x128 C:\convex-hull-blocks_7.1.0-21.png

This command will slightly shrink the input, and add a border. Shrinking (by resizing) is re-sampling, which usually adds new colours "between" existing colours.

The original image convex-hull-blocks.png is 128x128 it doesn't cause resizing/resampling.

The document says "PNG inheriting subformat from original if possible."
Without using -depth 8, IM 7.1.0-20 converts to same subformat.
So I think IM 7.1.0-20 has correct behavior and IM 7.1.0-21 has incorrect behavior.

[snibgo]

That is only if you use "PNG00:"

PNG00 RW Portable Network Graphics PNG inheriting subformat from original if possible

But you haven't use "PNG00:".

[neofuji]

@urban-warrior
This issue is not resolved. Please reopen.

I tried adding PNG00: but the result is same as adding no PNG00:, IM 7.1.0-21 still converts PNG8 image into PNG48 incorrectly.
So PNG00: on IM 7.1.0-21 is clearly corrupted.

The changelog doesn't say any PNG encoder/decoder changed, so this problem is a software regression.
Please investigate the cause in ImageMagick program.

This problem is still represented on IM 7.1.0-31.

convex-hull-blocks_7.1.0-20-PNG00.png PNG 128x128 128x128+0+0 8-bit sRGB 7418B 0.000u 0:00.000

convex-hull-blocks_7.1.0-21-PNG00.png PNG 128x128 128x128+0+0 16-bit sRGB 29887B 0.000u 0:00.000

[urban-warrior]

Its not a bug. The issue has nothing to do with PNG. Instead montage resizes the image with ThumbnailImage(). Previously, your image was at a size that coincidentally was sampled rather than resized. Resizing introduces new colors. The new thumbnail algorithm prefers resizing to theoretically produce "better" thumbnails. Of course, if you simply convert your source image to PNG, you will get an exact replica.

[neofuji]

@urban-warrior
Then has montage been no longer usable to concatenate MxN images without any loss?

[urban-warrior]

We will add a patch to clone an image when its resize size is identical to its actual size. That should resolve this issue.

[fmw42]

You can resize (actually sample if you do not want any change in colors) outside montage and pipe the results to montage.

magick convex-hull-blocks.png -sample 128x128 miff:- | magick montage - C:\convex-hull-blocks_7.1.0-21.png

or

magick convex-hull-blocks.png -sample 128x128 PNG00:- | magick montage - C:\convex-hull-blocks_7.1.0-21.png

[neofuji]

@urban-warrior
Solved in IM 7.1.0-32. Thanks!