Resizing .gif with GD2 ...can it work?

script works fine for .jpg's

[mgm_03]

I've written a script that accepts image file uploads. I use the GD library along with ImageCreateTrueColor to re-sample the images to create thumbnails. All works fine when .jpg files are uploaded. With .gif files ....it bombs.

I know the patent has expired. I don't know if it has to do with support of .gif with GD 2 or my script...I usually think I'm the problem.

Any ideas are appreciated.

TIA

[DrDoc]

gd has been released with GIF write support. If you don't have it (or can't upgrade to it), well, then you have no choice but to write a different format... PNG, for example. You can still read GIF though.

[mgm_03]

ok....i was able to convert the .gif to png. however, the background of the thumbnail is now black.

is this supposed to happen with png files?

if the answer is in the manual ...I have not found it.

Thank you.

[Salsa]

As much as I love PHP, GD2 comes nowhere near as close to ImageMagick in terms of quality, compression, versatility and ease of use. All counts! I haven't run any benchmarks on speed, but it also seems considerably faster. Or maybe it just feels that way because the ease of use and results make me so happy. Certainly, vistor downloads of the resulting images is MUCH faster, and bandwidth much less. If you can install it on your server, I highly recommend it. My 5.5.7 version is so powerful that, I'm afraid to say, I haven't upgraded it for almost a year. (Marking that on my to-do list.)

So, mine doesn't have GIF support, but there was talk at the time that GIF support would be added last June, when it entered the public domain. I'm not current on whether that's actually happened, however. It was all ready to go, but it was just a legal issue at the time. (Come to think of it, even mine does have GIF support, but not it's all important compression features--so even a tiny, four color Imagick GIF had a much larger file size than a JPEG.)

There is a PHP API for it, but that also was not quite ready for a production environment last year. You can still issue commands from a PHP script however, and they are so simple and powerful that even when there is an API available, I'll probably stick with the commands. BTW, these commands don't have the limitations of exec(). you simply put a backticked command in a variable and then print it. By comparison, the API I saw looked relatively clumsy.

When I talk about simplicity, I mean that you can replace 10 lines of GD code and do the job with two lines of ImageMagick code (in a PHP script). As for image quality and compression, my JPEG file sizes average less than than 1/4 of those created by GD2, while the image quality is MUCH better. This improvement is even more pronounced for images with very contrasty details. I mean, a visitor can actually enjoy looking at them!

And, yes, you can convert to and from practically any image type, including PNG format with translucent backgrounds if you want. PNG support requires a separate library, however. I'm guessing that GIF support (with compression) is also available by now.

As for PNGs in general, personally, I like them. Their features and quality are superior to GIFs, but I rarely use them anymore except for when I want to make a favicon.ico. The reason is that they still are not as universally supported by web browsers as are GIFs and JPEGs. I've gotten reports from AOL (as recent as v9) clients, for example, that when they view a page with a PNG image, rather than the image being displayed they are prompted to download the PNG file. I'm guessing the MIME type isn't always set by default even in browsers that can support PNGs. Maybe somebody can tell me what else might be wrong here, but in the meantime I'm scared of them!

Well, now you know my prejudices. And, no, I have no professional association with ImageMagick. I'm just a fan.

I wish all well.

[baertyp]

Salsa,

thank you so much for helping me a lot in my decision whether to choose GD2, which would have meant an upgrade of PHP on my hosted server, or IMagick, which I installed in no time at all few days ago.

The only drawback with IMagick I saw so far is, that the main program "mogrify" doesn't allow to specify any filename for the output, but instead overwrites the original file. This means: copying before touching it, especially when creating thumbnails for a gallery. Any suggestions on that? And can you give an example for that "backticked print". I'm new to external program calls in PHP.

Regards
Markus

[Salsa]

Use convert. For making thumbnails (and practically everything else), I always use convert. Here's a very basic example;

$output = `convert -geometry $width -quality $quality $infile $outfile`; 
print $output;

The backtick that you asked about is that little thingy to the left of the 1 key, with the tilda above it. When you put your Imagick command into a variable, you have to quote it with backticks, not single or double quotes. Also, you have to print, not echo, $output. And, yes, this is all inside of PHP tags.

About the options I used above:

