# xmlgraphics-batik-users mailing list archives

##### Site index · List index
Message view
Top
From thomas.dewe...@kodak.com
Subject RE: Extracting information from a transformation matrix
Date Wed, 07 Jun 2006 00:38:34 GMT
```Hi Michael,

"Bishop, Michael W. CONTR J9C880" <Michael.Bishop@je.jfcom.mil> wrote on
06/06/2006 08:28:55 PM:

> I'm confused...why do you call it "rotX"?
> Isn't there only a single rotation angle?

Not in the presence of shear.  Take the simple example of shearY:

+------+         +------+
|      |   ->   /       /
+------+       +-------+

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.

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.

> ________________________________
>
> 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
>
>
>
> Hi Michael,
>
> "Bishop, Michael W. CONTR J9C880" <Michael.Bishop@je.jfcom.mil> wrote on
> 06/06/2006 01:39:25 PM:
>
> > 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=matrix_reverse&znr=on
>
>    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').
>
>    I would simply use:
>
>         double rotX = Math.atan2(at.getShearX(), at.getScaleX());
>
>    I'm fairly sure I have scaleX/shearX in the right place.
>
> > Here's my test code:
> >
> > AffineTransform affineTransform = new AffineTransform(1, 0, 0, 1, 0,
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
"transform"
> > attribute and I print out the dummy "matrix" attribute
> > (matrix="matrix(a, b, c, d, e, f)".
> >
> > The problem is that if I translate, things are fine.  If I scale,
things
> > are fine.  If I scale, then translate, the "matrix" numbers don't
match
> > the "transform".  In order to get them to match up, I've been
"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
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
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 = new AffineTransform(a, b, c, d, e,
> > f);
> > > SVGMatrix svgMatrix = new SVGOMMatrix(affineTransform);
> > >
> > > Besides the obvious way of calling getA(), getB(), etc., is there a
> > way
> > > to turn this into the proper attribute?
> > >
> > > transform="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,
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
a
> > > warrant,
> > > it's for one reason: they don't feel like it. Not because you're
> > > innocent.
> > >
> > >
---------------------------------------------------------------------
> > > 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
> > >
> > >
---------------------------------------------------------------------
> > > 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
> >
> > ---------------------------------------------------------------------
> > 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
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
>
> [attachment "winmail.dat" deleted by Thomas E. DeWeese/449433/EKC]
> ---------------------------------------------------------------------
> 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