Code: Select all
convert -rotate 0.1 input.jpg output.jpg
The CPU usage of convert is 1%...2% during process. Why? How I can speed this up?
Code: Select all
convert flat.png -rotate 0.1 flat.jpgI think this depends on the cleverness and the algorithms of the programm. Today I am here on a Window system (Dektop PC with 3 GHz). For example IrfanView needs 0.9 s (874 milliseconds) to load and show this image! (Rotating: 14 s, Saving 4 s)fmw42 wrote:You file is a compressed PNG of size 540 KBytes. But when read in and decompressed it goes to 12,000 x 9,000 x4(channels rgba) = 432 MBytes It took minutes to even open in Mac PREVIEW and GraphicConverter for me.
which should half your memory use to hold the image data.For a single operation (like rotate) a Q8 version of IM will work just fine, though if you add 'colorspace corrections' then you may be better off using Q16 anyway due to subtle value changes, that you want to preserve in Q16 (why else would you be doing colorspace corrections otherwise!)The higher the Quality Setting, used when compiling IM, the more precise the color values used to store the image in memory. That means that if in processing an image you generate a lot of very small, slight variations in color, then those variations will be preserved in the in-memory storage of ImageMagick, and not lost in later processing steps.
I need a tool, that can be automated. Many people advised me ImageMagic. But this tool seems a little bit restricted (my problem with huge images).magick wrote:Our opinion has always been-- if another package solves your problem better or faster than ImageMagick, use it. No one program can suitably solve all problems.
Just curious, Magick, did you try timing your large test image for the odd size rotations with -distort SRT with and without -filter point and compare to -rotate?magick wrote:We have a benchmark for ImageMagick vs. PIL and for the basics-- convert, rotate, transpose, resize, convolve, etc., the execution time is comparable. We reran the benchmark with a 12000x9000 pixel JPEG image and the execution time for both were within about 2%. Rotate was for 0, 90, 180, etc. True, odd sized rotations are dog slow for large images with ImageMagick.
Thanks. I did understand all that. My question really pertained to whether using -distort SRT, which does not use the Paeth multipath approach, would be significantly faster so as to be helpful to the person who started the topic. Anthony had suggested earlier in this topic that -distort SRT as a one pass approach might be faster in this situation, and I would expect especially if EWA was turned off with -filter point.magick wrote:Our benchmarks are not comprehensive. Just a few to see if ImageMagick was outside the performance norm as compared to PIL. Its not-- except for non-integral rotation which as mentioned uses the 3 pass Paeth shearing algorithm which has been proven to be slow when image pixels are cached to disk. Smaller images, such as the standard HDTV image format of 1920x1080 rotates in a reasonable time. The cause is that non-intergral rotation does not read from disk sequentially and random disk access is very slow as compared to memory. PIL holds as much of the image in memory (including swap) to take advantage of the fast swapping algorithms handled by the kernel. The problem with that is, as the images got large (24000x18000, 48000x32000, etc), PIL consumed all the available memory and swap, the system thrashed, became unresponsive, and eventually the PIL slowed to a crawl and the system halted. ImageMagick handled the large images gracefully by caching the image pixels to disk rather than memory as expected. Other applications could run fine because it only needed 254MB of memory whereas for one case, PIL consumed 13GB of memory / swap. Each program has its advantages and disadvantages, each is useful depending on the requirements of the problem.
OK. Thanks for the clarification.magick wrote:No it won't be faster because it still accesses pixels in a non-sequential manner and random access to disk is much slower than sequential access. Again if the image fits in memory, this random access is less problematic since memory access is 1000+ times faster than disk access.
