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]
GIF Cropping issues. (Wierdly not resizing)
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 )
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 )