Transparent pixels changing color when scaling

[eric]

I'm running into some issues using convert---it appears that transparent white pixels are being changed to transparent black pixels when resizing an image.

Reproduction steps:

Use the following test file (testcase.txt)
# ImageMagick pixel enumeration: 2,2,255,srgba
0,0: (255,255,255, 0) #FFFFFF00 srgba(255,255,255,0)
1,0: (255,255,255, 0) #FFFFFF00 srgba(255,255,255,0)
0,1: (255,255,255, 0) #FFFFFF00 srgba(255,255,255,0)
1,1: (255,255,255, 0) #FFFFFF00 srgba(255,255,255,0)

Now run the command
convert -scale 200% testcase.txt out.txt

The result in out.txt is:
# ImageMagick pixel enumeration: 4,4,255,srgba
0,0: ( 0, 0, 0, 0) #00000000 none
1,0: ( 0, 0, 0, 0) #00000000 none
2,0: ( 0, 0, 0, 0) #00000000 none
3,0: ( 0, 0, 0, 0) #00000000 none
0,1: ( 0, 0, 0, 0) #00000000 none
1,1: ( 0, 0, 0, 0) #00000000 none
2,1: ( 0, 0, 0, 0) #00000000 none
3,1: ( 0, 0, 0, 0) #00000000 none
0,2: ( 0, 0, 0, 0) #00000000 none
1,2: ( 0, 0, 0, 0) #00000000 none
2,2: ( 0, 0, 0, 0) #00000000 none
3,2: ( 0, 0, 0, 0) #00000000 none
0,3: ( 0, 0, 0, 0) #00000000 none
1,3: ( 0, 0, 0, 0) #00000000 none
2,3: ( 0, 0, 0, 0) #00000000 none
3,3: ( 0, 0, 0, 0) #00000000 none
The white transparent pixels have become black transparent pixels. This does not occur when using -scale 100% --- the output is identical to the input in that case.

This worked as expected in version 6.5.7-0, producing the output
# ImageMagick pixel enumeration: 4,4,255,srgba
0,0: (255,255,255, 0) #FFFFFF00 srgba(255,255,255,0)
1,0: (255,255,255, 0) #FFFFFF00 srgba(255,255,255,0)
2,0: (255,255,255, 0) #FFFFFF00 srgba(255,255,255,0)
3,0: (255,255,255, 0) #FFFFFF00 srgba(255,255,255,0)
0,1: (255,255,255, 0) #FFFFFF00 srgba(255,255,255,0)
1,1: (255,255,255, 0) #FFFFFF00 srgba(255,255,255,0)
2,1: (255,255,255, 0) #FFFFFF00 srgba(255,255,255,0)
3,1: (255,255,255, 0) #FFFFFF00 srgba(255,255,255,0)
0,2: (255,255,255, 0) #FFFFFF00 srgba(255,255,255,0)
1,2: (255,255,255, 0) #FFFFFF00 srgba(255,255,255,0)
2,2: (255,255,255, 0) #FFFFFF00 srgba(255,255,255,0)
3,2: (255,255,255, 0) #FFFFFF00 srgba(255,255,255,0)
0,3: (255,255,255, 0) #FFFFFF00 srgba(255,255,255,0)
1,3: (255,255,255, 0) #FFFFFF00 srgba(255,255,255,0)
2,3: (255,255,255, 0) #FFFFFF00 srgba(255,255,255,0)
3,3: (255,255,255, 0) #FFFFFF00 srgba(255,255,255,0)

I suspect this is a bug, since I don't think that simply scaling an image should change the colors of the pixels in this manner. (I originally observed this issue when converting gif to png, but was able to reproduce it in the above test case using text files.) I apologize if I am simply misunderstanding how the convert command should be used. Any help would be greatly appreciated.


Thanks,
Eric

OS:
CentOS release 5.7 (Final)
ImageMagic:
Version: ImageMagick 6.8.0-7 2012-11-28 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2012 ImageMagick Studio LLC
Features: OpenMP

[fmw42]

On IM 6.8.0.7 Q16 (OpenMP disabled) Mac OSX Snow Leopard, I get the same incorrect result.

