MantisBT - VTK
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0009062VTK(No Category)public2009-05-25 14:182013-04-05 20:25
ReporterStefano Trapani 
Assigned ToDavid Gobbi 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Project
Type
Summary0009062: vtkTransform GetOrientationWXYZ returns wrong values after hand-inverting scaling
DescriptionThis bug was found using VTK 5.0.4 with Python 2.5.2 [GCC 4.3.2]

vtkTransform GetOrientationWXYZ returns wrong values if the vtkTransform has undergone hand-inverting scaling.

Here is a simple python example where one wants to define the isometric transform (x,y,z)->(-x,-y,-z) that inverts the coordinates trhough the origin:

> from vtk import *
> T = vtkTransform()
> T.Scale(-1,-1,-1)

While T.GetMatrix(), T.GetScale() and T.GetPosition() return the expected values, T.GetOrientationWXYZ() does not:

> print T.GetMatrix()
vtkMatrix4x4 (0x16515f0)
  Debug: Off
  Modified Time: 9
  Reference Count: 3
  Registered Events: (none)
  Elements:
    -1 0 0 0
    0 -1 0 0
    0 0 -1 0
    0 0 0 1
>
> T.GetScale()
(-1.0, -1.0, -1.0)
>
> T.GetPosition()
(0.0, 0.0, 0.0)
>
> T.GetOrientationWXYZ()
(180.0, 0.0, 0.0, 1.0)

T.GetOrientationWXYZ should return (0.0, 0.0, 0.0, 1.0), not (180.0, 0.0, 0.0, 1.0).

Combining an OrientationWXYZ=(180.0, 0.0, 0.0, 1.0) with the Scale and Position given above would correspond to the isometry (x,y,z)->(x,y,-z) which is a mirror reflection throgh the (xy) plane, not an inversion through the origin.

I came across this problem using VTK 5.0.4 with Python 2.5.2 [GCC 4.3.2].
Using the previous VTK 5.0.3 version, T.GetOrientationWXZY() would produce a more serious segmentation fault. This bug has been fixed in VTK 5.0.4 (http://www.kitware.com/news/home/browse/VTK?2008_01_22&VTK+Patch+Release [^]) but apparently the results returned by GetOrientationWXZY() are not correct yet.

I have not tested with more recent version of VTK. Nor have I checked the GetOrientation() returned values ...
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2009-05-25 14:18Stefano TrapaniNew Issue
2011-02-26 10:23David GobbiAssigned To => David Gobbi
2011-02-26 10:23David GobbiStatusbacklog => tabled
2011-04-21 17:56David GobbiNote Added: 0026240
2011-04-21 18:04David GobbiStatustabled => @80@
2011-04-21 18:04David GobbiResolutionopen => won't fix
2011-06-16 13:11Zack GalbreathCategory => (No Category)
2013-04-05 20:25Berk GeveciStatuscustomer review => closed

Notes
(0026240)
David Gobbi   
2011-04-21 17:56   
The issue here is that Orientation and Scale are not independent parameters.
A simple example of this is SetScale(-1, -1, 1) which could equally well be
interpreted as a rotation of 180 degrees. So after applying this scale, would
you expect to get back a scale of (-1, -1, 1) and and identity orientation,
or a scale of (1, 1, 1) and a orientation of (180, 0, 0, 1)?

It is true that the results could at least be made more consistent by always
applying the same SVD decomposition when returning scale as when
returning orientation. But when I wrote the code for GetOrientationWXYZ()
I made the decision for it to return the best-fit orientation under the
assumption that flipped matrices were not allowed (i.e. that any matrix with
a flip only had a flip due to numerical error). I still think that was a valid
choice, and any changes at this point will introduce backwards-incompatibility.

If you require strict guarantees about the exact form of matrix decomposition
that is applied when the matrix scale/orientation is computed, then use
vtkMath::SingularValueDecomposition(). I'd rather leave the vtkTransform
methods unchanged.