optimizing 'convert' speed

Questions and postings pertaining to the usage of ImageMagick regardless of the interface. This includes the command-line utilities, as well as the C and C++ APIs. Usage questions are like "How do I use ImageMagick to create drop shadows?".
User avatar
fmw42
Posts: 25562
Joined: 2007-07-02T17:14:51-07:00
Authentication code: 1152
Location: Sunnyvale, California, USA

Re: optimizing 'convert' speed

Post by fmw42 »

try

-distort SRT "%[fx:w/2],%[fx:h/2] etc for Xscale Yscale and rotation"
User avatar
anthony
Posts: 8883
Joined: 2004-05-31T19:27:03-07:00
Authentication code: 8675308
Location: Brisbane, Australia

Re: optimizing 'convert' speed

Post by anthony »

Exact center is %[fx:w/2],%[fx:h/2]
Imagemagick will then calculate it for you.


However i still do not think SRT will work, because with a asotropic image (non-square pixels) the transformation is really of the form
scale_to_square_pixels --> do rotation --> user_scaling --> scale_to_restore_astropic

You can not merge the three scales together due to the rotation separating them.
Also this is ignoring the 'translations' needed for scaling and rotation about a specific point (the center), but that is simple by comparision.

All the steps are however affine transforms, so you can generate it is as a single affine distortion (SRT does this for its stuff), either using three control points (one does not change, so really only two), or using affine matrix maths.

It is possible, just a bit harder and more involved.
Anthony Thyssen -- Webmaster for ImageMagick Example Pages
https://imagemagick.org/Usage/
jgrauman
Posts: 15
Joined: 2010-06-15T23:42:05-07:00
Authentication code: 8675308

Re: optimizing 'convert' speed

Post by jgrauman »

FYI: Maybe I'm missing something, but can't I just combine the scale to square pixels and user scaling into one step? It looks like it's working perfectly for me this way. I wrote a program (in C++/Qt) that calculates the smallest scale factors that after a given rotation a 640x480 rectangle will fit into. Thus a SRT with x and y scale factors of 0.604000, and 0.453000 (notice they are non-square and different by a factor of 4/3) and rotation of .8, will just fit a 640x480 rect into it (starting with an anaphoric 1440x1080 image). It looks like it's working perfectly from my tests and the resulting video looks nice. Since it's only a single SRT with viewport crop, it also runs much faster than my initial tests, and so should be perfect for me! Also, I don't need my resultant video to be asotropic/anaphoric/non-square ;), I actually don't want it to be. It's just that my camcorder records it that way. Thanks.
User avatar
anthony
Posts: 8883
Joined: 2004-05-31T19:27:03-07:00
Authentication code: 8675308
Location: Brisbane, Australia

Re: optimizing 'convert' speed

Post by anthony »

Try it with a large angle like 45 degrees with a right angle in the image. I am sure you will find it comes out skewed!
when you view the result in its normal non-square pixel mode.

You can apply it in one step, but the distortion needs more calculation. Just the movement of two points relative to the center is enough to get the right numbers. The scaling would be included in that calculation.
Anthony Thyssen -- Webmaster for ImageMagick Example Pages
https://imagemagick.org/Usage/
Post Reply