Well, among new features of imagick there is cropThumbnailImage. It’s not really that new but it might be undocumented for most of the parts.
- <?php
- /* Read the image */
- $im = new imagick( "test.png" );
- /* create the thumbnail */
- $im->cropThumbnailImage( 80, 80 );
- /* Write to a file */
- $im->writeImage( "th_80x80_test.png" );
- ?>
Let’s assume the source image in this example is 120×240. First it is scaled down to 80×160 and then cropped by the larger side (height in this case) from position x0,y40 to x80,y120. After this crop we have a fixed size 80×80 thumbnail.
#1 by phb on December 20, 2007 - 5:53 pm
Quote
With imagick module version => 2.0.1 (the debian etch package at the time of writing) I’m experiencing unexpected behaviour with cropThumbnailImage.
With a source image of 715×533:
$im = new Imagick(“source.jpg”);
$im->cropThumbnailImage(460, 345);
$im->writeImage(“dest.jpg”);
dest.jpg is written as 458×345 (desired is 460×345).
Obviously 715×533 and 460×345 have different aspect ratios, hence my use of cropThumbnailImage instead of thumbnailImage.
Am I doing something wrong?
#2 by Mikko Koppanen on December 20, 2007 - 5:55 pm
Quote
phb,
there was a bug in cropThumbnailImage which was fixed in the later versions.
#3 by phb on December 20, 2007 - 7:54 pm
Quote
Thanks for the quick reply Mikko.
I upgraded to imagick-beta with PECL but same results.
dev:~ {133} % php -i |grep magick
/etc/php5/cli/conf.d/imagick.ini,
imagick
imagick module => enabled
imagick module version => 2.1.0-rc1
imagick classes => Imagick, ImagickDraw, ImagickPixel, ImagickPixelIterator
ImageMagick version => ImageMagick 6.3.6 11/15/07 Q16 http://www.imagemagick.org
imagick.locale_fix => 0 => 0
This time I’m trying to resize a source image of 710×535 to 460×345 using the following code:
$im = new Imagick(“source.jpg”);
$im->cropThumbnailImage(460, 345);
$im->writeImage(“dest.jpg”);
But dest.jpg is 457×345.
Am I wrong in expecting this code to produce a 460×345 image?
#4 by Mikko Koppanen on December 20, 2007 - 7:58 pm
Quote
phb,
try: cvs -d :pserver:cvsread@cvs.php.net/repository checkout pecl/imagick && cd pecl/imagick && phpize && ./configure && make install
Still same results?
#5 by phb on December 20, 2007 - 8:20 pm
Quote
Mikko that works now
Thanks for your help!
#6 by phb on December 20, 2007 - 8:42 pm
Quote
Correction: that fixed it for the test-case mentioned above
But, using a source image of 700×352, I get an output image of 459×345 (using the same code as above). Is this correct behaviour?
#7 by Mikko Koppanen on December 20, 2007 - 9:13 pm
Quote
mikko@todellisuus:~/public_html$ php -r ‘$im = new Imagick(); $im->newImage( 700, 352, “white” ); $im->cropthumbnailImage( 460, 345 ); var_dump( $im->getImageGeometry() );’
array(2) {
["width"]=>
int(460)
["height"]=>
int(345)
}
It propably happens when a double is truncated to an int.
#8 by phb on December 20, 2007 - 10:15 pm
Quote
I tried that and got same results as you. Then I realised I’ve made a typo in my previous post – sorry! It’s 700×532 (not 700×352).
Now I tried your test again:
dev:~ {8} % php -r ‘$im = new Imagick(); $im->newImage( 700, 532, “white” ); $im->cropthumbnailImage( 460, 345 ); var_dump( $im->getImageGeometry() );’
array(2) {
["width"]=>
int(459)
["height"]=>
int(345)
}
#9 by Mikko Koppanen on December 20, 2007 - 10:58 pm
Quote
phb,
can you update to the latest CVS and try that with different dimensions?
#10 by phb on December 21, 2007 - 12:15 am
Quote
Mikko, perfect!
Thanks again for your fast help.
#11 by Will Prater on February 22, 2008 - 10:45 am
Quote
I am getting the same results. I have an input image of 70×73 and when I cropThumbnailImage(300, 300) the getImageGeometry() shows correctly, but the saved image is incorrect at 300×312.
I am running on the latest CVS build. Any ideas?
#12 by Benford on June 12, 2009 - 12:14 am
Quote
Great example code! I saw nothing much in the way of examples on this method’s php.net entry, so this was a great way to get started.
#13 by naveen on June 24, 2009 - 9:27 am
Quote
I am writing a tile cutter program. Basic code is below:
$imageWidth=3000;
$imageHeight=3000;
$tileWidth=256;
$tileHeight=256;
$img = new Imagick(‘test.png’);
for($y=0; $y<=$imageHeight; $y=$y+$tileHeight)
{
for($x=0;$xcropImage($tileWidth, $tileHeight, $x, $y);
$img->writeImage(“tile-$x-$y.png”);
}
}
After running it, it gives this error: “geometry does not contain image `/home/naveen/dev/imagick/thumb-0-0.png’ @ transform.c/CropImage/559″
It works only for first tile and then breaks.
I guess it has something with +repage (the command line parameter for convert tool). Is there any repage equivalent in php’s Imagick class? I tried setImagePage or setPage, but no luck.
#14 by naveen on June 24, 2009 - 9:31 am
Quote
Sorry for the last post , it has truncated code
I m posting the code part again:
$imageWidth=3000;
$imageHeight=3000;
$tileWidth=256;
$tileHeight=256;
$img = new Imagick(‘test.png’);
for($y=0; $y<=$imageHeight; $y=$y+$tileHeight){
for($x=0;$xcropImage($tileWidth, $tileHeight, $x, $y);
$img->writeImage(“tile-$x-$y.png”);
}
}
#15 by ovisopa on October 1, 2009 - 3:53 pm
Quote
I’m having the same problem with cropThumbnailImage
here is the code:
cropThumbnailImage( 257, 101 )
and here is the geometry result:
[geometry] => Array
(
[width] => 134
[height] => 101
)
What I have noticed so far, if the original image is in landscape aspect ratio the crop FAILS, but if the image is in portrait format the crop is done corectly.
imagick module version: 2.3.0
ImageMagick 6.4.1 09/24/08 Q16
any help will be appreciated.
Thank you
#16 by Kenny Meyers on October 5, 2009 - 11:07 pm
Quote
I seem to be experiencing some weird problems fiddling with resizing and cropThumbnailImage functions while working with an animated gif. The gif consists of 5 layers, each with different paging. When I try to resize I get very weird sizes and the images no longer matchup. This is after running a foreach loop through them. The resizeImage for example does stick to the height and width I pass it in a loop. Any help you could give would be much obliged. I think you’ve built a great library.
#17 by Kenny Meyers on October 5, 2009 - 11:08 pm
Quote
Sorry, I meant the resizeImage function doesn’t use the height and width I’m passing it on the second iteration of the loop.
#18 by No_limits51 on October 23, 2009 - 4:59 am
Quote
Even if there are less valued employees in the firm, the highly-valued ones will drive the choice of a health plan. ,
#19 by Koen on October 28, 2009 - 2:01 pm
Quote
I’m trying to cropthumbnailimage(400, 400) on a 800×600 image (JPEG). The result is an image of the following size: 400×300 while 400×400 is expected.
Does anyone know when this will be fixed?
#20 by Mikko Koppanen on October 28, 2009 - 2:01 pm
Quote
Koen,
can you try the trunk version?
#21 by Koen on October 28, 2009 - 2:14 pm
Quote
By the way, version used is: 1.0.2b2
Strangely enough phpinfo() tells me I’m using version 1.0.1-b1.
When looking in the source of php_gmagick.h (in the archive of version 1.0.2b2) it is has a line:
#define PHP_GMAGICK_VERSION “1.0.1-b1″
So I guess that’s probably why…
#22 by Koen on October 28, 2009 - 2:15 pm
Quote
Mikko, I’ll give that a try and let you know.
#23 by Koen on October 28, 2009 - 2:27 pm
Quote
Mikko, can you give me the path/address of the repository? Is it svn or cvs?
#24 by Dimmy on November 5, 2009 - 6:41 pm
Quote
I am getting a strange result also I want to crop an image from:
Width 3072
Height 2304
to:
Width 477
Height 320
I get :
Width 426
Height 320
I use :
magick module version 2.3.0
imagick classes Imagick, ImagickDraw, ImagickPixel, ImagickPixelIterator
ImageMagick version ImageMagick 6.5.6-7 2009-10-02 Q16 http://www.imagemagick.org
ImageMagick release date 2009-10-02
Is it a bug?
#25 by Dimmy on November 5, 2009 - 6:45 pm
Quote
Update:
when I use a image:
Width 640
Height 425
than the results are as expected:
to:
Width 477
Height 320
I get :
Width 477
Height 320
so maybe its the resolution of the big image?
Dimmy
#26 by Mikko Koppanen on November 5, 2009 - 6:47 pm
Quote
Hi Dimmy,
the algorithm was simply pretty random before 3.0.0. I pumped up to a new major version because the behavior changes for the edge cases to be more consistent
#27 by Dimmy on November 19, 2009 - 5:10 pm
Quote
Is there a linux build for version 3? I use centOS and use imagic 2.3.0 I did not see another version @ PECL (http://pecl.php.net/package/imagick)
Or maybe somone could give me a trunc I can use to compile one that has the fix in it?
Dimmy
#28 by Mikko Koppanen on November 19, 2009 - 5:19 pm
Quote
svn co http://svn.php.net/repository/pecl/imagick/trunk/ imagick-trunk
#29 by Dimmy on November 19, 2009 - 6:31 pm
Quote
MM i tryed to compile the files
that worked but now I get the folloing error when starting httpd in error_log:
PHP Warning: PHP Startup: Unable to load dynamic library ‘/usr/lib/php/modules/imagick.so’ – /usr/lib/php/modules/imagick.so: undefined symbol: Z_SET_REFCOUNT_P in Unknown on line 0
I use ImageMagick 6.5.6-7 2009-10-02 Q16
and PHP Version 5.2.9
Or do I need to have php3?
Pingback: Imagick blog » Blog Archive » Again some examples..cropThumbnailImage()
#30 by DES on February 18, 2011 - 5:22 am
Quote
car.gif is 982×487 image. Not animated.
$im = new Imagick(‘car.gif’);
$im->cropThumbnailImage(150, 100);
$im->writeImage(‘car_thumb.gif’);
But result is 201×100. Why?
Server on Windows:
apache 2.x,
php 5.2.x,
ImageMagick 6.6.5-0 2010-10-10 Q16,
imagick module version 2.2.1-dev