@astrofrog implemented a way to take an affine transformation matrix derived from a Nifti (.nii, .nii.gz) file's header and use that to translate pixel coordinates into world coordinates for Glue's image viewers. This is a good start, but there are a few problems remaining:
1) glue-medical is currently unable to load 4D+ volumes because of the coordinate transformation. It looks like trying to apply the 4x4 affine matrix to 4D+ volumes causes a dimension mismatch error. To me, there's two ways to go forward.m based on the fact that 4x4 affine matrices are only supposed to affect the first 3 spatial dimensions. One is to cleave off the the extra dimensions before doing any processing, and then add them back afterward. The other is to pad the 4x4 affine matrix into NxN affine matrices with identiy row/columns for dimensions above 3. I'll try out both, but they seem a little messy, and may not be able to deal with 2-D medical data all that well..
2) It looks like translation part of the affine matrix may be a little bit off. Comparing the MRBrainTumor2 volume between Glue and 3DSlicer, I notice that Glue's pixel-to-world calculations always start counting slices at 0 and then moving in the positive and negative direction respectively. In contrast, on Slicer, the same data has the first slice somewhere already in the negative/positive spectrum. Something to think about when implementing the above..
@astrofrog implemented a way to take an affine transformation matrix derived from a Nifti (.nii, .nii.gz) file's header and use that to translate pixel coordinates into world coordinates for Glue's image viewers. This is a good start, but there are a few problems remaining:
1) glue-medical is currently unable to load 4D+ volumes because of the coordinate transformation. It looks like trying to apply the 4x4 affine matrix to 4D+ volumes causes a dimension mismatch error. To me, there's two ways to go forward.m based on the fact that 4x4 affine matrices are only supposed to affect the first 3 spatial dimensions. One is to cleave off the the extra dimensions before doing any processing, and then add them back afterward. The other is to pad the 4x4 affine matrix into NxN affine matrices with identiy row/columns for dimensions above 3. I'll try out both, but they seem a little messy, and may not be able to deal with 2-D medical data all that well..
2) It looks like translation part of the affine matrix may be a little bit off. Comparing the MRBrainTumor2 volume between Glue and 3DSlicer, I notice that Glue's pixel-to-world calculations always start counting slices at 0 and then moving in the positive and negative direction respectively. In contrast, on Slicer, the same data has the first slice somewhere already in the negative/positive spectrum. Something to think about when implementing the above..