mriconvert: Support for exporting BIDS compatible JSON files
Roman Fleysher
roman.fleysher at einstein.yu.edu
Fri Oct 2 20:00:34 PDT 2015
Dear MRIConvert developers,
Dear MRIConvert users,
I am strictly against such addition to MRIConvert. This functionality must be implemented in a separate command. There are other parameters that might be needed and other ways to get them. I consider producing such files as part of DICOM to NIFTI conversion a side effect. As we know in programming, side effects is one of the biggest causes of errors. User interfaces get clumsy. Please do not add side effects to MRIConvert. Not this, not any other.
Thank you,
Roman
________________________________
From: mriconvert-bounces at lists.uoregon.edu [mriconvert-bounces at lists.uoregon.edu] on behalf of Chris Filo Gorgolewski [krzysztof.gorgolewski at gmail.com]
Sent: Friday, October 02, 2015 9:26 PM
To: mriconvert at lists.uoregon.edu
Subject: mriconvert: Support for exporting BIDS compatible JSON files
Dear developers of MRIConvert,
Brain Imaging Data Structure (BIDS)<https://docs.google.com/document/d/1HFUkAEE-pB-angVcYe6pf_-fVf4sCpOHKesUvfb8Grc/edit#> is a new specification describing how a neuroimaging dataset should be organized and described. Part of the standard are JSON sidecar files with acquisition parameters essential for performing data analysis that are not present (or reliably reported) in the NIFTI header (see here<https://docs.google.com/document/d/1HFUkAEE-pB-angVcYe6pf_-fVf4sCpOHKesUvfb8Grc/edit#heading=h.r8mrcau3kkcq> for details). Such fields include but are not limited to:
* EffectiveEchoSpacing
* RepetitionTime
* PhaseEncodingDirection
* SliceTiming
* SliceEncodingDirection
* EchoTime
Some of those fields are part of DICOM Ontology and are directly accessible from standard DICOM headers (such as RepetitionTime and EchoTime) and some are not part of standard DICOM nomenclature and require extraction using vendor and sequence specific heuristics (for example PhaseEncodingDirection or EffectiveEchoSpacing). We aded them to the BIDS standard because they are necessary for data processing.
This is how an example BIDS compatible JSON file looks like (more examples here<https://github.com/INCF/BIDS-examples>):
{
"EchoTime": 0.017,
"EffectiveEchoSpacing": 0.0003333262223739227,
"PhaseEncodingDirection": "y-",
"RepetitionTime": 3.0,
"SliceEncodingDirection": "z",
"SliceTiming": [
1.508,
0.0,
1.55,
0.043,
1.592,
0.087,
1.635,
0.13,
1.677,
0.173,
1.722,
0.215,
1.765,
0.26,
1.808,
0.302,
1.85,
0.345,
1.893,
0.388,
1.938,
0.43,
1.98,
0.475,
2.022,
0.518,
2.065,
0.56,
2.11,
0.603,
2.152,
0.645,
2.195,
0.69,
2.238,
0.733,
2.28,
0.775,
2.325,
0.818,
2.367,
0.86,
2.41,
0.905,
2.453,
0.948,
2.495,
0.99,
2.54,
1.032,
2.583,
1.075,
2.625,
1.12,
2.668,
1.163,
2.71,
1.205,
2.755,
1.248,
2.798,
1.293,
2.84,
1.335,
2.883,
1.378,
2.925,
1.42,
2.97,
1.462
]
}
I've heard a lot of good things about MRIConvert. It would be great if the future release supported saving BIDS style JSON files along the converted NIFTI files. In addition you can consider embedding this JSON inside the header (similar to what dcmstack does). From looking at your code base I see that you already calculate many of the required parameters. I'm more than happy to provide any help in implementing this feature.
I have reached out to other developers of DICOM to NIFTI converters with similar proposals. I hope that soon we will have a common way of describing NIFTI metadata!
Best regards,
Chris Gorgolewski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists-prod.uoregon.edu/pipermail/mriconvert/attachments/20151003/c2a48365/attachment-0001.html>
More information about the mriconvert
mailing list