New scripts for conversion, comparison and testing

[frheault]

4 new scripts (python) that will help to go back and forth between formats.
tff_verify_header_compatibility.py For NIFTI, TRK and TRX only, compares header informations (affine, dimensions, voxel sizes and voxel order) and inform the user about their compatibility
tff_simple_compare.py Subtract two tractography files in RASMM, VOXMM and VOX and inform the user about their similarity (point to point distance). Does not support tractograms with different streamline count or streamline shuffling (very simple comparison)
tff_visualize_overlap.py Load a tractogram, compute density maps (using 2 approach in Dipy) and render the density map and its bounding box (see below). 3 Rendering will be displayed (RASMM, VOXMM, VOX). If there is an incompatibility between the header and the coordinates the density map computation will crash OR the tractogram won't appear in the right position.
tff_convert_tractogram.py Script to convert from one to another file format (.trk, .tck, .vtk, .fib, .dpy, .trx)

• It is expected that a trx/trk should have a matching header with a NIFTI file from which they were generated. tff_verify_header_compatibility.py should help to verify this.
• Conversion from any file format to another should not make tff_simple_compare.py fail
• mrview or MI-Brain should be used to double-check if tck/trk align with their respective FA (both only work in RASMM)

Files and commands to test this PR:
https://drive.google.com/file/d/1vt9GWy--gRU5sYfgfe-qgFQyN2DHYyQQ/view?usp=sharing

[arokem]

Overall, looks great! One general comment/question: would it be possible to implement these functionalities as library code and then make the scripts import and execute this library code? I think it will make it useful in other contexts, easier to test, and also might help reduce some boiler-plate. For example, it would be good to have a supported_formats variable implemented as a module-global variable and test inputs against this variable, so changes only have to be introduced one place, and so on.

[frheault]

@arokem So just to be sure, you would put 100% of the main inside of a function and make that function receive only the string (filenames) as parameters? And the behavior would stay the same?

[arokem]

you would put 100% of the main inside of a function and make that function receive only the string (filenames) as parameters? And the behavior would stay the same?

Yeah - that would be good. If you put them all in the same module, you can start consolidating some of the boiler-plate, e.g., defining supported file-types and checking inputs and so on, and use shared test harnesses (eventually)

[frheault]

@arokem Is this ok for now? The visualization scripts are not tested because they are just rendering.
But the conversion is tested and datatype too. That's the most important part first.

[arokem]

Yeah - I think that we can go ahead and merge this.

I have some ideas for subsequent cleanup and tweaks that we can do -- I'll post some issues.

But for now, let's merge this and move ahead with this.