[Neuroimaging] JSON-LD and DICOM?

Reid, Robert I. (Rob) Reid.Robert at mayo.edu
Mon Jul 3 14:54:39 EDT 2017


Satrajit Ghosh wrote:
> as an algorithm developer, one would have to decide what metadata to keep and what new pieces of metadata to add to the dicom object.

I would really rather have it *all* kept, and think a better question is to decide what metadata to parse and what to store “raw”, to parse when modern medical science catches up to old obfuscated scans.  Our lab has been adding the dicom metadata of the first slice to our .niis for a long time, using dcmtk’s dcmdump.  Understandably, dcmdump needs a “DICOM dictionary” to translate between tag numbers and basic tag meaning, and many private tags end up as the dreaded “Unknown Tag & Data”, including, unfortunately, the Siemens CSA headers.  Later we figured out how to parse the CSA headers, and wish we had made them more conveniently accessible in our old .niis.  We keep the DICOM files of course, but we hate it when we have to go back to them.

As long as the metadata is kept, parsing is good, but a line will have to be drawn somewhere for how far parsing is supportable.  Keeping only one value for tags that are the same for all slices, but lists for ones that vary, is good and fairly straightforward.   Beyond that, there are many basic things, like diffusion gradients, whether fat saturation was used, and the Siemens CSA headers, that users want which are not stored the same way or in the same place between scanner software releases, let alone across manufacturers.  Having that info parsed would be very useful, but also difficult to maintain.

> but how many people use the diffusion extension over bvecs and bval files (a la FSL)?

Probably a rhetorical question, but actually I tend to use a header extension if it’s present, and do a glob for *bval* and *bvec* if I have to.  But it’s an in house extension made from the .bval and .bvec files from dcm2nii – I’m not aware of “the” diffusion extension.


Robert I. Reid, Ph.D. | Sr. Analyst/Programmer, Information Technology
Aging and Dementia Imaging Research | Opus Center for Advanced Imaging Research
Mayo Clinic | 200 First Street SW | Rochester, MN 55905 | mayoclinic.org<http://www.mayoclinic.org/>

From: Neuroimaging [mailto:neuroimaging-bounces+reid.robert=mayo.edu at python.org] On Behalf Of Satrajit Ghosh
Sent: Monday, July 03, 2017 12:58 PM
To: Neuroimaging analysis in Python
Subject: Re: [Neuroimaging] JSON-LD and DICOM?

hi all,

sorry, ohbm was busy, just catching up with this! it seems there are a few threads in here that i will attempt to summarize and comment.

1. the original question: is there a json-ld context that can be used or included in a nifti-header extension.

this can be easily created based on both the work done by david clunie to expose each dicom term but also the extensive curation by karl helmer. we can create a simple json-ld context definition that behaves as a lexicon. there are pieces of dicom where this will get complicated, but for our needs a vocabulary may be a good starting point.

here are the terms in neurolex: http://neurolex.org/wiki/Category:DICOM_term

they are being transitioned off to scicrunch/interlex and i'm sure karl and i can put together a basic context for us.

2. nibabel addons and the metadata extension in nifti.

for those who are unfamiliar, we have been using a non-standardized extension based on dcmstack in nifti for several years now in the heudiconv tool. there is an opportunity to make this part of nibabel and create a standard extension. as with many extensions, most software tools may choose to ignore an extension, but the value of this extension to keep dicom metadata around with the raw converted nifti file is immense. currently, we simply discard this information (wait till point 3 for the dicom-nifti dimension). as we create this standard, it would be good to leverage json-ld to simply point to a context file such as this:

"@context": "http://nipy.org/nibabel/dicom-context.jsonld"

we don't have to expand this out in each embedded header.

3. the dicom-nifti dimension:

a. state of the field.

