A few thing are true about this topic. First, you can draw (make images) with PHP. Second, only a sadist would try to replace a Photoshop-like tool with any programming interface to a drawing tool. Third, the GD image library for drawing in PHP has many drawbacks.

Those drawbacks are pretty significant, though some of them are certainly a matter of opinion. Among them, I’d list:

• The PHP GD library is completely procedural. You have no nice image object with a fluent interface or anything like that. You work with it by creating your $image and passing that variable into every function you then use related to that image.
• The function names are illegible. Seriously, they’re the much derided PHP standard library at its worst. imagecolorallocate(), imagefilledrectangle(), etc. They’re multiple words long, but neither camelCased nor snaked_case, so we’re just left with a hunk of letters jammed together. Looking closely you can tell them apart, but they’re hardly well named.
• The parameters aren’t obvious. This hardly seems a valid complaint from someone who advocates for the use of WordPress. And I don’t have a wealth of experience with programmatic drawing library to make it clear that this abnormal. But I’d rather pass in an array of named parameters than have to go look up every value every function every time I want to make a change. (Admitted, this is also a PHP limitation, without arrays named parameters aren’t something you can do in PHP today.)

Those complaints voiced, however, using GD has some significant advantages. Well, one. Which is that it’s there by default out of the box, so you can feel pretty certain that even a shared hosting environment will let you access it. ImageMagick (and other available drawing extensions) is better known, and a better option overall, but in a quick survey of the type of hosts my project was likely to end up on only two out of three had the ImageMagick PHP extensions running. And given that I had no say in the hosting environment, GD it was.

Let’s do some drawing!

As I said, other than practicality and universality there isn’t all that much to make GD a good choice for drawing. If other languages or other libraries are available to you, I’d say use them. But you can pretty quickly draw some shapes with GD, and that’s powerful in itself. Here’s an example GD script we’ll talk though:

header('Content-type:image/png');
$image = imagecreate(300, 150); // (x, y)
$background = imagecolorallocate($image, 244, 244, 244);
$black = imagecolorallocate($image, 15, 15, 15);
imagefilledrectangle($image, 0, 65, 300, 85, $black);
imagepng($image);

I think you may see what I mean about the ugliness of this code, but it does its job. Basically, you create an image, and you pass that into every function that will do things that will have an effect on it. Colors are created on the image and then used, shapes are drawn, etc.

A drawing even a mother probably wouldn’t love.

So the first two lines are pretty simple: it creates the image. We set a header for the page so the browser you see it in interprets our picture correctly. With the next line, we create our “canvas” for the image. As the comment notes, you just pass in the x and y dimensions of your image in pixels and you’re on your way.

But you’ll notice a couple of the lumps that makes me so harsh on GD as well. For one, we call the imagecolorallocate() function twice and we get two different behaviors. If you’re keeping score you’ll notice that the script above assigns something to the variable $background but doesn’t access it. That’s not because we use it in line I’m not showing you, it’s because your first call to imagecolorallocate determines the background color of your image.

The next call to the function and all subsequent ones (assuming you’re passing around the same image resource) will just create free colors that you can pass back into your drawing as colors. I didn’t note it before but you may have guessed: the second, third, and fourth parameters of imagecolorallocate() are the color’s red, green, and blue values.

We’re using the color — a not quite pure shade of black — to draw a rectangle in the fourth line. For a rectangle, you’ll sanely (though not obviously) specify it by naming two opposing corners in an x1, y1, x2, y2 format. As you may be able to picture, this is a rectangle through the middle of our image, which goes all the way to the horizontal edges. The final parameter of the imagefilledrectangle call is the color, in our case we’re using the “black” we just defined.

Finally, the last line we’re telling PHP to display our image resource as a PNG to match our header. With proper header and different commands you can create GIFs and JPEGs with GD as well, but given the simple shape and my preferences, I chose a PNG.

What Else?

As I’ve said, I don’t really think I’d recommend GD for much drawing. It’s usable, and does work, but those are kind of the minimum goals for any code I’m going to use. I think the ImageMagick PHP extension is available enough even among most shared hosting providers on the internet that there aren’t many times you should use GD when you need to draw in PHP. This was just about the simplest drawing we’d hope to do, and it was still full of ugliness that comes from GD.

Because I’ve mostly wasted your time, describing a solution I’d discourage you from unless you need completely global compatibility with your PHP drawing script, let me recommend this piece from JackMeme, an image macro service, about what the creator learned when trying to make “memes” with PHP. It’s far more detailed about what the advantages of ImageMagick are, and plus MEMES! The takeaway for me:

Image Magick is much, much easier to work. It took me hours before I stumbled upon John Ciacia’s stroke function for GD text, but for IM, you can do it out of the box. I was happy, I was ecstatic…