BMP resize and convert troubleshoot

[MootoolsSoftware]

ImageMagick version

7.1.1.21

Operating system

Windows

Operating system, version and so on

Windows 11

Description

I am using imagemagick (7.1.1.21) to load some icon in a.bmp icon, resize it and output a b.bmp image.

I use the following command convert a.bmp -resize 24x24 b.bmp

You can find attached the input / output files.

There's 2 problems:

• The white background is converted to black
• The resize is incorrectly processed

I tried to force loading using bmp2, bmp3 format without success.

Using the same command with imagemagick V6 gave correct results (cf bv6.bmp attached).

Questions:
Is there something new introduced in V7 that explains the output?
If so, what should be the correct command?

Note: the following command give something similar to V6. But a bit complicated for a simple reduction operation, isn't it?
convert a.bmp -channel a -negate -channel rgba -define filter:blur=0.1 -resize 24x24 b.bmp

Steps to Reproduce

Simply use convert a.bmp -resize 24x24 b.bmp with the provided image

Images

images.zip

[snibgo]

As you have IM v7, I suggest using magick instead of convert.

a.bmp has transparency. Transparent pixels are transparent white.

There's 2 problems:
The white background is converted to black

Transparent white pixels are changed to transparent black. You can change these to transparent white like this:

magick a.bmp -resize 24x24 -background White -alpha background out.bmp

Or, if you want to remove transparency, you can flatten against white (or any other colour):

magick a.bmp -resize 24x24 -background White -layers flatten out2.bmp

The resize is incorrectly processed

In what way? The output is 24x24 pixels, as expected.

Using the same command with imagemagick V6 gave correct results (cf bv6.bmp attached).

But bv6.bmp has no transparency. As the input has transparency, we would expect the output to have transparency, unless you change that as I show above.

[MootoolsSoftware]

Thanks for the help.

Above is 'magick a.bmp -resize 24x24 -background White -alpha background out.bmp'.
Could you explain why the reduction appears awful as shown in the capture provided above?

Transparent white pixels are changed to transparent black.

This means that internally the alpha channel impacts and modifies the rgb channels.
What I would like is that resize just performs a resize operation independently on each channel without any interaction between the alpha and the other channels and color replacement.

[snibgo]

Could you explain why the reduction appears awful as shown in the capture provided above?

What do you mean by "awful"? What don't you like about it? What change would make it less awful?

What I would like is that resize just performs a resize operation independently on each channel without any interaction between the alpha and the other channels and color replacement.

You can separate the channels, resize each one, and re-combine them:

magick a.bmp -channel RGBA -separate -resize 24x24 -combine +channel -background White -alpha background x0s.bmp

[MootoolsSoftware]

What do you mean by "awful"? What don't you like about it? What change would make it less awful?

• On the left is what I consider as a good result. RGB channels image is clean and can be used without usage of the alpha channel. This is a resize operation obtain with photoshop.
• On the right RGB channels image is messed. This result is not usable unless you combined it with the alpha channel below.

[snibgo]

What program are you using to show the "nice" and "awful" results?

We can do something similar with ImageMagick:

magick a.bmp -resize 24x24 -background White -alpha background out.bmp

magick out.bmp ( +clone -channel RGBA -separate +channel ) +append +repage sep.png

This is sep.png:

The first of the 5 squares has transparency. They all look "nice" to me.

[MootoolsSoftware]

Thanks for all your help.

What program are you using to show the "nice" and "awful" results?

I am viewing the result with photoshop.
'magick a.bmp -resize 24x24 -background White -alpha background out.bmp' gives the following result:

Curiously, I didn't get the same results using 'magick out.bmp ( +clone -channel RGBA -separate +channel ) +append +repage sep.png', and as you can see, the rgb channels are scrambled.

This is different from yours.
In the capture above I put the magick version and the compiler used to generate the magick command.

[snibgo]

Your result is bad.

My IM version is:

Version: ImageMagick 7.1.1-20 Q16-HDRI x86 98bb1d4:20231008 https://imagemagick.org
Copyright: (C) 1999 ImageMagick Studio LLC
License: https://imagemagick.org/script/license.php
Features: Cipher DPC HDRI OpenCL OpenMP(2.0)
Delegates (built-in): bzlib cairo 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 (193532217)

I don't know why your result is bad.

Try saving to PNG instead of BMP. Is the result good or bad?

Is your installation a pre-built binary, from the IM website, or did you build it yourself?

Try a build with Q16 instead of Q8.

[MootoolsSoftware]

I've got the same result with bmp (above a capture of what is seen under photoshop as we can't drop bmp file on the post)

I'll try to compile using Q16. I'll be back there when I have some results ;-)

[snibgo]

I suggest trying with this command first:

set MAGICK_OCL_DEVICE=false

[MootoolsSoftware]

Recompile the solution using MAGICKCORE_QUANTUM_DEPTH 16

Version: ImageMagick 7.1.1-21 Q16-HDRI x64 20231021 https://imagemagick.org Copyright: (C) 1999 ImageMagick Studio LLC License: https://imagemagick.org/script/license.php Features: Channel-masks(64-bit) Cipher DPC HDRI Modules OpenCL OpenMP(2.0) Delegates (built-in): bzlib cairo fftw flif freetype gslib heic jbig jng jp2 jpeg jxl lcms lqr lzma openexr pangocairo png ps raqm raw rsvg tiff webp xml zip zlib Compiler: Visual Studio 2022 (193833130)

I've got the same result using 'magick out.bmp ( +clone -channel RGBA -separate +channel ) +append +repage sep.png'

