Possible Bug -append/-rotate IM 6.7.1-0 Q16 on WinXP

[stupid]

This command having started, hangs absolutely dead. It works okay without -rotate.

convert IN.JPG ^
( +clone -rotate -22.5 ) ^
-compose Src -composite ^
( +clone -flip ) ^
-append ^
-rotate 45 ^
OUT.JPG

( +distort SRT 45 works as expected.)


Thanks.

[anthony]

Which -rotate? you have two of them!

Also why the -flip? for a mirror effect?

Oh I see Yes a mirror effect... Works for me under linux!
convert rose: \( +clone -rotate -22.5 \) -compose Src -composite \( +clone -flip \) -append -rotate 45 show:

[stupid]

Glad it works on linux. The second rotate, -rotate 45 is the one I meant. That's why I added -append as part of the title to this report.

I've tried it again. Still hanging. It seems to be related to size of input image. 800x600 px works fine; 4000x3000 px doesn't.


S.

[anthony]

Then it is more likly running out of memory. After rotating the image gets bigger, (45 is maximum enlargement for a squareish image) during that stage IM need to hold at least three images in memory due to its use of 3 shears to generate the rotation

See expert notes IM examples
http://www.imagemagick.org/Usage/warping/#rotate

The Rotate Operator is actually implemented using Simple Distorts followed by three Image Shears, a technique known as 'Rotate by Shear' (RBS) and first publish in research papers by Alan Paeth.

Also see Shears for even more info
http://www.imagemagick.org/Usage/warping/#shear
As well as Leptonica Rotation for more detail.
http://www.leptonica.com/rotation.html

Now if IM reaches memory limits it will switch to using a Cache to Disk method which compare to memory is deathly slow!
(there are monitor and debug options that will let you watch this happen).

However the -distort SRT method only needs two images the source and destination. It uses direct mathematical mapping (using affine matrixs not trignometric functions), and full Filtered sampling of the source image (EWA resampling) whci hresults is far superiour results at the pixel level. However it will be slower as it is not simply 'scanline processing' the image (3 times). Most importantally 'low memory requirements.

Use +distort to get it to expand the resulting image, and follow with +repage to remove virtual layer positioning info afterwards.

If you want you can speed it up by turning off the EWA filter using -filter none, and it will then be faster and probably still produce a 'better' result that traditional -rotate!

[anthony]

ASIDE: if you want to watch the many steps needed for traditional rotating (under UNIX/Linux) use...

Code: Select all

   convert rose: -monitor  -rotate 45 null: 2>&1 | mac2unix | less

this shows the processing steps...

add frame to image[ROSE]...
x shear image[ROSE]...
y shear image[ROSE]...
x shear image[ROSE]...
crop image[ROSE]...

the first is reading the image
the next three the shears used to rotate the image
the last a crop to trim the excess space caused by the three shears.
The final write is not shown as "null:" does not actually write the image, just junks it!

Is it any wonder that traditional -rotate has 'blur' issues Even though it is 'reasonably fast'.

[stupid]

Yes, I see. Thanks for the full explantion. Glad not a bug at your end or mine! Thanks again.


S.

[anthony]

No just the need for three or more images (original, an intermediate and the result)