convert -size 2x2 xc:"rgba(255,255,255,0)" -alpha on -channel rgba -scale 200% txt:
# ImageMagick pixel enumeration: 4,4,65535,srgba
0,0: ( 0, 0, 0, 0) #0000000000000000 none
1,0: ( 0, 0, 0, 0) #0000000000000000 none
2,0: ( 0, 0, 0, 0) #0000000000000000 none
3,0: ( 0, 0, 0, 0) #0000000000000000 none
0,1: ( 0, 0, 0, 0) #0000000000000000 none
1,1: ( 0, 0, 0, 0) #0000000000000000 none
2,1: ( 0, 0, 0, 0) #0000000000000000 none
3,1: ( 0, 0, 0, 0) #0000000000000000 none
0,2: ( 0, 0, 0, 0) #0000000000000000 none
1,2: ( 0, 0, 0, 0) #0000000000000000 none
2,2: ( 0, 0, 0, 0) #0000000000000000 none
3,2: ( 0, 0, 0, 0) #0000000000000000 none
0,3: ( 0, 0, 0, 0) #0000000000000000 none
1,3: ( 0, 0, 0, 0) #0000000000000000 none
2,3: ( 0, 0, 0, 0) #0000000000000000 none
3,3: ( 0, 0, 0, 0) #0000000000000000 none

Looks like a bug to me.

[snibgo]

On IM 6.7.9-Q16, Windows 7, with fmw's command, I get the same result.

6.5.8, 6.6.0, 6.6.1 and 6.6.2 are fine.

[Jason S]

It's not a bug. The algorithm used does not retain the hidden colors, and there's no (easy) way to change it to do so.

[fmw42]

It's not a bug.

You are indeed correct. I had earlier read the post you linked, but it had not sunk in until now. Thanks for pointing that out. Here is the key part from Nicolas's post:

"The pixel values of the color channels are first multiplied by the alpha (transparency) channel's pixel value, then linear resampling is performed, and finally the final color channel values are obtained by "unmultiplying" the results of resampling the alpha-multiplied color channels by dividing them by the alpha value at the same location, with some exception handling when alpha is close to zero. That is, the color (non transparency) channels are resampled taking transparency into account."



I believe this is what is needed to get the desired result (process each channel separately):


convert -size 2x2 xc:"rgba(255,255,255,0)" -alpha on -channel rgba -separate -scale 200% -combine -colorspace sRGB -depth 8 txt:

# ImageMagick pixel enumeration: 4,4,255,srgba
0,0: (255,255,255, 0) #FFFFFF00 srgba(255,255,255,0)
1,0: (255,255,255, 0) #FFFFFF00 srgba(255,255,255,0)
2,0: (255,255,255, 0) #FFFFFF00 srgba(255,255,255,0)
3,0: (255,255,255, 0) #FFFFFF00 srgba(255,255,255,0)
0,1: (255,255,255, 0) #FFFFFF00 srgba(255,255,255,0)
1,1: (255,255,255, 0) #FFFFFF00 srgba(255,255,255,0)
2,1: (255,255,255, 0) #FFFFFF00 srgba(255,255,255,0)
3,1: (255,255,255, 0) #FFFFFF00 srgba(255,255,255,0)
0,2: (255,255,255, 0) #FFFFFF00 srgba(255,255,255,0)
1,2: (255,255,255, 0) #FFFFFF00 srgba(255,255,255,0)
2,2: (255,255,255, 0) #FFFFFF00 srgba(255,255,255,0)
3,2: (255,255,255, 0) #FFFFFF00 srgba(255,255,255,0)
0,3: (255,255,255, 0) #FFFFFF00 srgba(255,255,255,0)
1,3: (255,255,255, 0) #FFFFFF00 srgba(255,255,255,0)
2,3: (255,255,255, 0) #FFFFFF00 srgba(255,255,255,0)

[eric]

Thanks all for the replies. This makes sense after reading the post on the scaling algorithm. I'll try the command fmw42's suggestion---it looks like it will do what I'm looking for.
Thanks!
Eric