Mailing-List: contact batik-users-help@xmlgraphics.apache.org; run by ezmlm
Precedence: bulk
Reply-To: batik-users@xmlgraphics.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Extracting information from a transformation matrix
Date: Fri, 9 Jun 2006 10:57:52 -0400
Message-ID: <523D779E0FF8A2468663A738B844AD0504B7D288@postman.j9.root2k.local>
In-Reply-To: 
 <OF4412BDF8.6F6793B4-ON85257187.003B54DC-85257187.0041AF7E@knotes.kodak.com>
Thread-Topic: Extracting information from a transformation matrix
Thread-Index: AcaK8u0FYglwnjnbTaWWvdSlPy0owgA4aJ0g
From: "Bishop, Michael W. CONTR J9C880" <Michael.Bishop@je.jfcom.mil>
To: <batik-users@xmlgraphics.apache.org>

Yeah, I was thinking rotate(degrees) was the same as
AffineTransform.rotate(degrees) and it's not.  It seems your latest
example works.  I didn't realize that manipulating an element was going
to be such a pain.  I suspect that's why InkScape "applies" each
transformation after you manipulate an object.  If you move it, it
changes the attributes that define the location.  If you scale it, it
changes the attributes that manipulate the width/height.  I thought that
would be a major pain (especially for polyline, polygon, and path
elements).  Now I'm not so sure.  Thanks for the help in figuring this
out.  A utility class that takes an element's AffineTransform and
correctly allows multiple move, scale, rotate, etc. is probably what I'm
going to write to keep all this simple.

Michael Bishop

-----Original Message-----
From: thomas.deweese@kodak.com [mailto:thomas.deweese@kodak.com]=20
Sent: Thursday, June 08, 2006 7:57 AM
To: batik-users@xmlgraphics.apache.org
Cc: batik-users@xmlgraphics.apache.org
Subject: RE: Extracting information from a transformation matrix

Hi Michael,

"Bishop, Michael W. CONTR J9C880" <Michael.Bishop@je.jfcom.mil> wrote on

06/07/2006 03:31:12 PM:

> public static double[] getRotationAngle(AffineTransform inTransform) {
> double tx =3D Math.atan2(inTransform.getShearX(),
> inTransform.getScaleX());
> double ty =3D Math.atan2(inTransform.getShearY(),
> inTransform.getScaleY());

   I suspect these may need some tweaking.=20
I don't have the time to sit down and sort the trig=20
out exactly but I suspect I used ShearX when I should
have used ShearY, so something like:

double rx =3D Math.atan2(inTransform.getShearY(),
inTransform.getScaleX());
double ry =3D
Math.atan2(-inTransform.getShearX(),inTransform.getScaleY());

   but really you should pull out your old Trig Texts=20
to sort this out.

> AffineTransform affineTransform =3D new AffineTransform(1, 0, 0, 1, 0
,0);
> affineTransform.translate(10, 10);
> affineTransform.scale(2, 2);
> affineTransform.rotate(60);

    Like most computer languages (and real math people) the
value to rotate is in radians (2*PI rad =3D 360 deg).  Since
this wraps every 2PI the above value is really ~3.451 which
is -2.83185... if you map it in the range -PI to PI.

> double[] rotation =3D
> AffineTransformUtil.getRotationAngle(affineTransform);
> System.out.println("Rotation X: " + rotation[0]);
> System.out.println("Rotation Y: " + rotation[1]);
> }
>=20
> I get unexpected results:
>=20
> Rotation X: 2.831853071795865
> Rotation Y: -2.831853071795865

   This is close to the expected results, perhaps
the above fix with sort the rest of it out...

