Ivadomed: Project hierarchy is prone to circular dependencies

[Drulex]

Circular dependencies occur when module_a depends on module_b and module_b also depends on module_a (https://stackabuse.com/python-circular-imports/).

While looking at #484 I noticed that __ivadomed_dir__ is defined in multiple places in the project and proposed to clean it up, but while doing so I uncovered some problems especially in utils.py:

• utils.py is doing too much. Classic problem of this type of module (see https://github.com/neuropoly/spinalcordtoolbox/issues/2898).
• utils.py is importing 6 other ivadomed modules. Usually utils.py is something that provides non-specific/general helper functionality. It is the kind of module that is at the bottom of the import hierarchy. By depending on these 6 modules we now need to be careful that they do not depend on utils.py in the future, otherwise it may cause circular dependencies (e.g https://github.com/ivadomed/ivadomed/pull/484/checks?check_run_id=1309819496)

To avoid these types of problem it is good to have a proper dependency hierarchy: i.e a depends on b and b depends on c, everything can depend on c, but c cannot depend on a or b...

It is probably a good idea to:

• refactor module-specific functions in the appropriate module (e.g get_metric_fns(), why is that in utils and not metrics.py?)
• evaluate if what is remaining makes sense to exist in utils.py or if a dedicated module should be added (image.py maybe?)
• further split utils.py if necessary (although I doubt it would be the case here).

[Drulex]

relates to #489

[lrouhier]

After a first discussion this is what we come up with:
create new files:

• image.py: reorient_image , convert label to RGB
• uncertainty.py: run_uncertainty, combine_predictions, voxelwise_uncertainty, structurewise_uncertainty
• mixup.py : mixup, save_mixup_sample
• inference.py: pred_to_nib, segment_volume, volume_reconstruction, onnx_inference
• visualization.py: animated_gif, looping_Pillow_writer, overlap_im_seg

Move function Get_metric_fns to metrics.py

We should do this refactoring before working on the HDF5 refactoring.

[lrouhier]

Update: This is well started in PR #497.
there is now 568 lines in utils.py (vs 1249 before).

I decided to leave convert_label_to_RGB in utils.py because this has more to do with tensorboard image than with regular image.
There are at least 3 functions that are used to generate or work with tensorboard images (save_tensorboard_image, convert_label_to_RGB, save_colors_labels ) Should we move them to a separate file as well?
@andreanne-lemay @olix86 @charleygros any opinion ?

[charleygros]

There are at least 3 functions that are used to generate or work with tensorboard images (save_tensorboard_image, convert_label_to_RGB, save_colors_labels ) Should we move them to a separate file as well?

What about in visualization.py?

[lrouhier]

Visualization appears to be a good idea! 👍