this dicom-nifti dimension reflects the reality of our field in many ways. most of us neuroimagers live in a research/exploratory space and mostly do not have any clinical applications that need to be embedded into hospital systems. the clinical imaging community is trying to make their algorithms work for clinical decision systems in the clinical enterprise, hence their need for dicom operators. much of cognitive neuroscience is not applicable to the clinic hence very little incentive for people to think about dicoms.

b. the variations in dicom and nifti

as nate noted there are some big differences in scanners as they apply to research institutions. trying to standardize dicom output across scanners is itself a big undertaking and not in the interest of many centers. i'm not even talking about metadata standardization here, i'm simply saying let all dicom scanners output multi-frame dicom. if this is something the community can achieve it would be a big step towards a common framework. however, if it requires every center to change their mode of operation, it's a huge barrier at present. nifti on the other hand is a compact format and fits easily into current filesystem views.

c. software support

as has been well noted in this thread, the brain imaging community for most relies on a set of software packages that support nifti extensively. updating these tools to support dicom i/o is a resource intensive undertaking. if magically, through a week long hackathon, every software supported dicom objects, i don't think we would be having this conversation.

in addition better dicom support in nibabel could be very useful to a subset of the community developing tools in python. for example, from a memory representation perspective, it doesn't matter what the disk file format is as long as there is a nice api to read it.

we view dicom in the same lens that we saw it through in the nineties. perhaps we can be educated on the diffs in the last 20 years.

d. metadata maintenance

as an algorithm developer, one would have to decide what metadata to keep and what new pieces of metadata to add to the dicom object. i know andrey, steve, and others have done this for segmentation objects and structured reports, but the field would have to do this for connectomes, surfaces, and others.

blindly copying dicom metadata is analogous to blindly copying nifti header extensions. so in both spaces, one has to decide what to keep and what to modify. while we can be careful about this for new algorithms, doing so for the existing ones is a lot of work.

e. a view of information that reduces cognitive load

as algorithm developers we care about the view, the minimal set of information that is needed to write a function/solve a problem. nifti-1 was an agglomeration of those views when it was created, together with some backward compatibility decisions with analyze. people were not thinking of large databases, diffusion imaging, and other areas that we now consider important. and hence nifti is a view of the underlying information that is already out of date. yes the extensions were part of the solution, but how many people use the diffusion extension over bvecs and bval files (a la FSL)?

the dicom object stores much more information, but it is also a view. it does not store the raw sensor data (think nikon RAW vs JPEG) in most cases, because people thought it was excessive. as we now seem to find with simultaneous multislice seqeunces in fMRI and dMRI, the reconstruction algorithm has a huge impact on the SNR of the combined channel data. hence more people are preserving k-space data in projects that use such sequences.


at some point neither dicom nor nifti will be the appropriate format. we are not there yet but there are many pointers in that direction as connected information aggregates (genetics, imaging, behavior, ehr, etc). at present, in our resource constrained development environments, perhaps we can preserve information and make it useful when we can.


On Mon, Jul 3, 2017 at 7:15 AM, Matthew Brett <matthew.brett at gmail.com<mailto:matthew.brett at gmail.com>> wrote:
Hi Steve,

On Mon, Jul 3, 2017 at 2:03 PM, Steve Pieper <pieper at isomics.com<mailto:pieper at isomics.com>> wrote:
> To avoid repetition, I'll just point to my comments 3 years ago on this
> topic [1].  Since then we've continued to work on DICOM in research contexts
> [2] and we still think it's a neat idea.  The software is coming along
> nicely too [3].

I am sure there's a place for sticking entirely to DICOM, but, as you
know, nearly all standard imaging software reads and writes NIfTI, for
preference, and often only writes NIfTI.  So, a solution that works
with NIfTI is a lot closer to hand than switching to using DICOM at
all stages of processing.


Neuroimaging mailing list
Neuroimaging at python.org<mailto:Neuroimaging at python.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20170703/df153bfa/attachment.html>

More information about the Neuroimaging mailing list