php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Doc Bug #21834 First call to imagecolorallocate() assigns background
Submitted: 2003-01-22 22:58 UTC Modified: 2003-07-02 06:47 UTC
From: Brendan at callaghans dot com dot au Assigned:
Status: Closed Package: Documentation problem
PHP Version: 4.3.0 OS: Win2k
Private report: No CVE-ID: None
View Developer Edit
 [2003-01-22 22:58 UTC] Brendan at callaghans dot com dot au 
I discovered from experimentation that the first call to imagecolorallocate() for a given image, sets the background colour for that image.

This would be worth noting in the manual page for imagecolorallocate().  Someone has pointed it out in a user comment, but it is a fairly important aspect of the function's behaviour, and IMO should be part of the official documentation.

I'm using php_gd2 as bundled with PHP 4.3.0, and I've only tried PNG images so far.  I can't say for sure if imagecolorallocate() exhibits this same behaviour for other image types.

As an aside, the GD functionality is great.  I'm loving the idea of creating dynamic images in my app.

May the Force be with you.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-01-22 23:09 UTC] philip@php.net 
This will need some study and confirmation.  For example here is one user comment:

"With gd 2.x, the first color allocated with imagecolorallocate() appears to no longer be made the background color. You can use imagefill() to set the background color."

Granted whatever behavior exists needs to be documented ... but what is the exact behavior?  Please report further findings in this bug report :)
 [2003-01-22 23:15 UTC] Brendan at callaghans dot com dot au 
Sure thing.  Later today I'll investigate different image types, and post the results here.

I'll also see if things are different with imagecreatetruecolor() (I suspect they will be).
 [2003-01-23 23:56 UTC] Brendan at callaghans dot com dot au 
I am only able to test JPG and PNG with my setup.

I suspect that what's happening is quite straightforward - when you first create an instance of an image with imagecreate, it builds a blank palette.  Each time you call imagecolorallocate(), it adds an index to the palette with the specified colour.  So, you could think of color allocation as

 $im->palette[] = array($r,$g,$b,$a); // a for alpha

As it just so happens, paletted images assume that palette index zero ($palette[0]) is actually the background colour.

I've been extracting the palette into a useful form using this code:

 $cols = imagecolorstotal($im);
 for($i=0;$i<$cols;$i++){
  $palette[$i] = imagecolorsforindex($im,$i);
 }

And running different sequences of colour allocations, then checking the contents of $palette to see the results.

If you use imagecolorset() with the index 0, even after allocating multiple colours, the background colour changes to whatever you specify.

Got an unexpected result testing out imagecreatefrompng().  I opened a png file of mine, and imagecolorstotal() came up 0.  Curious.  There are certainly multiple colours within the image.  Perhaps it just doesn't have a palette saved with it (does that make it a true colour image?)

That's all I have for you atm.  More later as I discover it.
 [2003-07-02 06:47 UTC] pajoye@php.net 
The first call to imagecolorallocate() for a given image sets the background color only for palette based image. Palette based image are created using imagecreate().

For truecolor image (imagecreatetruecolor), you have to fill the image using imagefill.

imagecreatefrompng does not create always a truecolor image, you may use imageistruecolor to know that.

thank's for your report,

pierre
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Sat Jul 19 23:00:03 2025 UTC