Page 1 of 1
Posted: 2006-03-20T13:12:17-07:00
by magick
Your process is probably not hanging, instead its probably just taking a real long time to complete. Add -monitor to your command line to monitor the progress of the image rotation operation.
Posted: 2006-03-20T14:11:37-07:00
by magick
Ok, post a URL so we can attempt to reproduce the problem.
Posted: 2006-03-20T14:51:17-07:00
by magick
Your image is being cached to disk which is dog slow compared to in-memory rotation. Add -debug cache to your command line to track progress.
Posted: 2006-03-20T19:15:22-07:00
by magick
You would probably would have better luck with the Q8 version of ImageMagick if you are not already using it. It uses 50% less memory than the Q16 version.
We tried your command under Fedora Core 5 on a 1GB machine with ImageMagick 6.2.6-5 Q16 and it created a 2811x2811 rotated image in 17 seconds of wall clock time. It appears our 1GB Windows XP machine is rejecting our demand for pixel cache memory where Linux is not for the same image and mogrify command.
Posted: 2006-03-21T14:34:56-07:00
by magick
Not a bug, but there is room to improve the algorithm. It appears for 45 degrees we are over allocating the initial rotated image size before it is cropped to the final size. We could speed up the rotation a bit by attending to this enhancement. We'll add it to the list of things to do.
Posted: 2006-03-21T17:02:34-07:00
by magick
The Paeth article is available in one of the Graphics Gems books (there are 5 in all).
Posted: 2006-03-22T12:11:10-07:00
by magick
We'd certainly like to hear from you if you come up with a solution to the speed problem. We designed ImageMagick to be general purpose so we had to trade-off certain optimizations to ensure support for the greatest number of image formats, colorspaces, storage classes, etc.