Possible enhancement to BIDS output

[seandoyle]

Hi -
I want to make some additions to the BIDS format data but I'd like to do it in a way that would be useful to others. I'm just reading up on BIDS tonight for the first time. I have two questions:

1. Is there a dictionary of existing DICOM fields? for example - I want to add the FrameOfReferenceUID. This would be useful to see if two NIFTI files are in the same geometric space.
2. Is it an abuse of BIDS to add sets of objects in a JSON file? Specifically - I'd like to add an array of images. Each image would contain attributes that enabled easy matching back to the original DICOM. Perhaps SOPInstanceUID, InstanceNumber... maybe SliceLocation (although that should be able to be calculated from other NIFTI data.

Use case for #1: A DICOM study might have two series - one with 2.5mm slices and another with 5.0mm slices. If they are in the same frame of reference - I might algorithmically find a feature on the thin slices but report it back to a user reading the thick slices.

Use case for #2: if I export DICOM to NIFTI for machine learning algorithms and a separate process generates findings on a particular slice - it's easy to map it back to the original data. Alternatively - if another process generates annotations on the original DICOM data - I can link it to the NIFTI slices.

Of course - if I keep adding attributes to then in the limit we get DICOM again!

I don't know if this is the correct forum for asking this sort of question. If there is a better one (or a better approach) please let me know. My goal is to close a loop - we export data as NIFTI for processing - but then return the results to a clinical context.

Thanks

Sean

[neurolabusc]

Sean-

Short answer:

This is not the correct forum - this software implements the BIDS standard but does not define it. If you can get this feature added to the specification, I will include it.

Long answer:

First of all, dcm2niix is really designed for speed, and does not allow the user to request specific DICOM elements. You might be able to hack a solution by piping the output of the logorrheic verbosity ("-v 2"). However, I think other tools like the Python-based dcmstack or Matlab-based dicm2nii might be better suited. On the other hand, you can always fork dcm2niix and modify it in any way you wish (hint: the softwareVersions works just the way you envision, copying a DICOM-based string to the BIDS format).

In general, I am open to the idea of adding useful elements to the BIDS output. However, in this particular case I am worried about unintended consequences. Consider the case of two scans from the same series with identical slice angulation but one being a 2D acquisition and the other being 3D. In this case, the former preserves orientation (required for slice timing correction) where in the latter the image is losslessly rotated to match the NIfTI identity matrix as closely as possible. My sense is the most robust solution is to read the NIfTI SForm or QForm to determine the spatial coordinates and axis. While this may be more complicated, it provides a robust, universal solution.

If you look at the current BIDS output of dcm2niix you will see I have attempted to include (1) all of the information I can that is required by the BIDS specification plus (2) a few elements that I think are useful and unambiguous. I admit the latter set is arbitrary, and @chrisfilo ultimately maintains the BIDS implementation in dcm2niix. If he wants something added or removed, I always defer to him.

[seandoyle]

