It seems that this entire package uses *inverse* transformations from the usual
convention.
This is borne out by examination of the Transform functions, which transform
from the destination to the source to look up pixels.
In addition, each of the Rotate, Translate, etc. functions generates an inverse
matrix (for example, Translate puts -x and -y in the translation terms;
Rotation produces at clockwise rotation by documentation, while the matrix it
provides usually produces a ccw rotation).
If this is intentional it needs to be clearly documented - providing your own
affine transform doesn't work as expected - you have to invert it first.
To fix this we'd need to add an Invert() function and call it before the
transformations. I'm happy to provide a patch if this is the correct route.
Original issue reported on code.google.com by
Paul.A.L...@gmail.comon 12 Jan 2012 at 7:13