-
Notifications
You must be signed in to change notification settings - Fork 19
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
Incorrect orientation of exported meshes #11
Comments
This reflects the fact that DICOM uses LPS while NIfTI uses the RAS coordinate system. This tool (as well as Surfice and NiiVue) uses RAS Talairach_coordinates popular in neuroimaging (e.g. NIfTI, GIfTI, TRX, etc), whereas Slicer3D defaults to LPS. To demonstrate the behavior, convert the AIL.nii.gz image, where the columns, rows and slices are saved to disk as posterior->anterior, superior->inferior, and right->left respectively (alternatively, try any of the 48 combinations) using nii2mesh. Drag and drop the resulting obj mesh onto the NiiVue worldspace demo and click the You can further investigate the polarity by leveraging the fact that the OBJ format is a text format, and you can edit the first line of the text file to change the spatial position of the first vertex, which is initially
Doing so, you can see that NiiVue interprets the first component as ascending rightwards, the second component as ascending anteriorly, and the third component as ascending superiorly. Therefore, the mesh uses the same RAS coordinate system. To resolve the issue, choose use the |
Thank you for a very detailed explanation. As I understand it, nii2mesh exports meshes to RAS coordinate regardless of the input coordinate system. Is that correct? Given that the meshes don't carry coordinate or affine information, it would be up to downstream users to ensure the correct coordinate system. |
Yes. To clarify: nii2mesh reads NIfTI images which uses the RAS coordinate system. The NIfTI header orientation information is used to transform the voxels to vertices specified with RAS coordinates, regardless of the order that voxels are saved to disk. |
I totally understand this part. The reason I said this:
is because that my input NIfTI file has LPS orientation (converted from DICOM using SimpleITK). The LPS orientation is confirmed with nibabel: import nibabel as nib
img = nib.load(nii_file)
print(nib.aff2axcodes(img.affine))
# ("L", "P", "S") So is it safe to assume that |
Yes. The nii2mesh mesh vertices are always RAS, regardless of the order that input voxels are stored to disk. Note that NIfTI always describes world space as RAS, and there are logically 48 combinations that data can be stored to disk. The NIfTI header spatial transformation(s) map voxel to world space. One little wrinkle is that the NIfTI header can store two independent spatial transforms: the quaternion-based QForm and the matrix-based SForm. Similar to most tools, when both are specified my tools give precedence to the SForm. However, be aware that at least historically VTK tools gave precedence to the QForm. I believe this was because those tools could not store the shear of rhomboidal volumes (the SForm has 12 degrees of freedom while the QForm has 9). |
Thank you so much and have a good day. |
Hey, thank you for making and publishing nii2mesh. I'm a big fan of your works (using NiiVue for open visualization).
I've notice that the generated meshes from nii2mesh is in a different orientation comparing to the voxel orientation. I need to perform a 180 degrees rotation around the Z axis in local coordinates of the object* for correction.
I've tested and confirmed with different files having these original affine: RAS, LPS and LAI.
Example file:
bet.nii.gz
provided onnii2meshweb
demo.You could download it here bet.seg.nii.gz
nii2mesh
:Output bet_1.ply.zip
Green is segmentaiton visualization, yellow is model:
Happy to provide any more details that you need.
The text was updated successfully, but these errors were encountered: