WeightedVotingFusionImageFilter(0x558b59d99b30): Inputs do not occupy the same physical space!

Question

WeightedVotingFusionImageFilter(0x558b59d99b30): Inputs do not occupy the same physical space!

muratmaga opened this issue 3 years ago · 5 comments

I have 18 MRI scans of fetal mice that are manually segmented.

I am trying to use randomly selected 6 of those as atlases and use the JLF on the remaining samples to evaluate how close we can get to the manual ones. I have used JLF successfully for this purpose before, but I am getting this error at the JLF step. This is happening for all samples, not just the one currently being passed.

>   JLF = jointLabelFusion(targetI=img, targetIMask = msk, atlasList =ref.imgs , labelList = ref.labels, verbose = TRUE)

Running antsJointFusion for 3-dimensional images.

Exception caught: 
itk::ExceptionObject (0x558b50b72dd0)
Location: "unknown" 
File: /usr/local/lib/R/site-library/ITKR/libs/include/ITK-5.2/itkImageToImageFilter.hxx
Line: 219
Description: itk::ERROR: itk::ERROR: WeightedVotingFusionImageFilter(0x558b59d99b30): Inputs do not occupy the same physical space! 
InputImage Origin: [-1.3785417e+01, -6.9695311e+00, 3.1688524e+00], InputImage_10 Origin: [-1.3785417e+01, -6.9695311e+00, 3.1688526e+00]
	Tolerance: 5.1041667e-08

Error in h(simpleError(msg, call)) : 
  error in evaluating the argument 'x' in selecting a method for function 'sum': subscript out of bounds
In addition: Warning message:
In .Call("antsJointFusion", .int_antsProcessArguments(c(myargs)),  :
  converting NULL pointer to R NULL

As the preprocessing step, I rigidly registered these images to a reference sample to make sure they all are in the same physical space. As far as I can tell, they are.

> lapply(imgs, antsGetOrigin)
[[1]]
[1] -13.7854165396067536165  -6.9695310592651367188   3.1688524499970043280

[[2]]
[1] -13.7854165396067536165  -6.9695310592651367188   3.1688524499970043280

[[3]]
[1] -13.7854165396067536165  -6.9695310592651367188   3.1688524499970043280

[[4]]
[1] -13.7854165396067536165  -6.9695310592651367188   3.1688524499970043280

[[5]]
[1] -13.7854165396067536165  -6.9695310592651367188   3.1688524499970043280

[[6]]
[1] -13.7854165396067536165  -6.9695310592651367188   3.1688524499970043280

[[7]]
[1] -13.7854165396067536165  -6.9695310592651367188   3.1688524499970043280

[[8]]
[1] -13.7854165396067536165  -6.9695310592651367188   3.1688524499970043280

[[9]]
[1] -13.7854165396067536165  -6.9695310592651367188   3.1688524499970043280

[[10]]
[1] -13.7854165396067536165  -6.9695310592651367188   3.1688524499970043280

[[11]]
[1] -13.7854165396067536165  -6.9695310592651367188   3.1688524499970043280

[[12]]
[1] -13.7854165396067536165  -6.9695310592651367188   3.1688524499970043280

[[13]]
[1] -13.7854165396067536165  -6.9695310592651367188   3.1688524499970043280

[[14]]
[1] -13.7854165396067536165  -6.9695310592651367188   3.1688524499970043280

[[15]]
[1] -13.7854165396067536165  -6.9695310592651367188   3.1688524499970043280

[[16]]
[1] -13.7854165396067536165  -6.9695310592651367188   3.1688524499970043280

[[17]]
[1] -13.7854165396067536165  -6.9695310592651367188   3.1688524499970043280

[[18]]
[1] -13.7854165396067536165  -6.9695310592651367188   3.1688524499970043280

> lapply(segs, antsGetOrigin)
[[1]]
[1] -13.7854166030883789062  -6.9695310592651367188   3.1688525676727294922

[[2]]
[1] -13.7854166030883789062  -6.9695310592651367188   3.1688525676727294922

[[3]]
[1] -13.7854166030883789062  -6.9695310592651367188   3.1688525676727294922

[[4]]
[1] -13.7854166030883789062  -6.9695310592651367188   3.1688525676727294922

[[5]]
[1] -13.7854166030883789062  -6.9695310592651367188   3.1688525676727294922

[[6]]
[1] -13.7854166030883789062  -6.9695310592651367188   3.1688525676727294922

[[7]]
[1] -13.7854166030883789062  -6.9695310592651367188   3.1688525676727294922

[[8]]
[1] -13.7854166030883789062  -6.9695310592651367188   3.1688525676727294922

[[9]]
[1] -13.7854166030883789062  -6.9695310592651367188   3.1688525676727294922

[[10]]
[1] -13.7854166030883789062  -6.9695310592651367188   3.1688525676727294922

[[11]]
[1] -13.7854166030883789062  -6.9695310592651367188   3.1688525676727294922

[[12]]
[1] -13.7854166030883789062  -6.9695310592651367188   3.1688525676727294922

[[13]]
[1] -13.7854166030883789062  -6.9695310592651367188   3.1688525676727294922

[[14]]
[1] -13.7854166030883789062  -6.9695310592651367188   3.1688525676727294922

[[15]]
[1] -13.7854166030883789062  -6.9695310592651367188   3.1688525676727294922

[[16]]
[1] -13.7854166030883789062  -6.9695310592651367188   3.1688525676727294922

[[17]]
[1] -13.7854166030883789062  -6.9695310592651367188   3.1688525676727294922

[[18]]
[1] -13.7854166030883789062  -6.9695310592651367188   3.1688525676727294922

I am at a loss where that really small rounding error might be coming from. Any suggestions will be much appreciated.

Answer 1 · 2021-11-12T19:22:38.000Z

As I copy/paste, I noticed that while origins imgs and labels lists are internally consistent, it looks like there is indeed an difference between them, which is probably the culprit. The labelmaps are generated by passing the transform from the rigid registration to antsApplyTransforms function. The call was like this:

seg = antsApplyTransforms(fixed=ref, moving=seg, transformlist = rigid$fwdtransforms, interpolator = "genericLabel")

So I guess the question is how can I make this robust? So that the resultant labelmap has identical physical space as the associated intensity image.

Answer 2 · 2021-11-12T19:26:57.000Z

See antsCopyImageInfo and antsCopyImageInfo2

Answer 3 · 2021-11-12T19:27:11.000Z

There'a some options here

https://github.com/ANTsX/ANTs/wiki/Inputs-do-not-occupy-the-same-physical-space

Answer 4 · 2021-11-12T19:29:31.000Z

Thanks will try all!

Answer 5 · 2021-11-12T19:37:53.000Z

antsCopyImageInfo did the trick. Thanks you all!