Page 1 of 3
optimizing 'convert' speed
Posted: 2011-06-01T12:56:38-07:00
by jgrauman
Hello,
I need to perform the following operation thousands of times, and so want to know if there is any way I can speed it up. Is this operation multi-threaded? Any compile settings that will help significantly? Other tricks/tips? Thanks!
convert image1.tga -rotate 1.2 -crop '1000x1000+20+20' -scale 640x480\! image2.tga
Josh
Re: optimizing 'convert' speed
Posted: 2011-06-01T13:08:21-07:00
by fmw42
what version of IM are you using and what platform? is OpenMP enabled? Do you have multiprocessors?
convert -version
what does it tell you. Does it show Features: OpenMP?
If you are using Q16 IM, then you could recompile as Q8 and get some speedup.
If all your commands and arguments are the same, you might try doing multiple images in a given directory using mogrify rather than convert, thought I don't know if it will be faster, but it will be easier. For every image in the directory you CD to, you will get one output image per input image. You can change formats if you want (see -format) and specify only certain formats are processed. But as far as I know, it will not traverse directories. My recommendation is to create a new directory to hold the output images so you don't walk over the input images. You can delete them later if you want. (see -path).
see
http://www.imagemagick.org/Usage/basics/#mogrify
Re: optimizing 'convert' speed
Posted: 2011-06-01T13:12:46-07:00
by jgrauman
I had just downloaded and installed latest IM. Here is my version...
Version: ImageMagick 6.7.0-2 2011-06-01 Q16
http://www.imagemagick.org
Copyright: Copyright (C) 1999-2011 ImageMagick Studio LLC
Features: OpenMP
What is Q16 and Q8 IM?
I'm on Linux and have multiple cores (just ordered a 4-core CPU to replace my 2-core one).
Re: optimizing 'convert' speed
Posted: 2011-06-01T13:14:43-07:00
by fmw42
I am not an expert on speed issues. But you can recompile as Q8 and get some speed up, but I don't know how much. You can also try processing using mogrify.
You have OpenPM enabled so it you have multiprocessors, IM should utilize them. Though I don't know which command per se are OpenMP compatible. But I believe most are to one degree or another.
IM compiles in 16 bit mode (Q16) or 8-bit mode (Q8). Depends upon how you install. If you download a binary, then you have to find the Q8 binary. If you install from source, you can set the mode in you .configure file. use --with-quantum-depth=16 or --with-quantum-depth=8
More information will need to come from the IM developers. That is the limit of my understanding.
see also
http://www.imagemagick.org/script/advan ... lation.php
"--with-quantum-depth
...
Larger pixel quantums can cause ImageMagick to run more slowly and to require more memory. For example, using sixteen-bit pixel quantums can cause ImageMagick to run 15% to 50% slower (and take twice as much memory) than when it is built to support eight-bit pixel quantums. "
Re: optimizing 'convert' speed
Posted: 2011-06-01T13:21:30-07:00
by jgrauman
Thanks, I'm recompiling as Q8. OpenMP compiled in as well. We'll see how much that helps. If anyone knows any other tricks, please let me know. Thanks!
Re: optimizing 'convert' speed
Posted: 2011-06-01T13:24:38-07:00
by fmw42
try mogrify also if that makes sense for your situation
Re: optimizing 'convert' speed
Posted: 2011-06-01T15:50:53-07:00
by jgrauman
mogrify and convert ended up taking the same amount of time...
Re: optimizing 'convert' speed
Posted: 2011-06-01T16:49:39-07:00
by fmw42
jgrauman wrote:mogrify and convert ended up taking the same amount of time...
Thanks for that information. I was not sure
Re: optimizing 'convert' speed
Posted: 2011-06-01T16:53:59-07:00
by fmw42
You could try combining the rotation and scaling and possibly even the cropping via -distort SRT (using a viewport crop). see
http://www.imagemagick.org/Usage/distorts/ and use the fastest -filter point or box setting up the -distort resampling method.
see
http://www.imagemagick.org/Usage/distor ... t_viewport
http://www.imagemagick.org/Usage/distor ... tort_scale
http://www.imagemagick.org/Usage/distorts/#srt
http://www.imagemagick.org/Usage/distorts/#distort_ewa
I have never tried your combination, so am not sure how much you can combine. Perhaps Anthony will have some ideas or comments. At least you could combine the rotation and scaling and then figure out a new crop at the end.
Re: optimizing 'convert' speed
Posted: 2011-06-01T22:29:58-07:00
by anthony
If the number of images does nto blow out your memory, you can also generate M variations of the same image using the latest IM and the use of image index to modify the distortion...
for an example see IM Examples, Animation Modifications, Animated distorts
http://www.imagemagick.org/Usage/anim_mods/#distort
If you can't do all the images due to memory limitations, you could do say groups of 20 or more at a time!
At this time viewport is a global (same across all images) so can't change from image to image, but in the future even that may be modifiable on a per-image bases.
Re: optimizing 'convert' speed
Posted: 2011-06-02T09:35:35-07:00
by jgrauman
FMW42,
The -distort SRT did indeed help! The problem I'm having now involves setting the viewport correctly. I tried the method for the Centered Square Crop, but it creates a viewport that includes the entire rotated image (which has corners of distortion), whereas I would like the viewport set entirely inside the new rotated image, and therefore cutting off part of the corners of my image. Anyone have any thoughts about how to do this?
Anthony,
Thanks for the suggestion, but I'm not sure that is what I want. Can you clarify? I'm rotating and scaling images that came from several long videos. So I only need to do one rotate/scale per image, not multiple rotates per image. So it doesn't look like this helps, but maybe I'm missing something.
Thanks!
Re: optimizing 'convert' speed
Posted: 2011-06-02T10:34:59-07:00
by jgrauman
To put the problem graphically (see link), if the white box represents my original image that has been rotated, IM is returning the blue box as the viewport and I want the red box as the viewport. Any idea of how to do this???
http://grauman.com/box.png
Thanks!
Josh
Re: optimizing 'convert' speed
Posted: 2011-06-02T11:28:08-07:00
by fmw42
jgrauman wrote:To put the problem graphically (see link), if the white box represents my original image that has been rotated, IM is returning the blue box as the viewport and I want the red box as the viewport. Any idea of how to do this???
http://grauman.com/box.png
Thanks!
Josh
Can you post your command and some small image or test images as you have here showing how you got that far. The viewport crop may have to come at the end and may not be any better than just using -crop at the end result. Either way you need to figure out where the crop offset needs to be to get only the red box. If all your commands are the same, then you just have to figure (measure) this once.
You may be interested in my scripts, unrotate and autotrim and innercrop. However, they may run too slow for you. But you might be able get some ideas from the commands and create your own script to do what you want.
Re: optimizing 'convert' speed
Posted: 2011-06-02T13:09:50-07:00
by jgrauman
I'd like to have IM automatically figure out the best crop, since I'm converting about 50 videos, so I'd rather not have to calculate everything by hand. The rotate command will be the same for each video, so I guess if I have to, I can do the 50 calculations... Right now the fastest command I've come up with is as follows. The SRT scales the video down and rotates it, the viewport crops it, and then I scale it to the final image. The video is anamorphic (non-square pixels) which is why there is a square crop to a non-square scale.
I'd like IM to calculate the viewport for me "640x640+400+220" to be the biggest square that can fit inside the rotated/scaled image...
convert in.tga -set option:distort:viewport "640x640+400+220" -filter point +distort SRT '.6,1.2' -scale 640x480\! out.tga
the input is at:
http://grauman.com/in.tga
Re: optimizing 'convert' speed
Posted: 2011-06-02T13:44:40-07:00
by fmw42
As far as I know, IM does not have such an automatic inner crop. My innercrop script will do that, but it is not part of IM, nor does the viewport crop have any current means of figuring that out, to my knowledge. In principle, if one knows the rotation and scale, one can compute where the corners of the image will be and then figure out the largest inner box. But that is not currently part of IM. You would have to script that calculation for yourself and feed the results as variables to the viewport crop.
see
http://monochrome.sutic.nu/2010/08/14/optimal-crop.html
http://www.mathhelpforum.com/math-help/ ... 02791.html
http://wn.com/Using_mathematica_to_inscribe_a_square