Edit report at https://bugs.php.net/bug.php?id=55034&edit=1
ID: 55034
Comment by: php at heavyconsulting dot net
Reported by: php at mrphlip dot com
Summary: ImageCopyResampled doesn't calculate colours
properly with alpha
Status: Open
Type: Bug
Package: GD related
Operating System: Ubuntu Natty
PHP Version: 5.3.6
Block user comment: N
Private report: N
New Comment:
After some more research I found a solution that fixed this issue for me.
Using instructions found on http://drupal.org/node/878778 i was able to build a
new php5-gd deb-package on a new virtual machine I installed with the same
version of debian that my server uses.
Then I could simply copy the new deb-file to the server and install it.
I now have the bundled GD with all the missing functions and it handles
alpha/colours correctly when using ImageCopyResampled, so I am now happy.
In other words, this is not a bug with PHP. It is a bug with the original shared
GD-library, and it has been fixed in the PHP-bundled GD-library, but not all
distributions use that version.
Previous Comments:
------------------------------------------------------------------------
[2012-04-21 12:54:16] php at heavyconsulting dot net
I did some more research, and the difference is due to different GD-libraries.
The Debian/Ubuntu PHP-packages uses the original GD-library, while CentOS uses
PHPs "bundled" GD-library.
The original library is missing a lot of fixes and functions that the PHP-variant
have. According to some Debian people, we can expect them to use the bundled
library sometime around when "hell freezes over", or when the PHP-team pushes
their changes and improvements to the main GD-library.
So, in other words, this is probably not a bug.
------------------------------------------------------------------------
[2012-04-21 11:59:13] php at heavyconsulting dot net
I have this problem on a new server running
Debian Squeeze with php5-gd 5.3.3-7+squeeze8.
I do not have this problem on my older server
running CentOS with php-gd-5.1.6-24.el5_4.5.
The test-script produces the expected result on the old CentOS server, and the wrong result on the
new Debian server.
My application uses imagecopyresampled to rescale and place simple white images with alpha channel
on top of a background image.
This works great on the old server, but on the new one it results in a black border around the edge
of the white graphic.
------------------------------------------------------------------------
[2011-06-13 06:38:18] php at mrphlip dot com
Hmm... I've just tried this on a different machine, and it works correctly there.
I notice that the two machines link to GD differently... on my machine (where the bug happens), I
don't have ImageAntiAlias, but on the other machine (where it works), I do... which I know is
related to how GD is compiled. I'm not sure whether this is related, but I figure more
information can't hurt.
------------------------------------------------------------------------
[2011-06-11 15:53:31] php at mrphlip dot com
Changed summary to be more accurate... it calculates the alpha fine, it's the colours it
doesn't calculate correctly in the presence of an alpha channel.
------------------------------------------------------------------------
[2011-06-11 15:48:17] php at mrphlip dot com
Description:
------------
It appears that ImageCopyResampled uses a naive averaging, which isn't correct when there is an
alpha channel involved. It should instead use a weighted average for the colour channel, weighting
each input pixel according to its opacity (so a more opaque input pixel has more weight in the
average).
This comes up particularly if you have eg a solid white shape against a solid black-but-transparent
background. The original image, every pixel is either white or transparent. But shrink it down, and
the object will have a thin dark halo around the edge, because of averaging those black pixels into
the result. The expected result would fade from full opacity white, to half opacity white, to
transparent any-colour... but the actual result fades from full opacity white, to half opacity
*grey*, to transparent black.
Test script:
---------------
# create an image with an almost-transparent white pixel and an almost-opaque black pixel
$img1 = ImageCreateTrueColor(2, 1);
ImageAlphaBlending($img1, FALSE);
ImageSetPixel($img1, 0, 0, ImageColorAllocateAlpha($img1, 255, 255, 255, 0x70));
ImageSetPixel($img1, 1, 0, ImageColorAllocateAlpha($img1, 0, 0, 0, 0x10));
# scale the image down to a single pixel - make it mix the two together
$img2 = ImageCreateTrueColor(1, 1);
ImageAlphaBlending($img2, FALSE);
ImageCopyResampled($img2, $img1, 0, 0, 0, 0, 1, 1, 2, 1);
# find out what colour the resulting pixel is
$col = ImageColorAt($img2, 0, 0);
print "R: " . (($col >> 16) & 0xFF) . "<br>";
print "G: " . (($col >> 8) & 0xFF) . "<br>";
print "B: " . ($col & 0xFF) . "<br>";
print "A: " . (($col >> 24) & 0xFF) . "<br>";
# clean up
ImageDestroy($img1);
ImageDestroy($img2);
Expected result:
----------------
R: 30
G: 30
B: 30
A: 64
Each of the colour channels has been weighted in the average... the almost-transparent white pixel
with a weight of 0xF (0x7F - 0x70), and the almost-opaque black pixel with a weight of 0x6F (0x7F -
0x10), giving a weighted average of (255 * 0xF + 0 * 0x6F) / (0xF + 0x6F) == 30. The alpha channel
is averaged in the normal way.
Actual result:
--------------
R: 127
G: 127
B: 127
A: 64
Each channel has been averaged separately, with no regard for the alpha channel.
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=55034&edit=1