>=20
> I thought in this case with uniform scaling, I'd see 60.
> If I have non-uniform scaling, how do I represent two different
rotation
> angles (x and y) in the transform attribute?  I don't understand how
> rotate(t, cx, cy) breaks down into two values for rotate.
>=20
> Michael Bishop
>=20
> -----Original Message-----
> From: thomas.deweese@kodak.com [mailto:thomas.deweese@kodak.com]=20
> Sent: Tuesday, June 06, 2006 8:39 PM
> To: batik-users@xmlgraphics.apache.org
> Cc: batik-users@xmlgraphics.apache.org
> Subject: RE: Extracting information from a transformation matrix
>=20
> Hi Michael,
>=20
> "Bishop, Michael W. CONTR J9C880" <Michael.Bishop@je.jfcom.mil> wrote
on
>=20
> 06/06/2006 08:28:55 PM:
>=20
> > I'm confused...why do you call it "rotX"?=20
> > Isn't there only a single rotation angle?
>=20
>    Not in the presence of shear.  Take the simple example of shearY:
>=20
> +------+         +------+
> |      |   ->   /       /
> +------+       +-------+
>=20
>    Note that a vector aligned with the x-axis will experience no
> rotation.  However a vector aligned with the y-axis will experience
> rotation.  This is why I called the above value 'rotX' it is
> the rotation of a vector aligned on the x-axis.
>=20
>    If you don't have shear or non-uniform scaling (which can make
> some of a normal rotation "look like" shear), this BTW is your
> case, then rotX and the similar 'rotY' calculation will match.
>=20
>=20
>=20
> > ________________________________
> >=20
> > From: thomas.deweese@kodak.com [mailto:thomas.deweese@kodak.com]
> > Sent: Tue 6/6/2006 7:46 PM
> > To: batik-users@xmlgraphics.apache.org
> > Cc: batik-users@xmlgraphics.apache.org
> > Subject: RE: Extracting information from a transformation matrix
> >=20
> >=20
> >=20
> > Hi Michael,
> >=20
> > "Bishop, Michael W. CONTR J9C880" <Michael.Bishop@je.jfcom.mil>
wrote
> on
> > 06/06/2006 01:39:25 PM:
> >=20
> > > OK, I'm still struggling with this.  I'm trying to derive the
> rotation
> > > angle using the MatrixReverse function here:
> > >
> > > =
http://www.datenverdrahten.de/svglbc/?code=3Dmatrix_reverse&znr=3Don
> >=20
> >    The code there doesn't look right to me.  In particular
> > the calculation of konst1 is using tansky which is known to
> > be zero.  I can't say this is 100% wrong (it may simply be
> > to reduce 'unknowns').
> >=20
> >    I would simply use:
> >=20
> >         double rotX =3D Math.atan2(at.getShearX(), at.getScaleX());
> >=20
> >    I'm fairly sure I have scaleX/shearX in the right place.
> >=20
> > > Here's my test code:
> > >
> > > AffineTransform affineTransform =3D new AffineTransform(1, 0, 0, =
1,
0,
>=20
> 0);
> > >         affineTransform.translate(10, 10);
> > >         affineTransform.scale(2, 2);
> > >         System.out.println("Transform: " + affineTransform);
> > >         System.out.println(
> > >             "Angle: " +
> > > AffineTransformUtil.getRotationAngle(affineTransform));
> > >         affineTransform.rotate(60);
> > >         System.out.println(
> > >             "Angle: " +
> > > AffineTransformUtil.getRotationAngle(affineTransform));
> > >
> > > The first time, the angle is reported as 0.0 which is correct.
The
> > > second time, it's reported as 17.746...which is not.  I'm under
the
> > > impression it should be 60.  Anyone know how/why this (doesn't)
> work?
> > >
> > > Michael Bishop
> > >
> > > -----Original Message-----
> > > From: Bishop, Michael W. CONTR J9C880
> > > [mailto:Michael.Bishop@je.jfcom.mil]
> > > Sent: Monday, June 05, 2006 1:49 PM
> > > To: batik-users@xmlgraphics.apache.org
> > > Subject: RE: Extracting information from a transformation matrix
> > >
> > > Well I'm trying to integrate this side-by-side with what's already
> > > there.  So when I print out the attributes, I print out the=20
> "transform"
> > > attribute and I print out the dummy "matrix" attribute
> > > (matrix=3D"matrix(a, b, c, d, e, f)".
> > >
> > > The problem is that if I translate, things are fine.  If I scale,=20
> things
> > > are fine.  If I scale, then translate, the "matrix" numbers don't=20
> match
> > > the "transform".  In order to get them to match up, I've been=20
> "undoing"
> > > everything:
> > >
> > > (For translation)
> > >
> > > transform.scale(1.0d / sx, 1.0d / sy);
> > > transform.translate(tx, ty);
> > > transform.scale(sx, sy);
> > >
> > > In order to make the numbers "match", I have to do all my
> translations
> > > "first" before scaling.  This kind of makes sense; when I use the
> > > transform attribute, I always start from scratch: translate(tx,
ty)
> > > scale(sx, sy) rotate(t).
> > >
> > > I see the "preConcatenate" method here in the JDK, so let's go
back
> to
> > > my use case.  I want to be able to translate, rotate, and scale in
> any
> > > order.  The user could draw an element, scale it by 150%, rotate
it
> 60
> > > degrees, drag it to the left, scale down to 50%, etc.
> > >
> > > I'm not sure how preconcatenating will help because I don't know
> when=20
> to
> > > do it and when not to.  I need to preconcatenate before any
scaling
> > > operations I think.  Rotate just makes it even tougher.
> > >
> > > Michael Bishop
> > >
> > > -----Original Message-----
> > > From: thomas.deweese@kodak.com [mailto:thomas.deweese@kodak.com]
> > > Sent: Monday, June 05, 2006 1:38 PM
> > > To: batik-users@xmlgraphics.apache.org
> > > Cc: batik-users@xmlgraphics.apache.org
> > > Subject: RE: Extracting information from a transformation matrix
> > >
> > > Hi Michael,
> > >
> > > "Bishop, Michael W. CONTR J9C880" <Michael.Bishop@je.jfcom.mil>
> wrote=20
> on
> > >
> > > 06/05/2006 12:12:15 PM:
> > >
> > > > Am I correct in assuming that:
> > > >
> > > > transform(tx, ty) scale(sx, sy)
> > > >
> > > > and
> > > >
> > > > sx  0  tx
> > > > 0   sy ty
> > > >
> > > > will hold identical values for sx, sy, tx, and ty for any values
> of
> > > > those variables?  In other words, no matter how I
scale/translate
> or
> > > in
> > > > what order, should it matter?  Note that no rotation has been
> > > > introduced.
> > >
> > >    Order does matter. So scale then translate is different from
> > > translate then scale.  However since you are manipulating the
> > > transform on one element you can play some games by choosing to
> > > pre or post multiply the various transforms.  So if you always
> > > post multiply the translate transform (preconcatenate in JDK
> > > terms) then the translate part will just be 'added' to the
> > > existing matrix.  This is probably what you want for translate
> > > (from what I recall of how you handle things).
> > >
> > >
> > > >
> > > > Michael Bishop
> > > >
> > > > -----Original Message-----
> > > > From: Bishop, Michael W. CONTR J9C880
> > > > [mailto:Michael.Bishop@je.jfcom.mil]
> > > > Sent: Friday, June 02, 2006 12:32 PM
> > > > To: batik-users@xmlgraphics.apache.org
> > > > Subject: RE: Extracting information from a transformation matrix
> > > >
> > > > Good, good...OK, now I'm getting an understanding and figuring
out
> > > what
> > > > needs to be done.  I assume the 6 values are represented as:
> > > >
> > > > a b c
> > > > d e f
> > > > 0 0 1 (implied, I know we don't really care about these values)
> > > >
> > > > According to my reference, to do a translation, I would have to
> > > multiply
> > > > in the following:
> > > >
> > > > 1 0 tx
> > > > 0 1 ty
> > > > 0 0 1 (again, implied)
> > > >
> > > > A scale:
> > > >
> > > > sx  0   0
> > > > 0   sy  0
> > > > 0   0   1 (implied for consistency's sake)
> > > >
> > > > A rotate:
> > > >
> > > > cos(t) -sin(t) 0
> > > > sin(t)  cos(t) 0
> > > > 0       0      1 (blah blah)
> > > >
> > > > To get this done in code:
> > > >
> > > > AffineTransform affineTransform =3D new AffineTransform(a, b, c,
d,
> e,
> > > f);
> > > > SVGMatrix svgMatrix =3D new SVGOMMatrix(affineTransform);
> > > >
> > > > Besides the obvious way of calling getA(), getB(), etc., is
there
> a
> > > way
> > > > to turn this into the proper attribute?
> > > >
> > > > transform=3D"matrix(a, b, c, d, e, f)"
> > > >
> > > > Michael Bishop
> > > > -----Original Message-----
> > > > From: Andrew Plotkin [mailto:erkyrath@eblong.com]
> > > > Sent: Friday, June 02, 2006 12:20 PM
> > > > To: batik-users@xmlgraphics.apache.org
> > > > Subject: RE: Extracting information from a transformation matrix
> > > >
> > > > On Fri, 2 Jun 2006, Bishop, Michael W. CONTR J9C880 wrote:
> > > >
> > > > > I don't care how it looks at all.  I don't need to present
> > > information
> > > > > to the user.  I can store the 6 values and keep it that way.
> > > >
> > > > Ok.
> > > >
> > > > > But realistically, if I wanted to rotate around a center
point,=20
> I'd
> > > > > translate to the center point, perform the rotation, then
> > > > "untranslate"
> > > > > to the center point.  Does Batik assist with these
calculations?
> > > >
> > > > The SVGMatrix interface has a multiply(SVGMatrix) method.
> > > >
> > > > > Am I even on the right
> > > > > track here in that every operation I want to do is a new
> > > > multiplication?
> > > >
> > > > Yes, that's right.
> > > >
> > > > > After I rotate, if I want to translate again, do I have to
> "undo"
> > > > > anything or just multiply in a new (tx, ty)?
> > > >
> > > > Just multiply in a new one.
> > > >
> > > > --Z
> > > >
> > > > --
> > > > "And Aholibamah bare Jeush, and Jaalam, and Korah: these were
the
> > > > borogoves..."
> > > > *
> > > > If the Bush administration hasn't subjected you to searches
> without=20
> a
> > > > warrant,
> > > > it's for one reason: they don't feel like it. Not because you're
> > > > innocent.
> > > >
> > > >=20
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:=20
> batik-users-unsubscribe@xmlgraphics.apache.org
> > > > For additional commands, e-mail:
> > > batik-users-help@xmlgraphics.apache.org
> > > >
> > > >=20
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:=20
> batik-users-unsubscribe@xmlgraphics.apache.org
> > > > For additional commands, e-mail:
> > > batik-users-help@xmlgraphics.apache.org
> > > >
> > > >=20
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:=20
> batik-users-unsubscribe@xmlgraphics.apache.org
> > > > For additional commands, e-mail:
> > > batik-users-help@xmlgraphics.apache.org
> > > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> batik-users-unsubscribe@xmlgraphics.apache.org
> > > For additional commands, e-mail:=20
> batik-users-help@xmlgraphics.apache.org
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> batik-users-unsubscribe@xmlgraphics.apache.org
> > > For additional commands, e-mail:=20
> batik-users-help@xmlgraphics.apache.org
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> batik-users-unsubscribe@xmlgraphics.apache.org
> > > For additional commands, e-mail:=20
> batik-users-help@xmlgraphics.apache.org
> > >
> >=20
> >=20
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
batik-users-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail:
> batik-users-help@xmlgraphics.apache.org
> >=20
> >=20
> > [attachment "winmail.dat" deleted by Thomas E. DeWeese/449433/EKC]=20
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
batik-users-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail:
> batik-users-help@xmlgraphics.apache.org
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail:
batik-users-help@xmlgraphics.apache.org
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail:
batik-users-help@xmlgraphics.apache.org
>=20


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org