Virtual offset problems...

[anthony]

case 1

If I do...

Code: Select all

convert -page +10+10 rose: -identify -rotate 30 -identify show:
rose:=>ROSE PPM 70x46 0x0+10+10 8-bit sRGB 9.67KB 0.000u 0:00.000
rose:=>ROSE PPM 70x46=>86x76 0x0+10+10 8-bit sRGB 0.000u 0:00.000

The rotated image has a offset of +10+10 instead of the expected correct behaviour...

Code: Select all

convert rose: -repage +10+10 -identify -rotate 30 -identify show:
rose:=>ROSE PPM 70x46 70x46+10+10 8-bit sRGB 9.67KB 0.000u 0:00.000
rose:=>ROSE PPM 70x46=>86x76 86x76+2-5 8-bit sRGB 0.000u 0:00.000

That is -page is effecting the secondary rotated (or distorted) image when it should only effect completely NEW images.
This may only be appearing because 'distort' also changes the virtual offset of images.

This problem does NOT happen using the IMv7 "magick" command.

case 2

Also centered crop seems to be loosing the virtual offset...
For example... no offset case..

Code: Select all

convert rose: -identify -gravity center -crop 50% -identify show:
rose:=>ROSE PPM 70x46 70x46+0+0 8-bit sRGB 9.67KB 0.000u 0:00.000
rose:=>ROSE PPM 70x46=>35x23 70x46+18+12 8-bit sRGB 0.000u 0:00.000

But this should still have an extra 10 pixel offset (or perhaps a extra 5 pixels) added to the crop offset....

Code: Select all

convert rose: -repage +10+10 -identify -gravity center -crop 50% -identify show:
rose:=>ROSE PPM 70x46 70x46+10+10 8-bit sRGB 9.67KB 0.000u 0:00.000
rose:=>ROSE PPM 70x46=>35x23 70x46+18+12 8-bit sRGB 0.000u 0:00.000

As you can see the virtual offset component of the centered crop is 'lost'

Note the center of the crop is the virtual canvas, and not of actual image! That is to be expected, even if inconvenient.
This also happens with the IMv7 "magick" command.

The previous '-page' problem is also effecting this...

Code: Select all

convert -page +10+10 rose: -identify -gravity center -crop 50% -identify show:
rose:=>ROSE PPM 70x46 0x0+10+10 8-bit sRGB 9.67KB 0.000u 0:00.000
rose:=>ROSE PPM 70x46=>35x23 0x0+10+10 8-bit sRGB 0.000u 0:00.000

(not in IMv7)

[magick]

We can reproduce the problem you posted and have a patch in ImageMagick 6.8.4-9 Beta available by sometime tomorrow. Thanks.