[solved] convert label with semi-transparent border has wrong background alpha value

[qubodup]

Hello,

Running the following command should create an image with evenly red semi-transparent background color, right?

Code: Select all

convert -background '#ff0000aa' -fill white -pointsize 72 -bordercolor '#ff0000aa' -border 40x20 label:"TEST" test.png

However, according to GIMP, the inner red has an alpha value of 227 (#e3) and the outer 170 (#aa)



Is this a bug or expected behavior?

I can work around this problem by using a different background alpha value. Don't know why though.

Code: Select all

convert -background '#ff00006c' -fill white -pointsize 72 -bordercolor '#ff0000aa' -border 40x20 label:"TEST" test2.png

Code: Select all

Version: ImageMagick 6.9.4-6 Q16 x86_64 2016-06-01 http://www.imagemagick.org
Features: Cipher DPC HDRI Modules OpenCL OpenMP 
Delegates (built-in): bzlib cairo fontconfig freetype gslib jng jp2 jpeg lcms lqr ltdl lzma openexr pangocairo png ps rsvg tiff webp wmf x xml zlib

Arch Linux

SOLUTION

But using -compose atop seems to fix the issue and produces the desired result:

Code: Select all

convert -background "#ff0000aa" -fill "#ffffffff" -pointsize 72 -alpha set -channel rgba label:"TEST" -compose atop -bordercolor "#ff0000aa" -border 40x20 test.png

Thanks!

[fmw42]

Looks like a bug to me. IM 6.9.5.0 Q16 Mac OSX snow leopard.

This works fine to put a semitransparent background to the label:

Code: Select all

convert -background "#ff0000aa" -fill "#ffffffff" -pointsize 72 -alpha set -channel rgba label:"TEST" test.png

Code: Select all

convert test.png -format "%[pixel:u.p{0,0}]\n" info:
srgba(255,0,0,0.666667)

But here, the label background part is now a different semi-transparent value from the border that has the desired semi-transparent value

Code: Select all

convert -background "#ff0000aa" -fill "#ffffffff" -pointsize 72 -alpha set -channel rgba label:"TEST" -alpha on -compose over -bordercolor "#ff0000aa" -border 40x20 test.png

Code: Select all

convert test.png -format "%[pixel:u.p{0,0}]\n" info:
srgba(255,0,0,0.666667)

Code: Select all

convert test.png -format "%[pixel:u.p{41,21}]\n" info:
srgba(100%,0%,0%,0.888884)

Note that -bordercolor .... -border ... should properly come after label:

Note also that I set the alpha values in all the hex color specifications (both the background and the fill)

I have also added, though it made no change, -alpha set, -channel rgba, -alpha on, and -compose over to be sure that alpha was enabled and the compose was reset.

[snibgo]

I don't think it's a bug.

The reason for the behaviour is that if we compose a semi-transparent pixel "over" a copy of itself, we get the same colour but reduced transparency (increased opacity). Experiments with sweet wrappers show this is expected behaviour.

[fmw42]

But -border, I thought, only added a border without affecting the inner area.

This also fails with -extent. So I guess you are right, but it is not intuitive.

Code: Select all

convert -background "#ff0000aa" -fill "#ffffffff" -pointsize 72 -alpha set -channel rgba label:"TEST" -alpha on -compose over -background "#ff0000aa" -extent 400x400 test.png

[snibgo]

See http://www.imagemagick.org/script/comma ... php#border

It generates an image of the appropriate size colors by the current -bordercolor before overlaying the original image in the center of this net image.

[fmw42]

OK, thanks. I see now. It is overlaying (using the default -compose over) one transparent image with another, so the alpha values get combined rather than replaced.

But using -compose atop seems to fix the issue and produces the desired result:

Code: Select all

convert -background "#ff0000aa" -fill "#ffffffff" -pointsize 72 -alpha set -channel rgba label:"TEST" -compose atop -bordercolor "#ff0000aa" -border 40x20 test.png