Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmtk.streamxform and xform.default inconsistent with affine matrices #388

Open
jefferis opened this issue Feb 19, 2019 · 3 comments
Open
Labels
Milestone

Comments

@jefferis
Copy link
Collaborator

scalemat=rgl::scaleMatrix(8/1e3,8/1e3,8/1e3)

pts=structure(c(23244, 23376, 23384, 22364, 23354, 4566, 23684, 23195.5,
              23728, 23750, 31140, 31690, 31306, 33230, 32284, 20140, 32966,
              33498.6, 31998, 32328, 26474, 26540, 25610, 26584, 25506, 8346,
              26034, 26241.1, 25616, 26122), .Dim = c(10L, 3L), .Dimnames = list(
                NULL, c("X", "Y", "Z")))

transforming points using the same affine matrix via CMTK and xformpoints.default results in different outcomes. One is doing the inverse of the other.

> xform(pts, reglist(scalemat, swap = T))
            X        Y        Z
 [1,] 185.952 249.1200 211.7920
 [2,] 187.008 253.5200 212.3200
 [3,] 187.072 250.4480 204.8800
 [4,] 178.912 265.8400 212.6720
 [5,] 186.832 258.2720 204.0480
 [6,]  36.528 161.1200  66.7680
 [7,] 189.472 263.7280 208.2720
 [8,] 185.564 267.9888 209.9288
 [9,] 189.824 255.9840 204.9280
[10,] 190.000 258.6240 208.9760

> xform(pts, reglist(scalemat, swap = F))
            X       Y       Z
 [1,] 2905500 3892500 3309250
 [2,] 2922000 3961250 3317500
 [3,] 2923000 3913250 3201250
 [4,] 2795500 4153750 3323000
 [5,] 2919250 4035500 3188250
 [6,]  570750 2517500 1043250
 [7,] 2960500 4120750 3254250
 [8,] 2899438 4187325 3280138
 [9,] 2966000 3999750 3202000
[10,] 2968750 4041000 3265250

> xform(pts, simplify_reglist(reglist(scalemat, swap = F), as.cmtk = T))
            X        Y        Z
 [1,] 185.952 249.1200 211.7920
 [2,] 187.008 253.5200 212.3200
 [3,] 187.072 250.4480 204.8800
 [4,] 178.912 265.8400 212.6720
 [5,] 186.832 258.2720 204.0480
 [6,]  36.528 161.1200  66.7680
 [7,] 189.472 263.7280 208.2720
 [8,] 185.564 267.9888 209.9288
 [9,] 189.824 255.9840 204.9280
[10,] 190.000 258.6240 208.9760
@jefferis jefferis added the bug label Feb 19, 2019
@jefferis
Copy link
Collaborator Author

jefferis commented Feb 19, 2019

This is not good news at all, since there must be numerous cases in the wild where we may rely on this behaviour. This includes

@jefferis
Copy link
Collaborator Author

it looks like a significant overhaul of registration classes may be in order, to fix this, handle #387 and allow better mixing across different registration formats including:

@jefferis
Copy link
Collaborator Author

I wonder if I should add this to the some of the updates planned for nat v2 (e.g. adding a base class for objects with 3d coordinates)

@jefferis jefferis added this to the 2.0 milestone Feb 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant