"-alpha on" sets bad value top-left

[snibgo]

"-alpha on" puts a bad alpha vaue in top-left pixel.

convert -size 4x4 xc:blue blue.png
convert blue.png -alpha on blueon.png

convert blue.png blue.txt

This shows the expected values (no alpha channel):

# ImageMagick pixel enumeration: 4,4,65535,rgb
0,0: ( 0, 0,65535) #00000000FFFF blue
1,0: ( 0, 0,65535) #00000000FFFF blue
2,0: ( 0, 0,65535) #00000000FFFF blue
3,0: ( 0, 0,65535) #00000000FFFF blue
0,1: ( 0, 0,65535) #00000000FFFF blue
1,1: ( 0, 0,65535) #00000000FFFF blue
2,1: ( 0, 0,65535) #00000000FFFF blue
3,1: ( 0, 0,65535) #00000000FFFF blue
0,2: ( 0, 0,65535) #00000000FFFF blue
1,2: ( 0, 0,65535) #00000000FFFF blue
2,2: ( 0, 0,65535) #00000000FFFF blue
3,2: ( 0, 0,65535) #00000000FFFF blue
0,3: ( 0, 0,65535) #00000000FFFF blue
1,3: ( 0, 0,65535) #00000000FFFF blue
2,3: ( 0, 0,65535) #00000000FFFF blue
3,3: ( 0, 0,65535) #00000000FFFF blue

convert blueon.png blueon.txt

This shows a bad alpha value (which Gimp also shows) at 0,0:

# ImageMagick pixel enumeration: 4,4,65535,rgba
0,0: ( 0, 0,65535,64990) #00000000FFFFFDDE rgba(0%,0%,100%,0.991684)
1,0: ( 0, 0,65535,65535) #00000000FFFF blue
2,0: ( 0, 0,65535,65535) #00000000FFFF blue
3,0: ( 0, 0,65535,65535) #00000000FFFF blue
0,1: ( 0, 0,65535,65535) #00000000FFFF blue
1,1: ( 0, 0,65535,65535) #00000000FFFF blue
2,1: ( 0, 0,65535,65535) #00000000FFFF blue
3,1: ( 0, 0,65535,65535) #00000000FFFF blue
0,2: ( 0, 0,65535,65535) #00000000FFFF blue
1,2: ( 0, 0,65535,65535) #00000000FFFF blue
2,2: ( 0, 0,65535,65535) #00000000FFFF blue
3,2: ( 0, 0,65535,65535) #00000000FFFF blue
0,3: ( 0, 0,65535,65535) #00000000FFFF blue
1,3: ( 0, 0,65535,65535) #00000000FFFF blue
2,3: ( 0, 0,65535,65535) #00000000FFFF blue
3,3: ( 0, 0,65535,65535) #00000000FFFF blue

IM 6.6.0-8 Q16 Windows 7.

[Drarakel]

And it's not always only one pixel. Sometimes "-alpha on" works, sometimes there's one wild pixel, sometimes there are more of them. (In my tests one of them was indeed always the top-left pixel. Strange.)

[snibgo]

It might help the developers/maintainers if you can show a simple case where a non-top-left pixel is bad.

[Drarakel]

OK. With a bigger version of that example, I get bad alpha values for the first and then the 511th pixel:
convert -size 26x26 xc:blue blue26.png
convert blue26.png -alpha on blue26on.png

These are the affected pixels then:
0,0: ( 0, 0,65535,65336) #00000000FFFFFF38 rgba(0%,0%,100%,0.996963)
...
16,19: ( 0, 0,65535,65279) #00000000FFFFFEFF rgba(0%,0%,100%,0.996094)

To visualize the result (stray alpha values replaced with red pixels and magnified by 2):

[fmw42]

I cannot reproduce that on IM 6.6.5-1 Q16 Mac OSX Tiger:

convert -size 26x26 xc:blue blue26.png
convert blue26.png -alpha on blue26on.png
identify -verbose blue26on.png
...
Histogram:
676: ( 0, 0,65535,65535) #00000000FFFF blue

What version of IM are you using and what platform?

[anthony]

Ditto for my Linux machine with latest IM. All seems to be working fine!

[Drarakel]

Maybe it only shows on Windows?
I'm using IM v6.6.1-5, on Windows XP.

For the last example (blue26on.png), I get that with identify -verbose:
Alpha:
min: 0 (0)
max: 256 (0.00390631)
mean: 0.673077 (1.02705e-005)
...
Histogram:
674: ( 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)
...

I could list all sorts of different results, for e.g. the 16bits/channel PNGs, or TIFs as output format; or for 8bits/channel BMPs as input/output etc. But probably this is not much worth - it's only 'scratching on the surface'.

