Previously aligned volumes no longer aligned in the pre-release version. It’s kind of obvious and since it’s “pre-release” I wonder if it is a known issue.
Steps to expose the bug: load a volume and place a fiducial. Using the Orient Scalar Volume module and perform some random orientation a couple of times and you will find the volume shifted.
which specific version of the preview release are you using?
What is your reason for using the Orient Scalar Volume?
What do you mean by “perform some random orientation”?
What is your overall goal?
I am using the latest Linux pre-release download from the website (2024-05-03).
I am not using Orient Scalar Volume for any particular purpose I just found out the bug can be easily observed this way. Just choose some different orientation and hit apply and sometimes the volume shifted.
I compared to load a same volume in v5.6.2 and v5.7.0 and they show different transformation matrix and scan order between these 2 versions. Sometimes after I transformed a volume and when I saved and reload the scene the volume also shifted.
I found there is a new Center of transformation option under Transform module and there is possibly some rework to the transformation and this bug could be resulting from that.
Trust me I have used Slicer for a long time. There is definitely something fundamentally wrong with current developmental release.
We trust you, but you need to more concretely describe the steps, and provide screenshots of it for us to undertand and reproduce the issue. If we can’t reproduce, it is hard to fix.
I am providing two volumes. You will find them aligned together in v5.6.2 but not in v5.7.0.
Also I tested them in MRView from MRTrix and they also aligned.
If you use NIFTI format then all bets are off. In this format the image oroentation can be defined in redundant and inconsistent ways, which is interpreted differently in each software. It is really a shame that we need to deal with such basic issues, but many people in the neuroimaging community just uses a few software, so they are not aware of these serious issues around NIFTI; and many newcomers to the medical imaging field don’t know just how bad NIFTI is, so it remains widely used and it wastes everyone’s time.
Slicer uses ITK toolkit to read NIFTI images and so it will load such images the same way as every other ITK-based software. It seems that you would expect ITK to load your images differently, so the best would be to post it to the ITK forum. They will explain why ITK loads your images differently compared to MRTrix. Maybe invite MRTrix developers to the discussion, too, and let them come to an agreement. If major imaging libraries resolved inconsistencies in NIFTI images the same way then NIFTI users would suffer less.
Thanks for reporting @Peng_Wang - I can reproduce this by comparing 5.6.1 to recent preview build. In this case I don’t think nifti is to blame, but something has changed in Slicer, presumably with the latest version of ITK.
It’s a serious regression, so we should get to the bottom of this asap.
I’ve filed an issue here:
It’s easy to reproduce and the CLI uses nrrd, so there’s something else going on.
While all the problems with NIFTI format still holds, I agree that in this case something else is going on with IntraOp2T1_Warped. The file uses a left-handed image coordinate system, which is uncommon, but it is still valid. It gets normalized to a right-handed coordinate, which would be good, but this normalization seems to be computed incorrectly.
The culprit is probably this change:
I should have suspected that it was wrong, because images should only be ever transformed with homogeneous transformation matrices, never with just flipping.
The problem is not only with the volume IntraOp2T1_Warped. Sometimes when I load back the volume saved by Slicer itself it also shifted. Also as shown by Pieper above you can reproduce the bug using Orient Scalar Volume not dealing with any on-disk files.
PS. Also I tried with the latest ITK-SNAP 4.2 (Apr 22, 2024) it also displayed the volumes correctly.
PPS. I remember this problem only showed in recent build. Using the download page url offset parameter I am trying to pinpoint the problematic build:
it’s somewhere in between [revision 32753 built 2024-03-15 ] and [revision 32789 built 2024-04-02 ].
As I suspected it’s also when the “Center of Transformation” started to show up in the Transform module.
The problem is the change that I pointed out above. When an image with left-handed IJK coordinate system is encountered then the K axis is automatically flipped to turn it into a right-handed coordinate system. However, the computation of the new image origin was incorrect. I’ll submit a pull request with the fix today.
The fix is available in this pull request:
Probably it will be available in the Slicer Preview Release within a few days.
When I looked at my other problematic volumes they are indeed left-handed too. And when Slicer save them they remained left-handed. So thank you, this should fix it.
The fix has been merged, so Slicer Preview Release that is downloaded tomorrow or later will include it.
