Legacy ImageMagick Discussions Archive

Initialy I was using the 6.6.9-1 HDRI manually compiled version then I noticed a new version ( 6.6.9-4) compiled with VS 2005 ...

If I call : convert -version I get this :
Version: ImageMagick 6.6.9-4 2011-04-01 Q64 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2011 ImageMagick Studio LLC
Features: HDRI

( I suppose I can say it compiled OK... )

If try something like :
convert dsc1860b.jpg -resize 200%x200% dsc1860z.jpg
I get a 20Kb jpg ...

The identify command in the resulting image gives me :

D:\ImageMagick-source\VisualMagick\bin>identify dsc1860z.jpg
dsc1860z.jpg JPEG 2576x1978 2576x1978+0+0 8-bit PseudoClass 256c 20.1KB 0.000u 0:00.031

If I try to open the original image I get :
D:\ImageMagick-source\VisualMagick\bin>identify dsc1860b.jpg
dsc1860b.jpg JPEG 1288x989 1288x989+0+0 8-bit PseudoClass 256c 176KB 0.047u 0:00.077

So the resize operation did calculated the correct dimensions ...
But where is the image per se ?

Sometimes it freezes ( at least it appears that the convert process is frozen ...) with this picture

CIMG5515.JPG JPEG 2560x1920 2560x1920+0+0 8-bit DirectClass 1.796MB 0.000u 0:00.031

Same behaviour with -adaptive-resize 200% ...

[Update] With this image it took about 3 hours to resize
D:\ImageMagick-source\VisualMagick\bin>convert oldf069.jpg -resize 200% o069.jpg
D:\ImageMagick-source\VisualMagick\bin>identify oldf069.jpg
oldf069.jpg JPEG 2682x1851 2682x1851+0+0 8-bit DirectClass 917KB 0.266u 0:00.296
[/update]




[update 2]
Using : convert -verbose -monitor I get to section that
...
Load image[sdim0207.ppm]: 1791 of 1792, 100% complete
sdim0207.ppm PPM 2688x1792 2688x1792+0+0 16-bit DirectClass 28.9MB 0.844u 0:03.359
Resize image[sdim0207.ppm]: 8 of 8960, 00% complete
...

The first part is fast ... about 1 minute ...
But the second part takes about half minute between each number ( last 8960 ? ) ...

What could be wrong with the "Resize" operation to take so much time ?


[/update 2]

After some tests I get two problems:
If call -sample or -scale or even adaptative-resize it works reasonably fast ...
Calling with -resize I get several hours ( 2 -3 hours ) for a 2560x1920 JPG to double its size (?) ...

together with the previous "problem" if I call the "-debug cache" option I noticed the increase in memory allocated ( double as supposed to be) but do not know where is going the file ( RAM or temporary file ) ?

I get this :
2011-04-12T18:01:48+01:00 0:59.922 12.094u 6.6.9 Cache convert[4284]: cache.c/ReadPixelCachePixels/4780/Cache
sdim0207.ppm[0][5376x1+0+3430]
2011-04-12T18:01:48+01:00 1:00.157 12.203u 6.6.9 Cache convert[4284]: cache.c/ReadPixelCachePixels/4780/Cache
sdim0207.ppm[0][5376x1+0+3465]
2011-04-12T18:01:48+01:00 1:00.391 12.266u 6.6.9 Cache convert[4284]: cache.c/ReadPixelCachePixels/4780/Cache
sdim0207.ppm[0][5376x1+0+3500]
2011-04-12T18:01:49+01:00 1:00.626 12.281u 6.6.9 Cache convert[4284]: cache.c/ReadPixelCachePixels/4780/Cache
sdim0207.ppm[0][5376x1+0+3535]
2011-04-12T18:01:49+01:00 1:00.860 12.375u 6.6.9 Cache convert[4284]: cache.c/ReadPixelCachePixels/4780/Cache
sdim0207.ppm[0][5376x1+0+3570]
2011-04-12T18:01:49+01:00 1:00.922 12.375u 6.6.9 Cache convert[4284]: cache.c/ReadPixelCachePixels/4780/Cache
sdim0207.ppm[0][5376x1+0+3583]

I know that I called the -debug cache but what does it mean ?

Any comments ?

Resize requires a two pass algorithm, that requires a intermediate image to be created during processing.

input -> resize_horizontal -> resize_vertical

At some point all three images are in memory. The Middle image is destroyed when the resize is complete, but the input image is kept until the operation library call is finished. The library operator does not delete the input image as it does not know if the caller still wants the original image or not. As such it is up left for the caller to destroy. Now while the command line (CLI API) doesn't want the input image when the resize is finished, other API's (wand, perl, etc) may still want the original.

One alternative is to use the NEW -distort Resize "WxH"
This uses a single pass though slower method, so only two copies of the image will be needed (input and result) during processing. However the method does produce slightly different results, whcih for some filters is actually better.

See http://www.imagemagick.org/Usage/distorts/#resize
For comparison of results See http://www.imagemagick.org/Usage/resize/#distort

Other operators that may require an intermediate image include -blur (which is two-pass) and multi-kernel or higher level -morphology methods.

markmarques wrote:After some tests I get two problems:
If call -sample or -scale or even adaptative-resize it works reasonably fast ...
Calling with -resize I get several hours ( 2 -3 hours ) for a 2560x1920 JPG to double its size (?)

Your computer must be very memory deficit if it can not handle a image that size.
Perhaps you need a Q8 version of imagemagick. That will work fine when not doing highly mathematical image handling.

Another alternative, divide the image into tiles, and resize each smaller tile!

After some more "ImageMagick Docs" reading I noticed that calling "-resize" option defaults to the "Mitchell" filter ...

I forgot to mention that my system is a modest Laptop ( E5600 with 1Gb of RAM) and windows XP ...
So I realize now that Imagemagick does it at its best ...

Although I got this strange related problem :
Even if specify the "-filter box -resize 200%" this image :

CIMG5515.JPG JPEG 2560x1920 2560x1920+0+0 8-bit DirectClass 1.796MB 0.000u 0:00.062

takes about 1 hour to resize (?) no matter the filter I choose ....
By using the -monitor option I can check in which "row" it is working but I get an increase 1 each minute (?)

Nonetheless I noticed that "convert" simply crashes ( no warning) if it can not create the temporary file ( verified by trial and error ) ...

Any comments ?

I recommend you compile/download a Q8 version of IM

and use -distort Resize to avoid the extra in-memory image copy.

After the previous indication I have compiled ImageMagick with Q32
and almost all problems regarding speed have disappeared ...

The problem were also masking the problem related in :
viewtopic.php?f=3&t=18526

Thanks for the fast response...