Dear All,

I have been using T1 and T2 FLAIR images in W2MHS to determine the effective volume quantification of WMH. However, the results are not satisfactory and many gave NaN or attempted to access xx(1); index out of bounds because numel(xx)=0 as the result. I have tried to adjust the the parameters (cleaning threshold from 0.1-2.5 and probability map cut value 0.1-0.5) but again the final results are still the same. I have looked through the images as well and they should all shows WMH.

Is there anything wrong with the parameters? Or something else was wrong?

I have attached one of the data to illustrate the issue.

Thank you for your help.

Chris, we should be able to help. Give us a few days and we will get back to you after the long weekend. 

--Vikas

Hello.

Firstly, sorry about the late reply.

Does the final bin maps have NaNs or the intermediate ones have them ?

For the former one, just removing/neglecting these NaNs might do the job.
For later case, If I understand the issue correctly, the NaNs might be the result of bad pre-processing outputs (i.e., the GM, WM maps). These will be the intermediate files on which the detection tool works. To that end, the first thing to check would be NaNs in these maps.
Further, it seems that the images you have are unsusally bright, and hence changing around the hyper-parameters of the preprocessing might also help. Note that these parameters are different from the quantification ones.
Also, if there are atleast one/more cases with 'good' WMH images, and thereby reasonable effective volume measures, the corresponding imtermediate files of these good set of images can be compared to the bad ones for adjusting the parameters better.

If all the intermediate files look good to you, then there might be some other issue. And I may be able to help you out via command line debugging (where each step needs to be checked for errors!).

Hi,

I would like to ask for your help as I have encountered some problems in EV quantification. Its says:

Error using xform_nii>change_hdr (line 350)
Non-orthogonal rotation or shearing found inside the affine matrix
in this NIfTI file. You have 3 options:

1. Using included 'reslice_nii.m' program to reslice the NIfTI
file. I strongly recommand this, because it will not cause
negative effect, as long as you remember not to do slice
time correction after using 'reslice_nii.m'.

2. Using included 'load_untouch_nii.m' program to load image
without applying any affine geometric transformation or
voxel intensity scaling. This is only for people who want
to do some image processing regardless of image orientation
and to save data back with the same NIfTI header.

3. Increasing the tolerance to allow more distortion in loaded
image, but I don't suggest this.
To get help, please type:
help reslice_nii.m
help load_untouch_nii.m
help load_nii.m

Error in xform_nii (line 154)
[hdr,orient]=change_hdr(hdr,tolerance,preferredForm);

Error in load_nii (line 135)
nii = xform_nii(nii, tolerance, preferredForm);
Error in WhyD_preproc (line 101)
wm_mask = load_nii(sprintf('%s/c2rFLAIR_%s.nii',names.directory_path,names.folder_id));
Error in WhyD_setup (line 125)
if check_preproc_vals(n) == 0 names = names_stack{n,1}; names_stack{n,1} = WhyD_preproc(names, spmtoolbox_path); end
Error in WhyD_GUI>run_button_Callback (line 281)
WhyD_setup(arg0,arg1,arg2,arg3,arg4,arg5,arg7,arg8,arg9,2);
Error in gui_mainfcn (line 96)
feval(varargin{:});
Error in WhyD_GUI (line 28)
gui_mainfcn(gui_State, varargin{:});
Error in guidemfile/@(hObject,eventdata)WhyD_GUI('run_button_Callback',hObject,eventdata,guidata(hObject))
Error while evaluating uicontrol Callback

I have resliced the nii image (option 1) using NIFTI toolbox. Converted the hdr format back to nii and used W2MHS to calculate the EV volume again. It went smoothly and all the output nii images were fine but in the RFREG_ev_660t.txt shows that
Study: W2MHS Subject: 660t
EV: NaN
EV-Deep: NaN
EV-Periventricular: NaN

Why did it show NaN? Did I do something wrong?
I have tried to reslice a few subjects that gave the same error message but in the end, they all gave NaN as the EV, EV-Deep and EV-Periventricular too.

The attachment contains all the output files from W2MHS and reslicing of this study.

Thanks for your help.

It seems that the file is too large to be uploaded. So, I just attached a few of them.

Hello.