-geometry takes wxh in pixels for the $outfile. You can define by both width and height or either, but if you only use one, you don't have to worry about aspect ratio. The convert program takes care of that for you. So, -geometry 100 will make the thumb 100 wide. -geometry x100 will make it 100 high. No need to calculate anything about $infile--though I do when they have random aspect ratios and I want thumbs of equal area rather that equal height or width.

-quality takes a value from 0-100, the higher the better, but I usually set my default at 40, which is way better than anything I ever turned out with GD.

There are tons of other options for anything you want to do; crop, rotate by fractions of a degree, brightness, contrast, intensity, hue, gamma, normalize, sharpen, blur, mirror (flip)... And that's only the beginning--all with convert.

I hope this helps.

[baertyp]

Thanks so much. I didn't mind at the convert program, as "mogrify" is used in just about any example in the docs.

This looks really neat, I can't wait to see the results. Won't get back to coding until tomorrow...

Best regards
Markus

[Salsa]

Markus,

Let me know if you have any further questions. I won't be around much over the weekend, so here are a couple of tips to help you get off to a faster start. One is that if you haven't included relevant directories in your paths, include the path to the various directories in your command. To make my scripts easily portable from development to production machines, what I do is something like:

if (!isset($HTTP_ENV_VARS["WINDIR"])) { 
 define('IMAGICK_PATH','/usr/local/bin/'); 
 define('TMP_IMG_PATH','/usr/home/username/tmp/'); 
 ... 
 // define production paths first so that both conditions don't have to be parsed in production. 
} 
else { 
 define('IMAGICK_PATH','E:\\ImageMagick\\'); 
 define('TMP_IMG_PATH','C:\\Apache\\htdocs\\img\\tmp\\'); 
 ... 
}

Then your command looks like:

$output = IMAGICK_PATH."convert -geometry $width -quality $quality $infile $outfile"; 
print `$output`;

Note that you can't concatenate within the backticked command, so in this case I simply put the command string in $output and backticked `$output` in the print command.

Also, you'll find that the identify program is very useful:

if (file_exists(TMP_IMG_PATH.$tmp_display_file)) { 
 $image = TMP_IMG_PATH.$tmp_display_file; 
 $id_image = IMAGICK_PATH."identify -verbose $image"; 
 $id_string = `$id_image`; 
 ... 
}

$id_string will then give you a wealth of information about the $image. If you...

?><pre><? print $id_string;?></pre><?

You'll get something like this on your local machine:

Image: C:\Apache\htdocs\img\tmp\110029077541951ad78070c.jpg 
 Format: JPEG (Joint Photographic Experts Group JFIF format) 
 Geometry: 240x320 
 Class: DirectClass 
 Type: true color 
 Depth: 8 bits-per-pixel component 
 Colors: 10184 
 Resolution: 72x72 pixels/inch 
 Filesize: 4.6kb 
 Interlace: None 
 Background Color: grey100 
 Border Color: #DFDFDF 
 Matte Color: grey74 
 Dispose: Undefined 
 Iterations: 0 
 Compression: JPEG 
 signature: ae77b6fb06cbc5b650c83600154ae33bfa1bd609669dd9448841fdbf9a9072ea 
 Tainted: False 
 User Time: 0.010u 
 Elapsed Time: 0:01

You can then parse through $id_string to find whatever info you need about the file--including whether it's even an image file--before proceeding. One of the very cool things about Imagick is that it does not depend at all on a file's extension to determine what kind of file it is--and you don't have to tell it what kind of file it is, either. You can make an image called some.jpg, rename it some.php, and you will not fool Imagick into believing that it's a PHP file. It will treat it as what it really is. This is also an aid to security because, with simple controls, you can easily prevent anyone from uploading a tainted or faux image file. Also, when creating an $outfile, there's no need to do any verbose telling to the program of what type of file you want to create. Simply name the $outfile with the appropriate image extension, and that's the kind of image it will make--so no need to choose between one of a zillion functions, like imagecreatefromjpeg() imagecreatefromgif() imagecreatetruecolor()....

Okay. I'll step down from my soap box now.

Good luck with it this weekend,
Salsa

PS: You will absolutely love the results. It's only unfortunate that you won't be able to compare it, first hand, with the results of GD. (Now, really stepping down from my soap box.)