adding varying series descriptions for the same series as a list in config.json
Arshitha opened this issue · 4 comments
Hi there! Thanks for creating such a user-friendly tool to transform dicom datasets to BIDS format!
I wanted to put forth a suggestion/feature request about config.json design. Can dcm2bids be modified to use lists instead of dictionary key-value pairs to account for series descriptions that belong to same series? Here's an example of what I'm referring to:
Based on the current config file format, for the same data type ("anat") , modality label ("T1w") and custom label ("acq-mprage"), there are multiple "SeriesDescription" values and therefore, multiple criteria key-values, causing there to be redundancy within the config file.
{
"descriptions": [
{
"dataType": "anat",
"modalityLabel": "T1w",
"customLabels": "acq-mprage",
"criteria": {
"SeriesDescription": "Anat T1w MP-RAGE 1mm (ABCD)"
}
},
{
"dataType": "anat",
"modalityLabel": "T1w",
"customLabels": "acq-mprage",
"criteria": {
"SeriesDescription": "PURE MP-RAGE 1mm"
}
},
{
"dataType": "anat",
"modalityLabel": "T1w",
"customLabels": "acq-mprage",
"criteria": {
"SeriesDescription": "Sag_MPRAGE_T1"
}
}]
}
Here's my suggestion:
{
"descriptions": [
{
"dataType": "anat",
"modalityLabel": "T1w",
"customLabels": "acq-mprage",
"criteria": {
"SeriesDescriptions": ["Anat T1w MP-RAGE 1mm (ABCD)", "PURE MP-RAGE 1mm", "Sag_MPRAGE_T1"]
}
}
]
}
I think this would make the config file more readable and easier to edit over multiple iterations of dicom to bids conversion over the course of curation process. It would also reduce the number of lines in the config file especially when transforming large neuroimaging datasets. I'm happy to add more examples if this isn't entirely clear.
Hi @arnaudbore - Just following up to see if you had any thoughts about this? Thank you!
Hi @Arshitha ,
Thank you for the follow up.
I put this as a new feature I will develop once we reach the new release 3.0.0.
Thanks @arnaudbore ! I'll try to do my bit and contribute to developing this feature.
This has been fixed in #217 with the use of a dict with the key "any"