Create testing dataset

[lrouhier]

This PR aims at uploading testing data used in the ivadomed testing suite

Images and files:

• sub-XXX --> Bids folder with multiple contrast (T2w,T2star and T1w)
• derivatives/sub-XXX --> derivatives folder with seg-manual labels for all contrasts, labels-disc-manual labels for T2w, lesion-manual label for all contrasts (dummy seg),
• bounding_box.json --> dictionnary to test certain function from the bounding_box.py file
• dataset_description.json --> needed file to descript dataset
• participants.csv --> table with subject names and potential metadata
• config file for train/test command --> We need to separate the 2 (it's json files so it does not take much space)
• temporary_results.csv --> Used to test ivadomed/scrip/compare_models.py

Subject used is sub-unf01 from https://github.com/ivadomed/data_example_spinegeneric
derivatives/labels/sub-unf01_lesion-manual.nii.gz are dummy seg. The goal is to use seg_manual as a ROI and lesion-manual as target.

[jcohenadad]

@lrouhier which one was used?

• https://github.com/spine-generic/data-multi-subject
• https://github.com/spine-generic/data-single-subject

[jcohenadad]

@lrouhier to squeeze size, can you:

• resample to 1mm in-plane
• convert to float32

[jcohenadad]

In the readme: indicate the changes to the dataset (e.g., sub-selection of subject, processing, etc.)

[lrouhier]

@lrouhier to squeeze size, can you:

• resample to 1mm in-plane
• convert to float32

done and previous commit has been squashed to reduc repo size. Repo size is now 33 mb.

[lrouhier]

@jcohenadad I think it is ready

[jcohenadad]

it says "sub-test001" in the bounding_box_dict.json file

[lrouhier]

Changed in 9bce745

[jcohenadad]

images have 80 slices, which seems unnecessarily large. Even when testing 3D kernels, this is probably an overkill. Why not cropping to 10 slices? we will reduce the size from ~30MB to ~4MB.
that's a lot of BW we can save given that those testing data are being downloaded for each CI run (ie. multiple times a day)

[lrouhier]

images have 80 slices, which seems unnecessarily large. Even when testing 3D kernels, this is probably an overkill. Why not cropping to 10 slices? we will reduce the size from ~30MB to ~4MB.
that's a lot of BW we can save given that those testing data are being downloaded for each CI run (ie. multiple times a day)

Yes will do and squash the commit that created the file to have a lighter repo. I'll add the transformation to the README

[lrouhier]

We have a repo of 8 mb do you want me to crop the image further ?

[lrouhier]

I forced push again. we need to have at least 16 slice per image. This is neede because the filter on the 3D unet has an issue with only ten slices (due to stride and convolution if I am correct)

[jcohenadad]

I forced push again. we need to have at least 16 slice per image. This is neede because the filter on the 3D unet has an issue with only ten slices (due to stride and convolution if I am correct)

i don't see the images anymore in the latest commit 9bce745.
while you're at it, maybe you can also reduce the dim along X and Y. Be "greedy".

[lrouhier]

Yes the images are not there because i was doing some tests to be sure that it would work this time (and wanted to avoid having to clean the repo a fourth time).

[jcohenadad]

Yes the images are not there because i was doing some tests to be sure that it would work this time (and wanted to avoid having to clean the repo a fourth time).

i think you don't need to bother with that, as we will do a squash merge. I believe this gets rid of the history (in case you re-uploaded binaries multiple times)-- @kouzu can you confirm?

[lrouhier]

I just added the images that works with the tests. I cropped all dimension (details of the bounding box in readme). Repo is 4.5 mb I think (zip download is 2.5 mb).

[jcohenadad]

on 2a55d35 json files are missing:

julien-macbook:~/code/ivadomed-data-testing/sub-unf01/anat $ ll
total 5016
drwxr-xr-x  5 julien  staff      160  5 Aug 14:11 .
drwxr-xr-x  3 julien  staff       96  5 Aug 14:11 ..
-rw-r--r--  1 julien  staff  1067161  5 Aug 14:11 sub-unf01_T1w.nii.gz
-rw-r--r--  1 julien  staff  1062495  5 Aug 14:11 sub-unf01_T2star.nii.gz
-rw-r--r--  1 julien  staff   433424  5 Aug 14:11 sub-unf01_T2w.nii.gz

[jcohenadad]

we should probably set up a procedure for generating json files on images that were processed (because the matrix size does not correspond anymore), but this is out of the scope of this PR.

@lrouhier are the discrepancies between the json and the images (e.g. dim, matrix size, resolution, etc.) a problem when running ivadomed?

[lrouhier]

No, for now the tests are running without them (because we used the contrast metadata which is in the name). However, They could be useful if we decide to create a test for FILM.

[jcohenadad]

No, for now the tests are running without them

[jcohenadad]

oopsi!

[jcohenadad]

No, for now the tests are running without them

so, does it mean that ivadomed's loader doesn't care if there is no json file in the BIDS dataset?

[lrouhier]

so, does it mean that ivadomed's loader doesn't care if there is no json file in the BIDS dataset?

I think so if it doesn't need it (from here). In the next lines an error is raised if the asked field is missing.

[lrouhier]

we should probably set up a procedure for generating json files on images that were processed (because the matrix size does not correspond anymore)

Not sure which field I need to change in the json for matrix size, resolution, dim ect .. @jcohenadad

[jcohenadad]

we should probably set up a procedure for generating json files on images that were processed (because the matrix size does not correspond anymore)

Not sure which field I need to change in the json for matrix size, resolution, dim ect .. @jcohenadad

will be addressed in #3

[jcohenadad]

I have some concerns with the decision to create random labels not representing the image content ivadomed/ivadomed#392, but we don,t need to fix it here