Legacy ImageMagick Discussions Archive

Other way around. I don't add anything to the control points they should be in image coordinates not pixel positions.

Are you saying that when someone supplies control points as (integer) pixel values to -distort perspective that you don't add 0.5 to each to convert to image coordinates before computing the coefficients? If not how are you doing that correction within -distort perspective. I am now very confused what you are doing and what your coefficients correspond to in terms of control points.

I doubt that GIMP does anything but compute the coefficients from the (integer) pixel values!!! I doubt they it is that sophisticated as to the 0.5 pixel issue.

The control point are not changed, but used AS IS for the determination of the the distortion mapping coefficients (the matrix).

In other words a control point of 0,0 means the top left edge of the image .5,.5 means the
centre of the top left pixel. That is moving the pixel itself! This gives the users more exact control over the distortion to a sub-pixel level. Important when distorting images to match other images.

Gimp probably has user pixel selection, so it would add 0.5 to the pixel position so the user is in reality selecting the 'mid-point' of a actual pixel.

Draw uses pixel positions too. That is drawing a line from 0,0 to 10,10 goes from the mid-point
of those specified pixels! For draw it make sense, for distort it does not.

Internally the distort algorithm itself takes a pixel position for destination, adds the 0.5, does the mapping then subtracts 0.5 to lookup the color from the source image. That is it converts pixel positions into image coordinates, maps them, then converts back again, but ONLY during the actual conversion process. (see the verbose FX equivalent).

This is needed so that a 'NOOP' mapping does come out correct, and not blurred, as per our previous discussions. It is especially important say in a simple 2 times scaling, and was also needed to stop the 1/2 pixel movements you complained about for de-polar/polar cycles.

Internally the distort algorithm itself takes a pixel position for destination, adds the 0.5, does the mapping then subtracts 0.5 to lookup the color from the source image. That is it converts pixel positions into image coordinates, maps them, then converts back again, but ONLY during the actual conversion process. (see the verbose FX equivalent).

OK. So the coefficients are computed from the integer pixels (if that is what is provided), but then you offset each pixel in the image twice. Seems compute intensive. But as it works, great. Thanks.

I looked at the GIMP code, but I could find no obvious place where they add 0.5. So I am puzzled what they are doing differently. Perhaps I will extract some code from my 3Drotate and see what coefficients I get. Let you know more when/if I get around to it.

Ok, I read this post a couple times more plus http://www.imagemagick.org/Usage/distorts/ because I was struggling with where to put the data but now I understand how this thing works. and it worked for me using gimp pixel info ... explanation:

Well first you take the cordinates of each corner in gimp like fred explained before, starting with the up left corner...


Bold= Original Value
Normal=New value

convert pic/test.png -matte -virtual-pixel transparent -distort Perspective "0,0 0,0  0,306 0,306  463,306 425,276  463,0 420,20" pic/test_im.png

This give me ALMOST the same result has gimp...

I've played around with IM and to get the exact result I had to add some here and take some there, final cmd:

convert pic/test.png -matte -virtual-pixel transparent -distort Perspective "0,0 0,0 0,306 0,306 463,306 423,277 463,0 423,18" pic/test_im_50.png

But this isnt a problem for me, cuz its just a matter of adding +1's and sometimes -1's.

Thanks fred and anthony for the help!!
You guys are great helpers.

Take care

ISSUE SOLVED

As I have attempted to say many times.
Distort works with Image Coordinates! NOT integer pixel positions.

To specify the center of a pixel as a control point you need to add 0.5 to the pixels position to convert it to an image coodinate. that is because pixels have width and height!

As such the first set of coodinates distorting the PIXEL coodinates, should be...
"0.5,0.5 0.5,0.5 0.5,306.5 0.5,306.5 463.5,306.5 425.5,276.5 463.5,0.5 420.5,20.5"
Yes it is a pain, but it means users can select either the pixels or the edges of images.
-draw -annotate etc does not need the +0.5 as thay work on pixel coordinates and not image coordinates.

Now does the above produce the same result as gimp?

Unless you are specifying the 'edge' of the pixels/image to move.
To re-iterate 0,0 is the top left EDGE of the image
0.5,0.5 is the top left PIXEL of the image.

The bottom-right EDGE of the image is the images Width,Height
The bottom-left PIXEL is (Width-0.5),(Height-0.5)

Also a un-documented feature (may change) is that FX arguments can take percent escapes!
as such the in a fx argument the bottom right EDGE can be specified as ' ... %w,%h ....'
and the bottom-right PIXEL as '.... %[fx:w-.5],%[fx:h-0.5] ....'

This is a un-documented feature because it is not validates or ratified as being a good direction to allow percent escapes in option arguments. The only other operation that does this is -sparse-colors

To specify the center of a pixel as a control point you need to add 0.5 to the pixels position to convert it to an image coodinate. that is because pixels have width and height!

Yes that makes sense.

Now does the above produce the same result as gimp?

It doesn't for me Anthony... here is the gimp original image vs your cordinates (+0.50)



the only that get exact the same is :

convert pic/test.png -matte -virtual-pixel transparent -distort Perspective "0,0 0,0 0,306 0,306 463,306 423,277 463,0 423,18" pic/test_im_50.png

But to be honest maybe is something I did wrong, like maybe i didnt measure well the cordinates in gimp and took the inside of the pixel instead of the outside ... so don't worry to much about it.

For me this post solved my problem
Thanks a million again! great support! 5/5

Well it obviously isn't correct. and it is off by far more than just 1/2 a pixel! more like 2 to 3 pixels.

Making the animation a little slower would have been better, so you can see what image was from what source. I downloaded the image and ran it through the "flicker_cmp" script from the IM examples 'scripts' directory to display it at a slower rate, so I could see what image was what.

Gimp's image has a perfectly vertical right edge, but the coordinates used for IM are not lined up vertically, so it does not produce a vertical right edge. Something was definataly screwy with the coordinates.

The top-left corner does shift about 1/2 a pixel but in a odd top-right to bottom-left diagonal direction, which is even more odd. And such shift due to the use of different coordinate systems would be in a top-left to bottom right diagonal direction.

Curiouser, and curiouser said Alice!

But if you are happy then I'll leave it at that, until we can get someone to do some more exact comparisons.