Chris - Thanks - this is very helpful - glad I asked :-). I’ll read through the spec - I saw the Nature paper for the first time last night. The problem that I think I’m trying to solve is consistent and bidirectional mapping between NIFTI and DICOM worlds. I hadn’t realized that NIFTI might losslessly rotate the images. I guess I need to read more than one spec closely :-). I think I could make an argument for including the FrameOfReferenceUID in your BIDS extensions. This would be useful for establishing that two NIFTI objects were in the same coordinate space (although maybe I’m missing something here). Thanks for taking the time to explain this to me. If there are other standards I need to read please let me know. BTW - the center I’m working at at MGH now has a new web site: https://clindatsci.com - please feel free to share this with anyone that is interesting in ML algorithms for clinical care. Thanks again - Sean On Jun 20, 2017, at 9:48 AM, Chris Rorden <[email protected]<mailto:[email protected]>> wrote: Sean- Short answer: This is not the correct forum - this software implements the BIDS<http://bids.neuroimaging.io/> standard but does not define it. If you can get this feature added to the specification, I will include it. Long answer: First of all, dcm2niix is really designed for speed, and does not allow the user to request specific DICOM elements. You might be able to hack a solution by piping the output of the logorrheic verbosity ("-v 2"). However, I think other tools like the Python-based dcmstack<https://github.com/moloney/dcmstack> or Matlab-based dicm2nii<https://www.mathworks.com/matlabcentral/fileexchange/42997-dicom-to-nifti-converter--nifti-tool-and-viewer> might be better suited. On the other hand, you can always fork dcm2niix and modify it in any way you wish (hint: the softwareVersions works just the way you envision, copying a DICOM-based string to the BIDS format). In general, I am open to the idea of adding useful elements to the BIDS output. However, in this particular case I am worried about unintended consequences. Consider the case of two scans from the same series with identical slice angulation but one being a 2D acquisition and the other being 3D. In this case, the former preserves orientation (required for slice timing correction) where in the latter the image is losslessly rotated to match the NIfTI identity matrix as closely as possible. My sense is the most robust solution is to read the NIfTI SForm or QForm to determine the spatial coordinates and axis. While this may be more complicated, it provides a robust, universal solution. If you look at the current BIDS output of dcm2niix you will see I have attempted to include (1) all of the information I can that is required by the BIDS specification plus (2) a few elements that I think are useful and unambiguous. I admit the latter set is arbitrary, and @chrisfilo<https://github.com/chrisfilo> ultimately maintains the BIDS implementation in dcm2niix. If he wants something added or removed, I always defer to him. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#108 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAfmwFSGkZdg5CXbdb3GX3Kt4CUnPuneks5sF828gaJpZM4N_BmL>. The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.

[chrisgorgo]

Hi Sean, This seems like a reasonable addition to BIDS, but lets move the discussion to https://groups.google.com/forum/#!forum/bids-discussion if you don't mind (it's also a wider forum). On Tue, Jun 20, 2017 at 7:59 AM, Sean Doyle <[email protected]> wrote:

…

Chris - Thanks - this is very helpful - glad I asked :-). I’ll read through the spec - I saw the Nature paper for the first time last night. The problem that I think I’m trying to solve is consistent and bidirectional mapping between NIFTI and DICOM worlds. I hadn’t realized that NIFTI might losslessly rotate the images. I guess I need to read more than one spec closely :-). I think I could make an argument for including the FrameOfReferenceUID in your BIDS extensions. This would be useful for establishing that two NIFTI objects were in the same coordinate space (although maybe I’m missing something here). Thanks for taking the time to explain this to me. If there are other standards I need to read please let me know. BTW - the center I’m working at at MGH now has a new web site: https://clindatsci.com - please feel free to share this with anyone that is interesting in ML algorithms for clinical care. Thanks again - Sean On Jun 20, 2017, at 9:48 AM, Chris Rorden ***@***.***< ***@***.***>> wrote: Sean- Short answer: This is not the correct forum - this software implements the BIDS< http://bids.neuroimaging.io/> standard but does not define it. If you can get this feature added to the specification, I will include it. Long answer: First of all, dcm2niix is really designed for speed, and does not allow the user to request specific DICOM elements. You might be able to hack a solution by piping the output of the logorrheic verbosity ("-v 2"). However, I think other tools like the Python-based dcmstack< https://github.com/moloney/dcmstack> or Matlab-based dicm2nii<https://www. mathworks.com/matlabcentral/fileexchange/42997-dicom-to- nifti-converter--nifti-tool-and-viewer> might be better suited. On the other hand, you can always fork dcm2niix and modify it in any way you wish (hint: the softwareVersions works just the way you envision, copying a DICOM-based string to the BIDS format). In general, I am open to the idea of adding useful elements to the BIDS output. However, in this particular case I am worried about unintended consequences. Consider the case of two scans from the same series with identical slice angulation but one being a 2D acquisition and the other being 3D. In this case, the former preserves orientation (required for slice timing correction) where in the latter the image is losslessly rotated to match the NIfTI identity matrix as closely as possible. My sense is the most robust solution is to read the NIfTI SForm or QForm to determine the spatial coordinates and axis. While this may be more complicated, it provides a robust, universal solution. If you look at the current BIDS output of dcm2niix you will see I have attempted to include (1) all of the information I can that is required by the BIDS specification plus (2) a few elements that I think are useful and unambiguous. I admit the latter set is arbitrary, and @chrisfilo< https://github.com/chrisfilo> ultimately maintains the BIDS implementation in dcm2niix. If he wants something added or removed, I always defer to him. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<https://github.com/ rordenlab/dcm2niix#108#issuecomment-309759079>, or mute the thread< https://github.com/notifications/unsubscribe-auth/ AAfmwFSGkZdg5CXbdb3GX3Kt4CUnPuneks5sF828gaJpZM4N_BmL>. The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#108 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAOkp7kgbEprv0y3OqqExgO7q_9mbsLGks5sF95JgaJpZM4N_BmL> .

