Open valosekj opened 9 months ago
In the end, it's not as straight-forward as I expected. There are multiple things to do :
sub-cal119_ses-M12_T2star.nii.gz
is "broken" : I cannot do file.get_fdata()
)sub-van150_ses-M12_T2star
contains 3 acquisitions)Questions :
@jcohenadad @valosekj Any thoughts ? Should we report this in the next meeting with UBC ?
Current code: here
What should be done for the splitting of T2star images ?
I think we can average them, or use RMS, as done in the spine-generic project
What should be done the problematic image ?
Let's see what the UBC team says
Should we report this in the next meeting with UBC?
I don't think we should wait for the next meeting-- can you let the team know about it now?
I confirm in spine generic we do RMS for T2star
- [ ] Copy updated images
What is meant by "updated images"?
- [ ] Deal with problematic images (
sub-cal119_ses-M12_T2star.nii.gz
is "broken" : I cannot dofile.get_fdata()
)
I can confirm that sub-cal119_ses-M12_T2star.nii.gz
is broken and cannot be opened in FSLeyes.
- What should be done for the splitting of T2star images ?
For spine-generic, we actually kept the 4D T2star images in the root dataset. And Sandrine is now adding reoriented and root mean squared (across 4th dimension) images to derivatives/data_preprocessed
as part of https://github.com/spine-generic/data-multi-subject/pull/159. So maybe we can do the same here, i.e., keep the original 4D T2star?
What is meant by "updated images"?
By this, I mean images which already exist but whose data was changed.
For spine-generic, we actually kept the 4D T2star images in the root dataset. And Sandrine is now adding reoriented and root mean squared (across 4th dimension) images to derivatives/data_preprocessed as part of https://github.com/spine-generic/data-multi-subject/pull/159. So maybe we can do the same here, i.e., keep the original 4D T2star?
After yesterday's discussion during the canproco meeting, we decided to keep both the 4D T2star and 3D T2star with different file names in the same folders. What names should be used ?
...T2star_original.nii.gz
...T2star.nii.gz
(their json file should contain the transformations applied)What are your opinions @jcohenadad @valosekj @NathanMolinier
for 4D T2star: ...T2star_original.nii.gz
that is definitely not 'BIDS friendly'. Someone would have to spend 5min to look at the BIDS doc to figure out what field is appropriate (acq, rec, etc.)
After yesterday's discussion during the canproco meeting, we decided to keep both the 4D T2star and 3D T2star with different file names in the same folders. What names should be used ?
- for 4D T2star:
...T2star_original.nii.gz
- for 3D T2star:
...T2star.nii.gz
(their json file should contain the transformations applied)
We could use the entities rec-RMS
or proc-RMS
for the 3D T2star ? If we decide to keep them in the same folder.
Since we recently received a new batch of data containing combined M0-M12, should we move forward with this ? Maybe we could just work on the last version they sent us, which might not have the problems listed here ?
Maybe we could just work on the last version they sent us, which might not have the problems listed here ?
I'd be curious to know how they dealt with this. My gut feeling is that they didn't, and we should send them the averaged T2*w data, which we could call rec-RMS
The modifications were done using the file code/update_M12_data_2024-02-26.py
The following work was done:
rec-RMS_T2star
(this means that both the original 4D T2star and the averaged T2star are stored in the canproco repo)The file sub-cal119_ses-M12_T2star.nii.gz
was corrupted and therefore not added to the git-annex dataset.
The following list details the output of the process:
TODO:
The segmentations were checked for the modified files (i.e. only subject sub-mon014_ses-M12
).
Changes were pushed to branch plb/update_m12_with_2024_02_26_data
and PR was opened. Ready for merge now.
On 2024-02-23, we received M12 MRI data from Erin. I saved the data to
~/duke/temp/janvalosek/canproco_M12_2024-02-26
.TODO: