Have a function that automatically fills the DB if the file architecture fits our conventions

[jcohenadad]

e.g., if someone adds files with the following convention (see below), then the DB is automatically updated:

  |- center_study_subject
      info.dcm --> single dicom file (e.g. could be from the localizer) which includes useful info in the header, such as scanner type, model, subject demographics, center, etc.
      subject.txt --> csv formatted as follows: pathology=XX,
      |- t1
        |- t1.nii.gz
        |- t1_seg_manual.nii.gz
      |- t2
        |- t2.nii.gz
        |- t2_seg_manual.nii.gz
        |- t2_labels_disc_manual.nii.gz
      |- t2s
        |- t2s.nii.gz
        |- t2s_seg_manual.nii.gz
        |- t2s_gmseg_manual.nii.gz
      |- mt --> note that if a sequence has the suffix "_reg", it means that it is inherently registered with the sequence without "_reg", and hence the ground truth segmentation can be used for all contrasts within this folder
        |- mt1.nii.gz (or mt1_reg.nii.gz)
        |- mt0.nii.gz (or mt0_reg.nii.gz)
        |- t1w.nii.gz
        |- t1w_seg_manual.nii.gz
      |- dmri
        |- dwi_moco_mean.nii.gz
        |- dwi_moco_mean_seg_manual.nii.gz
        |- b0_moco_mean.nii.gz --> inherently registered with dwi_moco_mean.nii.gz, hence dwi_moco_mean_seg_manual.nii.gz can be used as ground truth segmentation

[fperdigon]

I noticed that the file structure of our dataset is similar to BIDS.
Maybe we can consider adopting that format to store our data. There is an official lib for python to manage data stored in that format. This is becoming a standard, a lot of datasets are using it ie all openNeuro and openfMRI datasets.
Here some info
http://bids.neuroimaging.io/
https://github.com/INCF/BIDS
https://github.com/INCF/pybids

[jcohenadad]

@fperdigon we have already looked at this possibility, but BIDS is not compatible with qMRI in general (e.g., separate folder for mt). More info there: qMRLab/qMRLab#206

moreover, this would mean changing the physical organization of the folders and we don't have the human resource to do this task.

[fperdigon]

@jcohenadad I think it would be good to also include the vertebral labeling files in this convention. What suffix could we use? vert_lab? ivds_lab?
I would also like to add that based on the API Python client I can generate a python code that works for this type of convention.

[jcohenadad]

@fperdigon great idea. How about: xx_labels_disc_manual.nii.gz?
just to be on the same page, these are points at the posterior tip of discs, right?

[fperdigon]

@jcohenadad it seems good to me. Maybe it would be good to specify that it is the posterior tip of discs, i.e. xx_labels_disc_post_manual.nii.gz

[jcohenadad]

@fperdigon i would not specify, because it opens the door to the possibility of having different ways of doing the disc labeling, which means, big confusion in the future.

i would rather stick to ONE way of doing the disc labeling, and document this everywhere (it is already documented in sct_register_to_template) with pictures. agreed?

[fperdigon]

Agreed 👍

[fperdigon]

In addition to the file structure, I think it would be good to define what information will be extracted from the dicom files and the format of the information in the .csv file