Hello,
To check the quality of a registration DWI / T1, I used the mrview overlay function.
However, I noticed that even when using an identical image (same image in main load and overlay), the two images are slightly offset. The same procedure does not produce this bug with FSLeye.
is it a bug or error?
Thank you !
Hi @gmazo,
I can’t reproduce this – everything seems OK on my system. Can you provide screenshots of the problem, and state which version of MRtrix (as reported with e.g. mrview --version), and which operating system you’re using?
Thanks,
Donald.
Hi @jdtournier
mrview --version :
== mrview 3.0.2 ==
64 bit release version, built Sep 30 2020, using Eigen 3.3.7
I’m not sure where the problem is exactly? As far as I can tell, these two images are not the same: one has been warped slightly in a non-linear fashion. The outline of the images is pretty much spot on though, so there’s no obvious bulk offset of the overlay relative to the main image?
This is more easily appreciated by switching between the images, as shown in the gif below (generated from your screenshots):
Actually, on second thoughts, if these genuinely are the same image, this is probably due to the way the slice is positioned in different modes of operation. And yes, I can see that it would be confusing. To expand:
By default, the main image is opened in mrview in ‘lock to image axes’ mode. What this means is that the viewer will display a single slice through the grid of image voxels that cuts through along the axes of that grid – no angulation relative to the grid. The reason for this is that this means we only need to load the relatively small amount of data needed to render a single slice, which allows mrview to be used to rapidly inspect data very interactively. This also means that the slice being displayed will be the slice nearest to the current ‘depth’ of the crosshairs (I hope I’m making sense here).
You can switch to fully arbitrary angulation by ticking off ‘lock to image axes’ (the button with a grid and lock on the main menubar). This then allows arbitrary angulation of the image plane being displayed, and arbitrary position of the depth of the slice. In this case, the full volume needs to be loaded onto the GPU and the render then cuts through that dataset at the desired angle, with the values obtained via tri-linear interpolation (by default).
The overlay image is always loaded as above (i.e. without ‘lock to image axes’) – this is because we can’t in general guarantee that the axes & voxel sizes of the overlay will match that of the main image exactly. So in this case, what you can get if the depth of the cursor isn’t exactly in the middle of the slice being rendered, is that the main image is displayed as the nearest slice, while the overlay is displayed at exactly the expected slice location (with values interpolated across the two neighbouring slices).
In short: if you untick ‘lock to image axes’, you should find that the results match exactly… I hope all this makes some sort of sense!
Yes it is indeed the same T1.nii. The problem does not appear directly when I load the image from a new mrview window. It is when I have loaded several images that a lag begins to appear, including sometimes on the initial image which was not concerned at the beginning.
However, the solution without ‘lock to image axes’ solves the problem. Thanks very much !