With the same package, I use 'set MAGICK_OCL_DEVICE=false', then the result is the same.

Is this can be related to channel-mask (64-bit) or another features that is enabled ?

[dlemstra]

OpenCL is disabled by default in recent builds. It comes with support for OpenCL but you will need to enable it to use it.

[MootoolsSoftware]

OpenCL is disabled by default in recent builds. It comes with support for OpenCL but you will need to enable it to use it.

Just try it (even if I think this is not related to the issue reported here)
'set MAGICK_OCL_DEVICE=true
magick out.bmp ( +clone -channel RGBA -separate +channel ) +append +repage sep.png'

I got an abort call:

[dlemstra]

That is probably a problem with your videocard / driver. I will check if I can reproduce this tomorrow.

[snibgo]

There has been a recent change: the -resize operation can make negative alpha values. I think this is reasonable behaviour. However, -background White -alpha background (which should make fully transparent pixels into transparent-white) doesn't regard negative alpha as fully transparent. I'm not sure is this behaviour is reasonable.

Anyhow, a workaround is to use -clamp after -resize.

We can clamp just the alpha channel with "-channel A -clamp +channel".

[MootoolsSoftware]

That is probably a problem with your videocard / driver. I will check if I can reproduce this tomorrow.

Cleaning the solution and recompiling the whole project has solved the abort call related to opencl.

But I remember that the problem of the issue concerns the resize operation.

magick a.bmp -resize 24x24 -background White -alpha background out.bmp
magick out.bmp ( +clone -channel RGBA -separate +channel ) +append +repage sep.png

@snibgo magick operation gives

Version: ImageMagick 7.1.1-20 Q16-HDRI x86 98bb1d4:20231008 https://imagemagick.org Copyright: (C) 1999 ImageMagick Studio LLC License: https://imagemagick.org/script/license.php Features: Cipher DPC HDRI OpenCL OpenMP(2.0) Delegates (built-in): bzlib cairo 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 (193532217)

The same operation with my magick package gives:

Version: ImageMagick 7.1.1-21 Q16-HDRI x64 20231021 https://imagemagick.org Copyright: (C) 1999 ImageMagick Studio LLC License: https://imagemagick.org/script/license.php Features: Channel-masks(64-bit) Cipher DPC HDRI Modules OpenCL OpenMP(2.0) Delegates (built-in): bzlib cairo fftw flif freetype gslib heic jbig jng jp2 jpeg jxl lcms lqr lzma openexr pangocairo png ps raqm raw rsvg tiff webp xml zip zlib Compiler: Visual Studio 2022 (193833130)

[snibgo]

For me, there is no problem with IM v7.1.1-20, but there is with v7.1.1-22.

See my post above. The problem occurs when we have ...

-resize 24x24 -background White -alpha background

A workaround is to replace this with:

-resize 24x24 -channel A -clamp +channel -background White -alpha background

[MootoolsSoftware]

@snibgo sorry I miss your comment.
So I try it, but it still give a different result than the one you get with IM v7.1.1-20 (as shown below)

I'm not sure is this behaviour is reasonable.

Whatever the command, the resize result is bad. I am not sure resize choice are reasonable :-( and I still think this is a bug may be involved by the different compilation option.

Can this be due to Features: Channel-masks(64-bit) ?

magick a.bmp -resize 24x24 -channel A -clamp +channel -background White -alpha background out.bmp
magick out.bmp ( +clone -channel RGBA -separate +channel ) +append +repage sep2.png

The result is:

[snibgo]

Can this be due to Features: Channel-masks(64-bit) ?

I haven't experimented with this feature, but I doubt that is the cause.

We can fix the pixels you don't like by setting any alpha less than 0.02 (on a scale of 0.0 to 1.0) to 0.0.

magick a.bmp -resize 24x24 -channel A -clamp -fx "u<0.02?0:u" +channel -background White -alpha background out2.png

With this -fx, the -clamp is redundant, because the -fx will set negative values to zero.

[MootoolsSoftware]

I haven't experimented with this feature, but I doubt that is the cause.

I will make a try disabling that feature.

We can fix the pixels you don't like by setting any alpha less than 0.02 (on a scale of 0.0 to 1.0) to 0.0.

This does not explain why we've got differences between our two magick command.
What are your magick-baseconfig.h settings?

Don't you think the command is a bit complicated for such a simple operation?
All the more so as this command is possible only with a visual check of the result and multiple tries.

To process icons, I use image magick's C interface.
Before, with imagemagick version 6, a simple resize did the trick. I'm not sure that version 7 is any simpler. 😱

I'll keep you posted once the 64-bit alpha has been deactivated...

[MootoolsSoftware]

I recompile disabling 64 bits alpha.

Version: ImageMagick 7.1.1-21 Q16-HDRI x64 20231021 https://imagemagick.org
Copyright: (C) 1999 ImageMagick Studio LLC
License: https://imagemagick.org/script/license.php
Features: Cipher DPC HDRI Modules OpenCL OpenMP(2.0)
Delegates (built-in): bzlib cairo fftw flif freetype gslib heic jbig jng jp2 jpeg jxl lcms lqr lzma openexr pangocairo png ps raqm raw rsvg tiff webp xml zip zlib
Compiler: Visual Studio 2022 (193833130)

Using

magick a.bmp -resize 24x24 -background White -alpha background out.bmp
magick out.bmp ( +clone -channel RGBA -separate +channel ) +append +repage sep.png

I still get :

So our difference are not due to the 64-bit alpha feature.

May I send you my magick command as private message? So we might check if that can be related to a computer specific conf?