Strange MD and FA values in preclinical rodent data

Greetings DIPY experts, I'm Javier Arcos Hódar, a research assistant based on the Alberto Sols Institute for Biomedical Research on Madrid. I've been tasked to investigate other software for MRI data processing in case we end up having problems with our homemade Matlab software. First of all I'd like to be thankful for the developing of DIPY, since it seems to work faster, is fully open with helpful tutorials online and provide options our homemade software doesn't. Unfortunately I might be mismanaging something since even for the very simple task I wanted to start with (exporting AD, MD and FA maps) it's giving me some problems. I'll offer my files and anaconda spyder workspace in case it is helpful. We use 2 basal images, 2 b values beyond basal (~300-~1200) and 7 directions: https://www.mediafire.com/file/512di21tmeb9av3/javierdipymailquestion.rar/fi... Note b table and directions are directly in the workspace; I got annoyed trying to import them as the tutorial says due to an error of not formatting the text file properly and created a matrix of the same dimensions and entered the values manually as python objects. To clarify, the files from our alternative software are not a .nii stack but can be opened on imageJ under (checking CorteX folder, not the CorteX Config folder) Import -> Raw -> DTI_FA_Raw, with settings (I think those are the default but please double check to avoid problems) -image type 64-bit Real -Width and Height 128 pixels, -offset of first image 0, -number of images 1, -gap between images 0 bytes, and -only little-endian byte order ticked on, with the three other settings on blank. Inferred eigenvalues and eigenvectors can be checked in the DTI_Data txt file for each 'corte' (slice). I picked two example subjects were nearly every voxel had a curve fit above >75 just to try and make certain noise/phantoms Three issues are obvious: -MD values for each voxel appear a million-fold lower than in our Raw files but otherwise quite closely aligned. The most obvious, but perhaps wrong, explanation is that they are given in cm²/s instead of µm²/s as the output of our other software. This is a bit strange to me, as in: is some information missing from the way I imported the data that SI units are used, or is clinical human data typically given in cm²/s? It's not hard to solve this, whether in fslmaths or probably within dipy, but still raises my concern. -Fractional anisotropy values are more problematic. Taking a rough whole-brain ROI in ImageJ and dropping NaN values in to compare first slice of rat 19 in R, the difference averages .0837, which is big compared to the actual values and their variability. Moreover, it seems mostly driven by values that ought to be high, in ventricles or the dead core of a brain tumour (.30 or greater) instead becoming wildly high (>.50 or >.60) to the point it probably isn't accurate or biologically plausible. See for example Li XY et al (2017) https://www.sciencedirect.com/science/article/pii/S1995764517304492. I completely ignore the cause for this; I might be misunderstanding something but if it's a variance, multiplying everything by the same number shouldn't drive big differences in values, so the previously mentioned MD thing shouldn't be driving this. I get a >.8 correlation between difference between software output and dipy value, so I'm pretty sure still the problem really is curve fitting in high values, but I'm at loss at how this would be solved, something like scipy.optimize.curve_fit? -Checking the manual, (https://dipy.org/documentation/1.4.0./reference/dipy.reconst/) it seems ADC values are only offered voxel by voxel, without an obvious way to run it over the whole image. This causes me a bit of trouble comparing them for each direction to try and find the cause of the problem. It wouldn't be too hard to make it iterate over all voxels but I'd like to know if there's an inbuilt way to do this instead. We use two basal images per slice, and I understand that just having 0 b values would make DIPY interpret them as this, but perhaps the way to handle them (beyond simply averaging them?) could also cause differences? I don't know, but since similar issues have happened trying other software (dsi studio, track vis) I was hoping to check if in this more open software with community support the issue can be diagnosed/corrected. Lastly, note that I didn't use mask in the workspace provided since for our resolution and number of directions processing isn't too computionally demanding and the curve-fitting is done voxel by voxel anyway, but masks are provided in the folder in case someone wants to use them (it would remove the ugly background in the final nifty files at least) Thanks in advance
participants (1)
-
jarcos@iib.uam.es