[Teem-users] Suggested naming convention for dicom tag information in NRRD headers

[Steve P. <pi...@is...>]

Hi Gordon and Caspar -

There's actually a DICOM standard encoding for JSON so you could consider
following that rather than inventing your own:

ftp://medical.nema.org/medical/dicom/final/sup166_ft5.pdf

I have some python code here that does the mapping:

https://github.com/pieper/Chronicle/blob/master/bin/record.py

note that it's currently a lossy conversion because it ignores the binary
fields.


By the way, I'd be very interested in a more in-depth discussion of the
intersection of DICOM and NRRD.  For one of our projects we are working
hard on improved software support for "Enhanced Multiframe" DICOM objects,
which are in my opinion the *right* way to handle a number of important
quantitative image data representation tasks (notably ones where the
research community currently uses NRRD or NIfTI).

Over the past decade or so DICOM has significantly improved in terms of
support for encoding segmentations, spatial transforms, floating point
parametric maps, and many other important topics.  Importantly these are
standardized objects using well defined terminology and supporting
references between data objects.

There's some good information on this page:

https://github.com/QIICR/ProjectIssuesAndWiki/wiki/DICOM-Enhanced-Multi-frame-for-data-exchange

Best,
Steve


From: Gordon L. Kindlmann [gl...@uc...]
Sent: Thursday, July 30, 2015 2:10 PM
To: Caspar Jonas Goch
Cc: tee...@li...
Subject: Re: [Teem-users] Suggested naming convention for dicom tag
 information in NRRD headers

This is an interesting and important use for the key/value headers, but no,
there isn't any more general convention.

My only advise is to see if you can follow any precedent set by DICOM to
JSON meta data converters.  The Nrrd header is obviously not as flexible as
JSON, but someone may have already figure out a strategy for mapping the
possible zoo of DICOM tags to some consistent simpler representation.

Certainly, it would seem like you should be to include the numeric codes
that identify tags, like (0020,0037) for Image Orientation (Patient), in
the key name.

In general, I would err on the side of making the key strings longer and
more verbose.  It decreases the chances of them being misinterpreted later,
or clashing with different (and possibly incompatible schemes).  (Human)
Legibly is nice but reliably meaningful (algorithmic) parsing is essential.

Let us know what you figure out.
Gordon


On Jul 30, 2015, at 7:16 AM, Caspar Jonas Goch <cjg...@gm...>
wrote:

> Hi all,
>
> we are currently facing the requirement that users of our library want
some dicom tag information saved to the NRRD header when they convert their
data.
>
> I know that there is a naming convention for DWMRI data header
information we stick to so other tools can work with it. Is there a general
convention for other tags as well? So far I have not been able to find
anything.
>
> Any hints or suggestions are very much appreciated.
>
> Best,
> Caspar
>
> More details for those interested:
>
> We have not finalized which data we want to store, but it is probably
going to be a couple of dozen fields concerning sequence information and
acquisition parameters from official dicom tags as well as custom ones.
Additionally we will store information which is not saved in the dicom tags
at all but added at a later date.
>
> While it would work for us to just use our own keys and be done with it,
I would prefer to stick to an established convention if possible.
>
------------------------------------------------------------------------------
> _______________________________________________
> teem-users mailing list
> tee...@li...
> https://lists.sourceforge.net/lists/listinfo/teem-users


------------------------------------------------------------------------------
_______________________________________________
teem-users mailing list
tee...@li...
https://lists.sourceforge.net/lists/listinfo/teem-users


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.