Then we realized that sometimes there is an empty section on the first or last slide of a tensor image.
I overlaid the tensor image on the unbiased image.
OK, when you see ? as the voxel value, that means a NaN or an Inf. Presumably the tensor fit encountered negative values or something like that and taking the log caused a NaN or -Inf to be produced. What I don’t understand is how that could happen given that I thought we’d fixed all the ways that could happen…
Can I just check which version of MRtrix you’re using? Use dwi2tensor -version to get that information. This could happen if you’re running an older version…
== dwi2tensor 3.0.2-2-g537bd000-dirty ==
64 bit release version, built Oct 13 2020, using Eigen 3.2.92
Author(s): Ben Jeurissen (ben.jeurissen@uantwerpen.be)
Copyright (c) 2008-2020 the MRtrix3 contributors.
This Source Code Form is subject to the terms of the Mozilla Public
License, v. 2.0. If a copy of the MPL was not distributed with this
file, You can obtain one at http://mozilla.org/MPL/2.0/.
Covered Software is provided under this License on an "as is"
basis, without warranty of any kind, either expressed, implied, or
statutory, including, without limitation, warranties that the
Covered Software is free of defects, merchantable, fit for a
particular purpose or non-infringing.
See the Mozilla Public License v. 2.0 for more details.
For more details, see http://www.mrtrix.org/.
I also checked the intensity of my dwi_den_unr_pre_unbia_up.mif image. The intensity values are positive.
OK, that’s the latest version – though I note the dirty label on the version string indicates the code has been modified in some way. Any reason why that might be? What does git diff report (when run within the MRtrix3 install folder)?
Did you check all volumes? A negative value in any one volume may cause trouble…
OK, nothing to do with the dwi2tensor code, so that rules out that as the issue. I’ll have a look through the code again to see under what conditions NaNs might be produced.
OK, to help narrow down the range of possibilities, can you try running the dwi2tensor call with the -iter 0 option, and again with the -ols -iter 0 options, and check whether either of these make any difference to those NaNs…?
I’ve tried both of them and there’s no difference compared to the previous picture.
But thanks to the suggestion came from @bjeurissen, we disabled the interpolation and found that these empty voxels are negative.
May I ask what is your suggestion when we come across this kind of data? Should we discard the last slide or do something else?
Thank you for the helpful suggestion. The interpolation is one of the problem, now the other problem is there are some negative value voxels in the first slide of the unbiased image. Do you have any suggestion to solve this problem?
OK, now I’m confused as to what is going on exactly…
When you say the voxels are negative, I assume you’re talking about the raw DWI? These voxels are still NaN in the DTI coefficients image, right?
If that’s the case, and neither of the alternative fitting options I suggested made any difference, then the only way I can think of that would result in NaNs would be that all volumes in the whole DWI series are negative in that region…
If that’s the case, there’s not much that we can do here: the tensor model can’t handle negative values, and in many ways NaN is the right answer. But if you want to try to ‘fix’ that, we could change this line (cmd/dwi2tensor.cpp:140) to read:
That would ensure the log transform still returns non-NaN values. But there’s still no guarantee that the subsequent tensor fit will produce anything sensible. Indeed, it can’t do anything sensible in this case, but it might at least not produce NaNs…
If you want to try it, edit that file as above, run ./build again, and see if it makes any difference.
Let me try to be more clear.
When I say that voxels are negative, I’m talking about pre-processed DWI.
We did “dwidenoise”, “mrdegibbs”, “dwifslpreproc”, “dwibiascorrect” and “mrgrid” on the raw DWI data and then used this pre-processed image to achieve the DTI coefficient images.
Yes, these voxels are still NaN in the DTI coefficient image.
In the raw DWI image and the intermediate images created during these pre-processing, I also checked the region where are NaN in DTI coefficeint image. In the images after dwidenoise or mrdegibbs, the values of this region are still positive. After dwifslpreproc or dwibiascorrect, the values of this region are 0. But after mrgrid, the values of this region are negative.
I think the issue originates in dwifslpreproc, which causes the last slice to be all zeros for some reason. @rsmith: does this have anything to do with padding when there is an uneven number of slices?
Also, this is the first time you mention mrgrid… I suspect this is where the negative values get introduced… Why is this used? Are you using it to upsample before model fitting?
In all I think there is nothing wrong with dwi2tensor. Like @jdtournier mentioned, if you feed it all negative values, a nan tensor is probably the sensible thing to return.
I think the issue originates in dwifslpreproc, which causes the last slice to be all zeros for some reason. @rsmith: does this have anything to do with padding when there is an uneven number of slices?
Not any more it shouldn’t. The data get padded so that topup runs with the default config file, and then the padded slice is stripped off. So output should be agnostic to that process.