We've been dealing a lot with PNG and GIF files with transparent background being used as portrait, either internal or cover. And as of the moment of releasing v1.1 we couldn't find a way to go over it.

By digging into ImageMagick's documentation and googling everywhere over the net, we've discovered that it is a natural problem, not precisely a flaw, but an issue in ImageMagick.

And the problem is a collision with the transparency, either indexed (GIF, PNG at 256 colors) or by Alpha Channel (PNG at 24 bits). JPG and BMP files are not affected because they are opaque (i.e. they don't store transparency).

So, using the next example:

As you see here, the "apple" icon is set using the "Normal" style. This mode is lossless because the image is not composed over any other image. It is resized or distorted without touching the transparency.

But when we set the image to internal or cover portrait, the problem arises:

That's because, in order to compose the color of the folder, the folder body transparency is mapped, then, the transparency of the apple collides with it.

This also happens in translucent templates:

As you see here, the transparency of the folder is retained, while the transparency of the apple is discarded.

We're still trying to find a way to map the transparency of the images.
Until then, please try not to use this file types for crafting as portraits.

Tags:
png, gif, transparency, alpha, channel, issue, problem, composing, imagemagick