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

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

Hi Caspar -

Good question - here's the way I see it working out:

We'll definitely be integrating this work with CTK, but the bulk of the
implementation will be natively in DCMTK.  The QIICR project is funding
some of the DCMTK developers to add support for a higher level C++ API for
multiframe objects (current focus is on segmentation objects).

On top of the DCMTK C++ API there will be the usual collection of handy
command line utilities in DCMTK.

CTK will expose a Qt API and a complementary set of widgets (plus PythonQt
wrapping).  This is what we'll use in Slicer, and although I can't speak
the their exact plans, also MITK.

dcmjs (see dcmjs.org) will expose the DCMTK functionality in javascript.

While QIICR is focused on DCMTK for the implementation, there needs to be
multiple standards compliant libraries that can interoperate using these
objects.  David Clunie's Java PixelMed software is currently the most
advanced, and some commercial tools can operate on these objects, but it
would be great to have support, for example, in pydicom and other packages
as well.

Circling back to teem, it would be great to have converters back and forth
between multiframe DICOM and NRRD.  In the context of QIICR we are trying
to determine the best way to encode derived objects.

Best,
Steve

On Mon, Aug 3, 2015 at 5:00 AM, Caspar Jonas Goch <cjg...@gm...>
wrote:

> Hi Steve,
>
> thanks for the link. I did take a look at it and will use it as a
> guideline.
>
> Maybe slightly off-topic for the teem list:
>
> Is your new project based on CTK? I was considering implementing the key
> dictionary within CTK anyway, that way other projects can use the same keys
> as MITK without needing MITK.
>
> Best,
> Caspar
>
>
> 2015-08-02 18:02 GMT+02:00 Steve Pieper <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.
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> teem-users mailing list
>> tee...@li...
>> https://lists.sourceforge.net/lists/listinfo/teem-users
>>
>>
>