Fiber measure tests failing due to differences due to differing baseline data about slicerdmri

[jhlegarreta]

Also, the column names have spaces around them, but the data is tab separated:

SlicerDMRI/Modules/CLI/FiberTractMeasurements/Testing/CMakeLists.txt

Line 23 in 372675b

--separator Tab

Steming from

SlicerDMRI/Modules/CLI/FiberTractMeasurements/FiberTractMeasurements.cxx

Line 544 in 372675b

ofs << " " << SEPARATOR << " " << it2->second;

SlicerDMRI/Modules/CLI/FiberTractMeasurements/FiberTractMeasurements.cxx

Line 552 in 372675b

ofs << " " << SEPARATOR << " " << it2->second;

and maybe

SlicerDMRI/Modules/CLI/FiberTractMeasurements/FiberTractMeasurements.cxx

Line 552 in 372675b

ofs << " " << SEPARATOR << " " << it2->second;

SlicerDMRI/Modules/CLI/FiberTractMeasurements/FiberTractMeasurements.cxx

Line 605 in 372675b

ofs << " " << SEPARATOR << " ";

Extra spaces should not be added, because they make any automatic processing on the tables much more complicated.

Being addressed in PR #171.

[pieper]

default RAS vs. LPS convention

FYI @jhlegarreta - with Yogesh and Lauren we decided that FiberBundles are always RAS. See

SlicerDMRI/Modules/Loadable/TractographyDisplay/MRML/vtkMRMLFiberBundleStorageNode.cxx

Lines 25 to 29 in 372675b

	vtkMRMLFiberBundleStorageNode::vtkMRMLFiberBundleStorageNode()
	{
	this->DefaultWriteFileExtension = "vtk";
	this->CoordinateSystem = vtkMRMLStorageNode::CoordinateSystemRAS;
	}

[jhlegarreta]

FYI @jhlegarreta - with Yogesh and Lauren we decided that FiberBundles are always RAS. See

Yes, I recall some past RAS vs LPS issue, and although I mentioned it, it is only another hypothesis; I ignore how the baseline data was generated.

[jhlegarreta]

The same differences are observed when computing the measures using the GUI in 3D Slicer 5.2.2.

The relevant classes in SlicerDMRI have not been modified in the past few years (e.g. no relevant changes in the past 7 years in https://github.com/SlicerDMRI/SlicerDMRI/blame/master/Modules/CLI/FiberTractMeasurements/FiberTractMeasurements.cxx).

Following #123 (comment), 3D Slicer 4.11 and SlicerDMRI commit a7a9bdd is the last known version where tests were passing.

So, checking out that commit and seeing if tests pass (even against a recent, e.g. HEAD, 3D slicer version) might be worthwhile.

Otherwise, a non-negligible amount of work will be needed to investigate whether differences introduced in 3D Slicer since version 4.11 (versions around 2020/09/30 or 2021/02/26) have somehow impacted that the fiber measurement computations in SlicerDMRI.

[jhlegarreta]

Checking out a7a9bdd (last commit in the PR #123 commit series) does not compile; the most recent commit after that compiling is d1b8f17 (with some manual workaround in qSlicerTractographyInteractiveSeedingModule::helpText to avoid Slicer_VERSION_MAJOR and Slicer_VERSION_MINOR being sought).

At d1b8f17, the tests still fail, giving the exact same results as they give with the current HEAD.

Inspecting the commit history in SlicerDMRI, the only major change that may have impacted the measures seems
5902dee#diff-c04d96ea387b465cf4fc784b01112a62b6256677e69d2024abad79d1238467b1R28

However, commenting out that line does not make tests pass.

Otherwise, the only relevant change to the classes actually performing the computations, FiberTractMeasurements or vtkDiffusionTensorMathematics, seems to have been:
Slicer/Slicer@3a4f3cb

Or maybe fe29099, but it does not seem likely that random numbers are involved in the computations (e.g. like to downsample the number of streamlines or vertices - each test file has only a handful of streamlines).

So there is some other issue.

Tests have been known to be failing since early April 2023, at least.

We should create some basic tests using data whose DTI features we know very well (e.g. spheres, ellipsoids, etc.), otherwise this looks hard to solve without more context.

[jhlegarreta]

Baselines will need to be updated after PR #171 has been merged.