Legacy ImageMagick Discussions Archive

I wonder if there is a simple way to capture Affine Projection output from -verbose -deskew… and feed this back to another image.

Did you try it?

It works for me in IM 6.8.4.8


convert zelda3_r4.png -verbose -deskew 40 null:
Affine Projection:
-distort AffineProjection \
'0.994484,0.104887,-0.104887,0.994484,0.000000,0.000000'
Affine Distort, FX Equivelent:
-size 154x153 -page -20-6 xc: +insert \
-fx 'ii=i+page.x+0.5; jj=j+page.y+0.5;
xx=+0.994484*ii +0.104887*jj -0.000000;
yy=-0.104887*ii +0.994484*jj +0.000000;
v.p{ xx-v.page.x-.5, yy-v.page.y-.5 }' \
zelda3_r4.png=> PNG 138x138=>154x153 154x153-20-6 16-bit sRGB 0.020u 0:00.049

For a practical example, using perspective... Finding the new location of a point within a image that was distorted
See...
IM Examples, Layers of Images, Positioning Distorted Perspective Images
http://www.imagemagick.org/Usage/layers/#layer_distort

Note that Affine Distortion is a a sub-set of Perspective Distortion.
And like perspective there are different (but related) coefficients for forward mapping (for distorting points and vectors) and reversed mapping (for distorting pixel arrays).

Also remember Distort control points are in Image Coordinates (0,0 is top-left edge corner) while Draw uses Pixel Coordinates (0,0 is the center of the top-left pixel).
See Image Coordinates vs Pixel Coordinates
http://www.imagemagick.org/Usage/distor ... oordinates




NOTE: in Freds output the affine projections translation amount is 0,0 that means the de-skew only performed a rotation around the images origion, and probably then junked any resulting virtual offset to the image.

This is probably a bug as I would expect the rotation to be performed using the center of the image. (whcih can produce slightly different results).

Hmmm that seems to be because deskew uses a 'Draw Rotation Affine' to do the rotation (old method). It probably needs to be updated to call distort SRT with just the angle, to rotate the image around its center.

Deskew probably also should verbosely report the rotation angle (and/or store it as a image artifact).

Fred what does report about the image after the deskew (I don't have your image)
(this reporting method was added as part of the updates for IMv7 CLI, but was backported to IMv6)


UPDATE; never mind, it does not save the calculated deskew angle anywhere, the only thing deskew does is report it in 'debug transform' output I'll see about having it save it into an artifact for access later in the same command (or to report via a excape sequence)...

okay...

I have added a little code (both Imv6 and Imv7) to save the calculated deskew angle as an artifact.
In SVN, revision 11784 Im version 6.8.4-9

For example... returned... image deskewed by -4.02199

If deskew failed this result will be 0 (or -0!)

However I never liked deskew as I found it rather buggy. Which is also why I have no IM Examples of its usage.

For example if you change the above example to use an initial rotation of 10 and the resulting image does not appear to have been deskewed. More over the reported calculated deskew angle was a tiny -0.895174 degrees, which is obviously not a good result.


NOTE: I have not modified anyong other than the save of the calculated. I have not touched what it does to rotate the image, nor have I changes the "deskew:auto-crop" handling.

ASIDE: the crop values for auto-crop is also reported in debuging.

For example if you change the above example to use an initial rotation of 10 and the resulting image does not appear to have been deskewed. More over the reported calculated deskew angle was a tiny -0.895174 degrees, which is obviously not a good result.

In my (limited) experience, -deskew only works well for angles of about 5 degrees or less. I think it was meant more for deskewing text images rather than everyday type images. In such case, it does not rely upon the outer padding from a small rotation, but uses the rows of text to guide it.

My unrotate script seems to work well for larger rotation angles so long as there is good separation of the image from its surrounding rotated padding or if an image is scanned at an angle.

I was looking at the code for the "deskew:auto-crop" artifact/option and finally figured what it does.

If you set -define deskew:auto-crop=50 then all the pixels within 50 pixels of the edge of the image will be used to calculate a
average background color! This is then used to do very rough sort of 'fuzzy trim' of the image. Specifically filter image using median statistic, get bounding box based on that background, crop original image with that bounding box.

I must say WOW...

Then... Why wasn't that documented? -- It is now in code and on options page.

And then.. Why is this only available in -deskew?
This technique would be a great addition as a separate operations. For example....as a way to auto-set an images background color, and as a separate a fuzzy trim operation, (for example as a +trim ?). That is a "trim" that is, background color limited, median/blurred filtered, with fuzz factor control.

See the long time example "Noisy image trim"
http://www.imagemagick.org/Usage/crop/#trim_noisy


WARNING: deskew will also also ways set 'Background Virtual Pixel Method'
It does not save what method was previously set, so as to restore it afterwards!
I regard that as a bug.