possible bug -threshold 0 on alpha channel

[fmw42]

IM 6.9.9.35 Q16 Mac OSX Sierra

Code: Select all

convert xc:"#D3B29E00" xc:"#D3B29EF4" xc:"#D3B19EB8" xc:"#D3B29EFF" +append tmp1.png

Code: Select all

convert tmp1.png txt:

# ImageMagick pixel enumeration: 4,1,65535,srgba
0,0: (54227,45746,40606,0) #D3B29E00 srgba(211,178,158,0)
1,0: (54227,45746,40606,62708) #D3B29EF4 srgba(211,178,158,0.956863)
2,0: (54227,45489,40606,47288) #D3B19EB8 srgba(211,177,158,0.721569)
3,0: (54227,45746,40606,65535) #D3B29EFF srgba(211,178,158,1)


The above image has 1 fully transparent alpha value, 1 fully opaque alpha value and two partially transparent alpha values.


I want to threshold the alpha channel at 0. So all values but the alpha=0 should go to 1. But the opposite is happening. All values but alpha=1 go to 0.

Code: Select all

convert tmp1.png -channel a -threshold 0 +channel tmp2.png

Code: Select all

convert tmp2.png txt:

# ImageMagick pixel enumeration: 4,1,65535,srgba
0,0: (54227,45746,40606,0) #D3B29E00 srgba(211,178,158,0)
1,0: (54227,45746,40606,0) #D3B29E00 srgba(211,178,158,0)
2,0: (54227,45489,40606,0) #D3B19E00 srgba(211,177,158,0)
3,0: (54227,45746,40606,65535) #D3B29EFF srgba(211,178,158,1)


Should not the two alpha values in red actually be 1?


P.S. This goes back at least as far as 6.9.8.3. I have not tested earlier versions

[fmw42]

The above seems to work fine in IM 7.0.7.23 Q16 HDRI Mac OSX Sierra

Code: Select all

magick xc:"#D3B29E00" xc:"#D3B29EF4" xc:"#D3B19EB8" xc:"#D3B29EFF" +append tmp1.png

Code: Select all

magick tmp1.png txt:

# ImageMagick pixel enumeration: 4,1,65535,srgba
0,0: (54227,45746,40606,0) #D3B29E00 srgba(211,178,158,0)
1,0: (54227,45746,40606,62708) #D3B29EF4 srgba(211,178,158,0.956863)
2,0: (54227,45489,40606,47288) #D3B19EB8 srgba(211,177,158,0.721569)
3,0: (54227,45746,40606,65535) #D3B29EFF srgba(211,178,158,1)

Code: Select all

magick tmp1.png -channel a -threshold 0 +channel tmp2.png

Code: Select all

magick tmp2.png txt:

# ImageMagick pixel enumeration: 4,1,65535,srgba
0,0: (54227,45746,40606,0) #D3B29E00 srgba(211,178,158,0)
1,0: (54227,45746,40606,65535) #D3B29EFF srgba(211,178,158,1)
2,0: (54227,45489,40606,65535) #D3B19EFF srgba(211,177,158,1)
3,0: (54227,45746,40606,65535) #D3B29EFF srgba(211,178,158,1)

Correct result: three values of 1 and one value of 0.

[fmw42]

The bug in the original post at the top does not seem to be corrected in IM 6.9.9.36 Q16 Mac OSX.

[fmw42]

This does not seem to be fixed in IM 6.9.9.37.

convert xc:"#D3B29E00" xc:"#D3B29EF4" xc:"#D3B19EB8" xc:"#D3B29EFF" +append tmp1.png
convert tmp1.png -channel a -threshold 0 +channel tmp2.png
convert tmp2.png txt:
# ImageMagick pixel enumeration: 4,1,65535,srgba
0,0: (54227,45746,40606,0) #D3B29E00 srgba(211,178,158,0)
1,0: (54227,45746,40606,0) #D3B29E00 srgba(211,178,158,0)
2,0: (54227,45489,40606,0) #D3B19E00 srgba(211,177,158,0)
3,0: (54227,45746,40606,65535) #D3B29EFF srgba(211,178,158,1)

The two sets of red 0s should be 1s (or FF)

[magick]

Thanks for the problem report. We can reproduce it and will have a patch to fix it in GIT master branch @ https://github.com/ImageMagick/ImageMagick later today. The patch will be available in the beta releases of ImageMagick @ https://www.imagemagick.org/download/beta/ by sometime tomorrow.