The issue with 'Non-orthogonal rotation or shearing found inside the affine matrix in this NIfTI file' pops up because the nifti file, when created, had some errors/corruptions in the header information.
I have faced such issues with the imaging data I work with, and more often than not, using load_untouch_nii (instead of load_nii) would solve the issue! (a.k.a the solution 2 above). Hence, look through the w2mhs code and use load_untouch_nii wherever necessary.
You can also check for more solutions on SPM archives (https://www.jiscmail.ac.uk/cgi-bin/webad...).

Hi,

I have tried using load_untouch_nii instead of load_nii. After that, used save_untouch_nii and ran the untouch T1 and T2 Flair on W2MHS. It doesn't seem to work for any of my images.
eg. nii=load_untouch_nii('sNACC489101-0004-00000-000124-01.nii')
     save_untouch_nii(nii, 'untouch1')

The same error message popped up:
Error using xform_nii>change_hdr (line 350)
Non-orthogonal rotation or shearing found inside the affine matrix
in this NIfTI file. You have 3 options.....

Are there any other suggestions?
I have attached one of my subjects' T1 and T2 Flair nii images just in case you would like to try.

Thanks again.

Anita

Anita, 

Let us look into it...we will get back to you soon. I am fairly certain we will be able to figure this out. 

--Vikas

Hello.

I have tried out few other options mostly suggested on SPM blogs, but looks like there is some corruption on the nii header itself (while they were saved as niis from DICOMs!). I am not sure what else can be done here. Pardon me, but I will keep an eye for other options and get back if I find any. Good luck!

Dear Vikas and Vamsi,

I see....Thanks for your help.

Dear All,

I have been using T1 and T2 FLAIR images in W2MHS to determine the effective volume quantification of WMH.
The results are not satisfactory:
EV: 0.000000
EV-Deep: 0.000000
EV-Periventricular: 0.000000

Is there anything wrong with the images? Or something else was wrong?
I have attached one of the images.
Thank you for your help.

Hello.

Thanks for your interest.
I think the problem is wit the fact that the hyperintense regions are mostly on the borders of WM and GM/CSF, and so in the extracted GM tissue map the WMH and non-WMH regions are `looking' the same. I would try changing the preproc parameters, reduce the bias correction parameter (all these are in _preproc.m file).
Do all your images end up getting zero detections? Or does this happen to few?

Hi,

this happens with all my images, just using the images of "W2MHS_Sample_Images" the results are satisfactory.

Thanks for your help.

Oh. I am sorry about that.
I would still go ahead and change around with the preprocessing parameters and the 'quantification' parameters that summarize the detections?
If the detections on the output image are OK, but the quantification is wrong, then mostly changing the quantification parameter (see help docs) would be fine.
If not, and all your images look like the one you uploaded earlier, then the hyperintensities are surely getting effect by bad preprocessing.

I noticed that my images have an absolute value between 0 and 1600 . I multiplied the originals images for 5, 10 and 15 . the results are satisfactory:

x5
EV: 258.732681
EV-Deep: 12.440582
EV-Periventricular: 246.292099

x10
EV: 511.133234
EV-Deep: 39.565074
EV-Periventricular: 471.568160


x15
EV: 504.888690
EV-Deep: 39.277380
EV-Periventricular: 465.611310


there isn't big difference using images for 5, 10 and 15. do you know why? Do you know what is the best number to do the multiplication?
I also converted the same multiplied images by int to float 32bit, and in this case the text file RFREG_ev gives all values "Nan". Do you know why?
Thank you for your help.

Hello.

I am glad that the issue was solved.One reason would be that there is some minimal scaling factor beyond which the regions are already too bright to be detected/processed with no issues.
This minimal factor might be smaller than 5 in your case, and hence the quantification for different factors that you chose are all close.
Although there is no 'optimal' way to choose the scaling-up factor (5 vs. 10 vs. 15 in your case), I wonder if the best one might be chosen visually on 1-2 images/detections?
Since, this is a post-hoc check, and the variation in quantifications are minimal, the results would be valid for any down stream analysis.

The NaN issue comes from the Matlab typeset for exporting/importing a text file from mat files (or Matlab's workspace). There might be other reasons, but feel free to convert number precisions as needed since this has nothing to do with the detections. Thanks!

Hello,

I am trying to figure out the bug that gives the following values:

EV: 0.000000
EV-Deep: 0.000000
EV-Periventricular: 0.000000

I also tried using bias fwhm 60, 80, 150, but still got the same values. Would anyone be able to suggest the possible error? Thank you in advance.
Best,
Ganesh

Does the detection show up on the image? I mean to ask, do the *RFREG_* nii image have the detections.
If so then there is some issue in the quant file, else the issue is in the preprocessing itself.
Also, please note that some issues have been pointed out by a user a few months ago which were corrected and the new codes uploaded (see alternate forum message) -- to that end, please make sure that you are using the new toolbox and not the old ones.

Hi Vamsi,
Thanks for your response.
There is no detection on the RFREG_*nii and I am using the version v2.1. Does this mean there is a problem in preprocessing?If so, could you please suggest the possible places?
Thanks,
Ganesh

Yes it does.
Are all your images not showing up any detections? If so, then changing pre-processing parameters might help. Please see documentation on how to change these and other important parameters relevant for the detection.
If one or few are having such issues, then I am not sure if pre-processing is the issue. In this later scenario the algorithm is not robust enough to pick these outlier images.