Hi,
I am Tenzin. I would like to ask about a problem I am having.
I did some segmentation on ITK snap and exported into nrrd format file. when I imported that into 3d slicer against a same volume, the segmentation is in a different place.
any idea on how to fix it or why it happens?
best
Tenzin
Both Slicer and ITK-snap saves images in physical coordinate system, so there should not be any misalignment.
Can you attach a screenshot?
How did you import the segmentation?
How did you load the grayscale volume? From DICOM or other file format?
Hi Lassoan, I would like to upload the snapshot here. 
And then I went to 3d slicer, dragged the file and uploaded as segmentation.
I loaded the grayscale volume in 3d slicer (just by doing load data) and the files are in dicom. Am I meant to be uploading the file as dicom? (that takes a very long time in 3d slicer to load).
best
Tenzin
Hi Lassoan,
actually I was able to do it correctly, seems like the volume that I used was wrong. I apologize.
furthermore I would like to ask an additional question, if I want to edit the segmentation in segment editor on 3d slicer (segmentation saved using ITK snap), how can I do that?
best
Tenzin
We more or less have the same problem. For our study we need a surface-mesh from a segmentation that was already done in Mimics.
Strangely enough Mimics doesn’t give you the possibility to make a real surface-mesh (it always does some sort of smoothing), so I exported the segmentation as a dicomserie and then imported the dicoms into Slicer.
Then I segmented the included Mimics-mask by choosing the proper theshold values. After that I saved the segmentation as an STL without smoothing.
But now, when I import the Slicer-stl back into Mimics, the resulting mask (in red) is offset by about halve the voxelheight in the Z-direction (see screenshot).
For our study it’s very important that the STL is exactly in the same coördinate system as the dicom!
We discussed this problem and the only thing we came up with for now is that it might be caused by where the application (Mimics, Slicer, …) defines the position of the Z-coördinate; at the top, in the middle or at the bottom of the voxel.
I don’t believe that that will be the case, because I think there are fixed rules for this in the dicom parameters. But we haved got a clue.
Who gave help us in this?
We can’t really debug Mimics here, but if you find any inconsistencies in the way Slicer handles coordinates please do let us know.
Best thing I can suggest is to create some very controlled examples (like a test pattern) and carefully go through each step in the pipeline to look for inconsistencies.
Hello Steve,
I’m not asking to debug Mimics (actually I want to stop using it) but I would like to know what causes this issue. Is it due to how segmentation application handle the dicom coördinates or is there another possible cause for this?
I already found out that the mask has exactly half the voxelheight of (slice thickness is 3mm)
What information object did you use (RTSTRUCT, segmentation, …)?
Can you share with us a sample input image (use a phantom or a publicly available sample data set) and exported segmentation?
Sorry lassoan, but I have no idea what you mean by RTSTRUCT. In Mimics I just use the export the segmentation within the dicom files and then in Slicer resegment them. How the exporting is done, they don’t tell you.
I also can’t give you the sample data for patiënt privacy reasons.
But can you tell what protocol dicom uses for x,y,z? Are there fixed rules for where x, y and z are defined (for instance within the same plane), or can it be that, depending the CT-scanner, the z can be of plane?
Please download a DICOM volume from anywhere (e.g., TCIA) and use that for these tests so that you can freely share the results.
According to [DICOM standard],(C.7.6.2 Image Plane Module) slice position corresponds to center of the voxel: Image Position (0020,0032) specifies the x, y, and z coordinates of the upper left hand corner of the image; it is the center of the first voxel transmitted.
Thanks for the information on the dicom coördinates. That was very helpfull.
In the meantime I’ve found what went wrong. It was caused by the fact that the segmentation was done in an older version of Mimics (version 14) and since version 16 they’ve updated their coördinate system.
So thumbs up for Slicer 
and another reason for me to avoid Mimics 
!
