Add or preserve alpha channel

[salsaman]

Hi,
I am trying to do the following:

convert an image (format is not know ahead of time) to png. If the source image has an alpha channel, preserve it. If the source image has no alpha channel, add an opaque one.

-alpha Set almost does what I want, except that it makes black pixels in the source transparent.

[fmw42]

use -alpha on

convert image -alpha on outimage

see http://www.imagemagick.org/Usage/masking/#alpha_on

[salsaman]

I have tried that, it does the same as Set, i.e turns black pixels transparent.

also, -alpha Background keeps the black pixels black, but does not add any alpha channel. -alpha Opaque would be OK, except that I want to preserve any exsting alpha channel.

[fmw42]

-alpha on should work. at this point you need to post a link to your image so that others can review its characteristics and try -alpha on. Perhaps your version of IM is too old for the -alpha commands. What version of IM and what platform are you on?

[salsaman]

You may well be right. Looking at the code the problem could be in gdk_pixbuf_new_from_file() not handling the png alpha channel correctly.

Is there some way I can visualise the alpha channel as greyscale to check ?

[fmw42]

convert image -alpha extract image_alpha_channel.png

[anthony]

convert an image (format is not know ahead of time) to png. If the source image has an alpha channel, preserve it. If the source image has no alpha channel, add an opaque one.

-alpha Set almost does what I want, except that it makes black pixels in the source transparent.

can you post that image! -alpha set should only make pixels transparent if the input image already has alpha enabled and those pixels are already transparent!

[glennrp]

Try "convert input png32:output.png"

[chui]

Sorry for digging up an old thread.
I've been trying to concatenate a few RGBA bitmaps with alpha channel that could possibly be blank.
I find that Magick would smartly convert those blanks ones into opaque (even if I force PNG32:out.png) white images, which is not what I wanted.
And, no matter how I use
-background none
-background transparent
-channel RGBA
-alpha on
-alpha set
I still don't get it to work as expected i.e. preserve the alpha for me.
However, if I use convert.exe, I was able to get alpha as wanted.

Does anybody know if it's a bug in Magick.exe or if there's any way I can preserve alpha ?

update: the convert.exe used was from an older version of IM.

[snibgo]

Your question is a bit vague for a proper answer.

Perhaps you can provide a sample input(s), a command, and tell us what it is doing wrong. Also say what version of IM you are using. And your platform.

[chui]

Thanks for your reply snibgo.

I've put sample input and output files here:
https://www.dropbox.com/sh/ry8xhwey5rmu ... NvrSa?dl=0

Platform: Windows. I'm using the executables from ImageMagick-7.0.3-2-portable-Q16-x86.zip.

Input files: 1.bmp and 2.bmp, Both RGBA
1 has a little mark on a transparent background, 2 has all alpha = transparent.

Commands:
magick convert 1.bmp PNG32:1.png
magick convert 2.bmp PNG32:2.png

I get 1 as correct - with alpha preserved, but 2 as a solid white image.

I tried montage.exe, and convert.exe and also those parameters as mentioned in my last message but the result is the same.
In the file resultOpenedInPaintNet.PNG, you can clearly see the transparency difference.

I have an older convert.exe, which I've lost track of the version, and result from it (olderConvertEXE 2.png) is usable since the all-transparent image preserves whole page alpha = 0, although the color now is showed as black in Window's preview.

Hope this makes the issue clear.

[snibgo]

You say:

1 has a little mark on a transparent background, 2 has all alpha = transparent.

What software shows the images in this way?

BMP is a Microsoft format. Historically, Microsoft were vague about what the alpha channel was supposed to do.

Windows Photo Viewer shows 1.bmp and 2.bmp as opaque. Microsoft Paint, and Gimp, see them both as opaque, with no alpha channel.

IM v6.9.0-0 sees 2.bmp as transparent. v6.9.1-0 and later versions sees 2.bmp as opaque white.

For 1.bmp, IM v6.9.5-3 sees 1.bmp as mostly transparent.

So, current IM is consistent with Microsoft software, seeing 2.bmp as opaque. But IM is inconsistent with Microsoft for 1.bmp

Code: Select all

convert 2.bmp -alpha on b.png

This results in b.png being transparent. I don't know why.

To me, it would make sense if IM treated the files in the same way as Microsoft software, showing them both as opaque.

[chui]

Those RGBA bmp's are generated by my own program so I know the pixel is 32-bit instead of 24-bit. It looks like most Windows software tools just ignore the alpha channel and treat the bitmap as RGB.
To me, if the A channel data is there, it is probably better not to ignore it. And for the case of IM, it seems good to let the user decide via the -alpha switch.

[snibgo]

Yes, your files have 32 bits/pixel, as verified by exiftool.

When I wrote my own image-processing software, decades ago, I used BMP because it was simple. But alpha was always a problem. I knew what it meant, within my own software, but other software wasn't consistent. I eventually gave up on the format.