But one more example - this time with IM v6.5.8-5 (couldn't recreate that with v6.6.1-5). This is really strange:
When I use that older version, I even get different results if I use different file paths.
convert -size 28x28 xc:olive olive28.png
convert olive28.png -alpha on olive28on.png
These two lines produce this on my system (only one alpha value that's slightly off - similar to the output of v6.6.1-5):

But if I type this:
convert -size 28x28 xc:olive olive28.png
convert olive28.png -alpha on e:\temp\olive28on.png
I get this (not similar to the output of v6.6.1-5):

I didn't modify the output file! You can easily see (if the browser displays it correctly) that a lot of pixels are partly transparent there.

[fmw42]

might you have multiple IMs installed and they are getting confused with each other? Or perhaps a bad install?

[Drarakel]

As snibgo is getting the bad values, too - I would say no, two bad installs are not likely..

Personally, I'm using the latest dynamically linked IM version as default - but have another (older, statically linked) version that's not in my PATH. That's all.

I can make even weirder examples:
With IM v6.6.1-5:
convert -size 28x28 xc:olive olive28.png
convert olive28.png -alpha on olive28on.png
Identify shows:
Alpha:
min: 0 (0)
max: 256 (0.00390631)
mean: 0.580357 (8.85568e-006)
...
Colors: 3
Histogram:
782: (32896,32896, 0,65535) #808080800000 olive
1: (32896,32896, 0,65279) #808080800000FEFF rgba(50.1961%,50.1961%,0%,0.996094)
1: (32896,32896, 0,65336) #808080800000FF38 rgba(50.1961%,50.1961%,0%,0.996963)
...
Nothing really new.. But if I type this:
convert -size 28x28 xc:olive olive28.png
convert -debug all olive28.png -alpha on olive28on.png
I get that:
Alpha:
min: 0 (0)
max: 31084 (0.474311)
mean: 3003.65 (0.0458327)
...
Colors: 94
(The histogram would be too long..)
That means that even the 'measurement' parameters have an impact on the output. (That's almost like quantum mechanics. )

But: It's not totally random! If I make the same command (with the same version), I'm always getting the same output. Well.. There seems to be an exception: Because the above is only true, if I always delete the old result file, before I make another test (with the same ouput filename). Overwriting a file sometimes produced a different output to what I expected.

Anyway.. I'm getting these effects only with "-alpha on". As I said in the other thread, with "-alpha set" everything's fine. And the two options shouldn't differ for files without alpha layer - unless I misunderstood the documentation.
It only shows in Windows so far. Maybe something with memory allocation? I don't know..

[snibgo]

All on Windows 7:

IM 6.5.8-8 Q16 never gives me this problem.

IM 6.6.1-1 Q8 never gives me this problem.

IM 6.6.0-8 Q16 consistently gives me incorrect alpha in the top-left pixel (and no other pixels, so far).

"%IMG%convert" olive28.png -alpha on h:\temp\olive28on.png
"%IMG%convert" h:\temp\olive28on.png o.txt

# ImageMagick pixel enumeration: 28,28,65535,rgba
0,0: (32896,32896, 0,64954) #808080800000FDBA rgba(50.1961%,50.1961%,0%,0.991135)
1,0: (32896,32896, 0,65535) #808080800000 olive
etc (1,0 and all other pixels are correct)


Repeating the command a couple of times, I got the same result, but then:

# ImageMagick pixel enumeration: 28,28,65535,rgba
0,0: (32896,32896, 0,64977) #808080800000FDD1 rgba(50.1961%,50.1961%,0%,0.991485)
1,0: (32896,32896, 0,65535) #808080800000 olive
etc (1,0 and all other pixels are correct)


Changing the filename slightly:

"%IMG%convert" olive28.png -alpha on h:\temp\olive28onzxc.png
"%IMG%convert" h:\temp\olive28onzxc.png o.txt

# ImageMagick pixel enumeration: 28,28,65535,rgba
0,0: (32896,32896, 0,64966) #808080800000FDC6 rgba(50.1961%,50.1961%,0%,0.991318)
1,0: (32896,32896, 0,65535) #808080800000 olive
etc (1,0 and all other pixels are correct)

EDIT: Yes, I have three versions installed, but they don't use DLLs, so shouldn't interfere with each other.

[anthony]

Anyway.. I'm getting these effects only with "-alpha on". As I said in the other thread, with "-alpha set" everything's fine. And the two options shouldn't differ for files without alpha layer - unless I misunderstood the documentation.
It only shows in Windows so far. Maybe something with memory allocation? I don't know..

It sounds to me like the image already has random data in a alpha channel area.

Remember -alpha on only turns on the alpha channel, if the alpha channel has data in it (random or otherwise) that data is preserved. If the channel did not previously exist, then that channel will be allocated. Under linux all allocated memory is always cleared to zero. It may be a problem on windows if memory allocation does not zero the memory. This may be the cause of the problem.

On the other hand, -alpha set (or the equivelent older -matte option) will not only turn on the alpha channel, it will clear the alpha channel to be fully-opacity if it was turned on (that is it was previously off). It does not care if the alpha channel for that image was already defined of not. If the channel turns on (because it was off) then it will always be cleared.

The bug then appears to be in the alpha channel memory allocation routine.

This may be why -alpha set (or -matte)is recommended after reading any image file format, rather than -alpha on.

I am sending a note to Cristy about this.

[magick]

We patched BMP to initialize the alpha channel, however, -alpha set is the correct solution to this problem. Initially assume the alpha channel is random for RGB and CMYK images. Assume a valid matte channel for RGBA and CMYKA.

[Drarakel]

Thanks for your responses!
So.. Could the documentation be updated with a warning that "-alpha on" shouldn't be used for images without existing transparency data (as it could lead to problems)?
http://www.imagemagick.org/script/comma ... .php#alpha
http://www.imagemagick.org/Usage/basics/#alpha_on

[anthony]

I noted this many times thought IM examples already.
From IM Example Basics, Alpha set
http://www.imagemagick.org/Usage/basics/#alpha_set

This is the recommended way of ensuring an image has an alpha channel after
reading it into memory, regardless of image file format being read.

Note that -alpha on is only really used when you previously, manually turned off alpha for some reason (such as preserve its contents when image is use with some operators, like -shade). I will mention that in IM examples for the alpha on setting.


I have always used -alpha set for any example that must have transparency, in a image image that may not have transparency.

[Drarakel]

OK. Thanks again!
(It seems the documentation has a bit changed now.)