GIF Cropping issues. (Wierdly not resizing)

MagickWand for PHP is an object-oriented PHP interface to ImageMagick. Use this forum to discuss, make suggestions about, or report bugs concerning MagickWand for PHP.
Post Reply
monsters

GIF Cropping issues. (Wierdly not resizing)

Post by monsters »

Copied from my blog for posterities sake, go there if you want to see the images.

http://bigmojo.net/monsters/?p=37

---------------------------
So, I have some magickwand code which crops images, all seemed well.

Then it’s pointed out that GIF files are not cropping properly, an investigation shows serious wierdness with them.

Eventually I discover that the are in fact being cropped, but some metadata about their size is not being updated..

The symptoms here were that the image looked fine in my imageviewer (irfanview) , but in a browser (including the windows explorer thumbnail view) they were showing as their orriginal pre-cropped size as transparent, and the newly cropped image visible..

see below (click for larger versions)

Here’s the original Image

And here is the perplexing ‘cropped’ image, you can see that the crop worked, but for some reason it is layered on the original image resolution..

The windows file properties show the file as 486*563, the original size… but opening in irfanview shows the image as 275*160, the cropped size. Clearly there is some metadata in a GIF that defines the size, which some applications (browsers) care about and others (irfanview) do not.. so on to find that.

A trip to imagemagicks identify command was equally confusing, here it shows us the ‘correct’ cropped resolution
identify -format “%@” orig.gif
223×438+0+0

But after some experimenting , I found
identify -format “%g” orig.gif
486×563+0+0

This was the original and now ‘incorrect’ size, so I had at least located the data. Apparently GIF stores ‘page geometry’ data, surprise !

So I found the method in magickwand to deal with this

MagickBooleanType MagickSetPage(MagickWand *wand,
const unsigned long width,const unsigned long height,const long x,
const long y)

Putting that in place unfortunately solved nothing, and the identify %g still showed the wrong data.. my love affair with magickwand ended a long time ago, so this was not well received.

This is where we enter the great, and terrible things about open source:
1. Documentation is often wrong, outdated, or totally absent
2. You can find the source code and just look at that

So as has been the case many times with MagickWand, I found the code and had a look, turns out there is a method called MagickSetImagePage in ImageMagick (not MagickWand) , so I figure I’d try it out. Sure enough that method works fine, and does exactly what I want see here:

MagickBooleanType MagickSetImagePage(MagickWand *wand,
const unsigned long width,const unsigned long height,const long x,
const long y)

Issue resolved, and here see the cropped image in all it’s proper glory.

Here’s the code that generates these files

$current_file = 'orig.gif';
$sourceWand = NewMagickWand();
MagickReadImage($sourceWand,$current_file);

$cropwand = CloneMagickWand($sourceWand);
MagickCropImage( $cropwand, 275,160,90,200);

magickWriteImage($cropwand,"bad.gif");
MagickSetImagePage( $cropwand,275,160,0,0);
magickWriteImage($cropwand,"good.gif");

DestroyMagickWand($sourceWand);

?>[img][/img]
aditan22

Post by aditan22 »

it's a good article...
yeah, when we crop a gif image, we should care about the imagepage too... and sadly it's not well documented. Another useful function which is friend of MagetSetImagePage is MagickGetImagePage, using this function you can get the imagepage info of an image. (I know it from this forum too :) )
Post Reply