[seandoyle]

Agreed :-) On Jun 20, 2017, at 11:06 AM, Chris Filo Gorgolewski <[email protected]<mailto:[email protected]>> wrote: Hi Sean, This seems like a reasonable addition to BIDS, but lets move the discussion to https://groups.google.com/forum/#!forum/bids-discussion if you don't mind (it's also a wider forum). On Tue, Jun 20, 2017 at 7:59 AM, Sean Doyle <[email protected]<mailto:[email protected]>> wrote:

Chris - Thanks - this is very helpful - glad I asked :-). I’ll read through the spec - I saw the Nature paper for the first time last night. The problem that I think I’m trying to solve is consistent and bidirectional mapping between NIFTI and DICOM worlds. I hadn’t realized that NIFTI might losslessly rotate the images. I guess I need to read more than one spec closely :-). I think I could make an argument for including the FrameOfReferenceUID in your BIDS extensions. This would be useful for establishing that two NIFTI objects were in the same coordinate space (although maybe I’m missing something here). Thanks for taking the time to explain this to me. If there are other standards I need to read please let me know. BTW - the center I’m working at at MGH now has a new web site: https://clindatsci.com - please feel free to share this with anyone that is interesting in ML algorithms for clinical care. Thanks again - Sean On Jun 20, 2017, at 9:48 AM, Chris Rorden ***@***.******@***.***>< ***@***.***>> wrote: Sean- Short answer: This is not the correct forum - this software implements the BIDS< http://bids.neuroimaging.io/> standard but does not define it. If you can get this feature added to the specification, I will include it. Long answer: First of all, dcm2niix is really designed for speed, and does not allow the user to request specific DICOM elements. You might be able to hack a solution by piping the output of the logorrheic verbosity ("-v 2"). However, I think other tools like the Python-based dcmstack< https://github.com/moloney/dcmstack> or Matlab-based dicm2nii<https://www. mathworks.com/matlabcentral/fileexchange/42997-dicom-to-<http://mathworks.com/matlabcentral/fileexchange/42997-dicom-to-> nifti-converter--nifti-tool-and-viewer> might be better suited. On the other hand, you can always fork dcm2niix and modify it in any way you wish (hint: the softwareVersions works just the way you envision, copying a DICOM-based string to the BIDS format). In general, I am open to the idea of adding useful elements to the BIDS output. However, in this particular case I am worried about unintended consequences. Consider the case of two scans from the same series with identical slice angulation but one being a 2D acquisition and the other being 3D. In this case, the former preserves orientation (required for slice timing correction) where in the latter the image is losslessly rotated to match the NIfTI identity matrix as closely as possible. My sense is the most robust solution is to read the NIfTI SForm or QForm to determine the spatial coordinates and axis. While this may be more complicated, it provides a robust, universal solution. If you look at the current BIDS output of dcm2niix you will see I have attempted to include (1) all of the information I can that is required by the BIDS specification plus (2) a few elements that I think are useful and unambiguous. I admit the latter set is arbitrary, and @chrisfilo< https://github.com/chrisfilo> ultimately maintains the BIDS implementation in dcm2niix. If he wants something added or removed, I always defer to him. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<https://github.com/ rordenlab/dcm2niix#108#issuecomment-309759079>, or mute the thread< https://github.com/notifications/unsubscribe-auth/ AAfmwFSGkZdg5CXbdb3GX3Kt4CUnPuneks5sF828gaJpZM4N_BmL>. The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#108 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAOkp7kgbEprv0y3OqqExgO7q_9mbsLGks5sF95JgaJpZM4N_BmL> .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#108 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAfmwHTatXpXrVKSRo1_MhuT300j6NnFks5sF9_8gaJpZM4N_BmL>.