mriconvert: Support for exporting BIDS compatible JSON files
Chris Filo Gorgolewski
krzysztof.gorgolewski at gmail.com
Thu Oct 15 16:55:20 PDT 2015
Dear Roman,
Thank you for the clarification. I respectfully disagree. There are many
ways to clarify the reason for which a given command line fails. For once
there is the return code you mentioned. It's a common practice to associate
different non-zero codes with different types of failures (for example -1
for conversion failure, -2 for metadata extraction failure). In addition
one can use standard error channel of the console output to communicate the
nature of the error in plain English.
Using a separate command line to extract metadata would be unnecessarily
slow because you would have to load the same data twice. For this reason
other dicom converters (dcm2nii, dicm2nii, dcmstack to name only a few)
also perform metadata extraction.
I agree that that this is not the best place to discuss this. I will try
other ways to reach mriconvert developers to work on this feature.
Best regards,
Chris Gorgolewski
On Wed, Oct 7, 2015 at 12:38 PM, Roman Fleysher <
roman.fleysher at einstein.yu.edu> wrote:
> Dear Chris,
>
> I am not sure this forum is the right place to discuss general programming
> stylistics. I will give a small example.
>
> Typically, a well written code (and I regard mcverter as one of these)
> sets an exit code to indicate success or error. If success (conventionally
> code=0), the user knows conversion was good. If fail (code not zero)
> indicates NIFTI is ether corrupt or not present and code may be interpreted
> as to the reason: no input data, wrong flags, no space on disk to output
> etc. Suppose conversion was OK, but the text file you propose could not be
> generated because DICOM fields were not filled. Is that a success or a
> failure? Which code should be given? By convention there is only one code
> for success: 0. Programmers have this joke that makes it easy to remember:
> Why did Roman Empire die? Because they did not have numeric code for
> successful completion of operations. (Roman numerals --- I, II, III, IV...
> --- do not have notation for zero.)
>
> The reason I talk exit codes is because as our analyses are getting more
> complicated, and they do, humans are less and less involved in the routine
> tasks. Tasks are scripted. I call mcverter from within a script that checks
> exit codes and tells me where error occurred. If the task of conversion and
> creation of the parameter file are split into two commands, then each gets
> to flag its exit status and makes it easier to trace successful conversion
> and successful parameter extraction.
>
> Moreover, it will be easy to pair DTI data with mcverter and b-value
> extractor, fMRI data with mcverter and timing extractor, ASL with mcverter
> and label extractor.... Conversion is always the same. Parameters depend on
> the context.
>
>
> 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 11:18 PM
> *To:* MRIConvert user's list
> *Subject:* Re: mriconvert: Support for exporting BIDS compatible JSON
> files
>
> Hi Roman,
> Thank you for you feedback. Could you elaborate a bit more why do you
> consider command lines producing more than one file so dangerous?
>
> Best,
> Chris
>
> On Fri, Oct 2, 2015 at 8:00 PM, Roman Fleysher <
> roman.fleysher at einstein.yu.edu> wrote:
>
>> 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
>>
>> _______________________________________________
>> mriconvert mailing list
>> mriconvert at lists.uoregon.edu
>> https://lists-prod.uoregon.edu/mailman/listinfo/mriconvert
>>
>>
>
> _______________________________________________
> mriconvert mailing list
> mriconvert at lists.uoregon.edu
> https://lists-prod.uoregon.edu/mailman/listinfo/mriconvert
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists-prod.uoregon.edu/pipermail/mriconvert/attachments/20151015/8864462e/attachment.html>
More information about the mriconvert
mailing list