Issues with alpha layer, type, etc.

[Drarakel]

I'm having some issues for some time - especially with the alpha layer. But I'm not that experienced in that area, so maybe I misunderstood some things. Some of the things may be limited to the BMP format (or maybe it's just a coincidence?).. I'm also not sure if/how the issues are related to each other..

First: Can someone tell me what are the latest available binaries? I'm using the Q16 Windows static binaries, on Windows XP - the IM version is probably v6.6.1-5. I think there are small inconstancies with the version numbers on the download page/filenames and the numbers that IM itself reports. On my system, "convert -version" currently says:
Version: ImageMagick 6.6.1-6 2010-04-23 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2010 ImageMagick Studio LLC
Features: OpenMP
But I still believe it's version 6.6.1-5.(?)
The 'software' list in Windows reported that version (downloaded at April 24th) as:
"ImageMagick 6.6.1-5 Q16 (2010-05-01)"
I'm confused..

Now to some of my problems:

Case 1:

A plain 24bit BMP (sample taken from this thread):
http://www.tmace.com/viewer.php?file=51 ... 444716.bmp
"identify -verbose":
Type: Palette
Colorspace: RGB
Depth: 8-bit
Channel depth:
red: 8-bit
green: 8-bit
blue: 8-bit
Channel statistics:
...
(By the way, type "Palette" seems strange to me - as the file is stored as normal 3x8bit, so I would expect "TrueColor". But probably identify shows the values of the in-memory image - not the actual file representation. Is that correct?)
Now if I use the following command to create an alpha channel (set to opaque):
convert test.bmp -alpha on teston.png
Identify shows that:
Type: PaletteMatte
Colorspace: RGB
Depth: 8-bit
Channel depth:
red: 8-bit
green: 8-bit
blue: 8-bit
alpha: 8-bit
Channel statistics:
...
Alpha:
min: 0 (0)
max: 1 (0.00392157)
mean: 4.64511e-005 (1.82161e-007)
...
Histogram:
43054: (224, 9, 29,255) #E0091D rgba(224,9,29,1)
2: (224, 9, 29,254) #E0091DFE rgba(224,9,29,0.996078)
...

A command with "-alpha set" instead of "-alpha on" seems to work:
Type: PaletteMatte
Colorspace: RGB
Depth: 8-bit
Channel depth:
red: 8-bit
green: 8-bit
blue: 8-bit
alpha: 1-bit
Channel statistics:
...
Alpha:
min: 0 (0)
max: 0 (0)
mean: 0 (0)
...
Histogram:
43056: (224, 9, 29,255) #E0091D rgba(224,9,29,1)
...
I'm not sure anymore if some values represent alpha or opacity, but the identify output and the actual file look ok.
I just think (as the input file has no pre-existing alpha channel) that both commands should produce the same output..?

Case 2:

Just an example that shows that "-alpha on" can work. It's basically the same image as above - saved with a different software:
http://www.tmace.com/viewer.php?file=19 ... 045860.bmp
Actually, I would call this file 'TrueColorMatte' - it comes with an alpha channel. But ImageMagick doesn't recognize this channel - belongs probably to this thread. Anyway, IM treats it as an image without alpha - like in Case 1. Identify:
Type: Palette
Colorspace: RGB
Depth: 8-bit
Channel depth:
red: 8-bit
green: 8-bit
blue: 8-bit
Channel statistics:
...
Here, "-alpha on" produces the same output as "-alpha set":
Type: PaletteMatte
Colorspace: RGB
Depth: 8-bit
Channel depth:
red: 8-bit
green: 8-bit
blue: 8-bit
alpha: 1-bit
...
Alpha:
min: 0 (0)
max: 0 (0)
mean: 0 (0)
...
Histogram:
43056: (224, 9, 29,255) #E0091D rgba(224,9,29,1)
...

(The behaviour in case 1 and case 2 doesn't show just for these two files. It can be done with e.g. internal IM images, too.)

Case 3:

Also about the alpha channel.. This time, ImageMagick 'invents' alpha channels out of the blue. (Probably it's not related to the above issues.)
I have this issue whenever I do color conversions (with color profiles). I think it always occurs when there is a color profile present.
One can take a random image from the web - for example:
http://www.pbase.com/kevin_ve/image/60070066/original
As it's a JPG, it has no alpha channel of course. Identify:
Type: TrueColor
Colorspace: RGB
Depth: 8-bit
Channel depth:
red: 8-bit
green: 8-bit
blue: 8-bit
Channel statistics:
...
Profile-icc: 3144 bytes
Description: sRGB IEC61966-2.1
...
Now, after a simple "convert input.jpg output.bmp", identify shows this:
Type: TrueColorMatte
Colorspace: RGB
Depth: 8-bit
Channel depth:
red: 8-bit
green: 8-bit
blue: 8-bit
alpha: 1-bit
...
Alpha:
min: 0 (0)
max: 0 (0)
mean: 0 (0)
...
At this step, my output.bmp doesn't seem to contain any alpha channel. But identify thinks it does.
I can make a second conversion ("convert output.bmp output2.bmp"): Now not only identify shows an alpha channel (the identify output stays the same), but the file really contains one.

Case 4:

The issues can even partly be 'summarized' with a command like that:
"convert rose: -profile sRGB.icm rose.bmp"
Identify says:
Type: TrueColorMatte
Colorspace: RGB
Depth: 8/16-bit
Channel depth:
red: 8-bit
green: 8-bit
blue: 8-bit
alpha: 16-bit
...
Alpha:
min: 0 (0)
max: 1 (0.00303655)
mean: 0.000240472 (9.43027e-007)
...


I hope that most of that rather longish post was understandable (English is not my mother tongue).
I would be glad if some users here could affirm some of the things - or give hints if I made something wrong.
Eventually, I will create (separate) threads for the issues in the bug forum.

[snibgo]

Sorry, I can't help you with version numbers.

I can't open "65714097927030291028.bmp". Microsoft Photo Viewer says it is damaged or corrupt.

4-channel BMP files don't have a definition for the 4th channel. Some software treats the 4th as alpha. Other software (like ImageMagick) doesn't. I would never use BMP for anything, unless I really have to.

I would ignore the values given under "alpha min", "alpha max" etc. At least under 6.6.0-8, they are misleading, to put it very politely.

[fmw42]

see my bug report at viewtopic.php?f=3&t=16086 about misleading alpha values

[Drarakel]

I can't open "65714097927030291028.bmp". Microsoft Photo Viewer says it is damaged or corrupt.

Sorry. Seems that the host I used is checking the referrer. I made a new upload and updated the links (this time not with direct links). You should be able to get to the pictures now.

4-channel BMP files don't have a definition for the 4th channel. Some software treats the 4th as alpha. Other software (like ImageMagick) doesn't. I would never use BMP for anything, unless I really have to.

Well, ImageMagick does read/write transparency at least with BMP V4 files. But even if this could be 'disabled' - it wouldn't help here, as the error seems to lie partly in the reading of files that have no alpha layer in the first place. And I know now that it isn't all limited to BMP files.

Take case 1:
Instead of my example with the 24bit BMP, you could try something like that:

Code: Select all

convert -size 100x100 xc:blue blue.png
convert blue.png -alpha on blueon.png
identify -verbose blueon.png

My result shows:
Type: PaletteMatte
Colorspace: RGB
Depth: 16-bit
Channel depth:
red: 1-bit
green: 1-bit
blue: 1-bit
alpha: 16-bit
Channel statistics:
...
Alpha:
min: 0 (0)
max: 256 (0.00390631)
mean: 0.0455 (6.94285e-007)
...
Histogram:
9998: ( 0, 0,65535,65535) #00000000FFFF blue
1: ( 0, 0,65535,65279) #00000000FFFFFEFF rgba(0%,0%,100%,0.996094)
1: ( 0, 0,65535,65336) #00000000FFFFFF38 rgba(0%,0%,100%,0.996963)
...
(The example works this way only with Q16.)

I would ignore the values given under "alpha min", "alpha max" etc. At least under 6.6.0-8, they are misleading, to put it very politely.

see my bug report at viewtopic.php?f=3&t=16086 about misleading alpha values

Yeah, I saw some reports there. I lost the overview somehow about what is fixed right now and what not and in what versions... That's one of the reasons why I wanted to post in the user section first.
But: I think, my examples here are not about 'misleading' values. The stray pixels that "-alpha on" sometimes produces are real! If I write the output into a BMP, I can check it myself with a hex editor. In my first example here, there are really two pixels in the output file with 0xFE as alpha value. All the other pixels have 0xFF, like they should.

After writing the posts here and after some additional tests, I think I have already a clearer view about what happens. I'm still not completely sure about the origin of the problem with "-alpha on" (case 1).
But I think I know what causes the problem in case 3: It seems that this one is indeed limited to BMP files and that the reading of BMP V5 files is borked. ImageMagick reads the BMP V5 files as if they had an alpha layer - but they have not! And the problem showed everytime I made a color conversion (with BMP as output) because a color profile triggers the creation of V5 BMPs (usually V3 BMPs are written). The same with PNGs with a sRGB or GAMA chunk as input. For example, if I simply do "convert input.png output.bmp" and the input PNG (no alpha channel) has a GAMA chunk, a BMP V5 gets written. This BMP still has no alpha layer at all - but as I said, ImageMagick thinks it does.

Back to "type":

By the way, type "Palette" seems strange to me - as the file is stored as normal 3x8bit, so I would expect "TrueColor". But probably identify shows the values of the in-memory image - not the actual file representation. Is that correct?

Can someone give me a hint or a URL where the type in identify -verbose is described? I've read some things, but I'm still unsure about that info.

[snibgo]

I think you have identified a bug in "-alpha on". I have reported it: viewtopic.php?f=3&t=16142

[Drarakel]

Thanks!
I will report the other one (BMP V5), too.