Source files for DICOM dictionaries

[suever]

From mathieu.malaterre on November 12, 2009 06:04:52

Since pydicom dictionary is derived from mdcm (and not directly GDCM), this means the license should be LGPL at best not MIT.

Please update your license or change the way you generate your dictionary.

Thanks

Original issue: http://code.google.com/p/pydicom/issues/detail?id=61

[suever]

From roy.coding@gmail.com on November 12, 2009 13:10:26

Malat has posted this to his blog, suggesting that the dictionary be derived directly from the BSD licensed xml-formatted dictionary from gdcm. http://malatsblog.blogspot.com/2009/11/private-dicom-dictionary.html

[suever]

From darcymason@gmail.com on November 19, 2009 08:11:32

I have commented on the blog link above -- I believe the license is not in violation, but for now have marked the googlecode site license as LGPL until this can be sorted out. In any case it would be preferable to derive from the BSD licensed file, and shouldn't be too difficult using python's built-in XML support. Anyone want to take that on?

[suever]

From bastula on November 19, 2009 14:51:08

I've done some XML parsing in Python before, so I could take a stab at it this weekend. I am curious though, the data / UID dictionaries are only from 2008 and don't include the additional CPs (the earlier MDCM-derived versions weren't either). When generating the dictionary, I'll compare to the 2008 standard before I submitted the CP additions.

[suever]

From mathieu.malaterre on November 20, 2009 00:18:11

Long story short: http://gdcm.svn.sf.net/viewvc/gdcm/trunk/Source/DataDictionary/DICOMV3.xml?view=log is generated from: http://gdcm.svn.sf.net/viewvc/gdcm/trunk/Source/DataDictionary/Part6.xml?view=log http://gdcm.svn.sf.net/viewvc/gdcm/trunk/Source/DataDictionary/Part7.xml?view=log and for IOD, I am using only : http://gdcm.svn.sf.net/viewvc/gdcm/trunk/Source/InformationObjectDefinition/Part3.xml?view=log and I used : http://gdcm.svn.sf.net/viewvc/gdcm/trunk/Source/InformationObjectDefinition/Part4.xml?view=log to generate the mapping from SOP classes to IOD (it has been aknowledge to be incomplete by DICOM WG6).

For every xml file (part3, Part4...) you'll find the corresponding xsl file used to generate the XML file the winword document. This is a very complex task to parse human document to automatically generate machine parsable document. Since WG6 has agreed on publishing DICOM standard as docbook in the near future, I have not taken any step in writing custom xsl script to also parse the Supp+CPs.

I am hoping 2009 edition will come out soon.

Cheers,

Thanks for respecting GDCM license.

[suever]

From mathieu.malaterre on November 20, 2009 00:22:05

BTW private elements are here: http://gdcm.svn.sf.net/viewvc/gdcm/trunk/Source/DataDictionary/privatedicts.xml?view=log

[suever]

From darcymason@gmail.com on November 20, 2009 11:39:42

Just to be clear -- for now we only need to change the source for the private dictionary conversion. The main dictionary can stay for now, including the CP additions bastula contributed before.

However, it might be convenient to use the XML as source for the main dictionary too. As Mathieu said, it is difficult (or has been in the past at least) to parse the human-readable documents to machine-readable. I've done that task and it required some hand-editing for quite a few definitions. If someone else has already done it (e.g. GDCM) we should use it with thanks if possible.

Summary: Source files for DICOM dictionaries
Status: Accepted
Labels: -Priority-Medium Priority-High

[suever]

From DaniN...@gmail.com on January 20, 2010 07:16:25

Attached a script that generates a "_private_dict.py"-analogous file with the information from the website specified by Mathieu in comment 5 above.

Please note:

1. This was not extensively tested. Use at own risk. It seemed to provide more information on private tags than the current implementation.
2. I do not understand what the legal issues with the licenses are. I understood the above comments as meaning direct use of this information might be an option and decided to see what would be involved and what the benefits might be. Any rightful claims and restrictions that the GDCM project might have against such a use of the data they publish remain valid.
3. Please feel free to change the copyright of the script to what seems most useful.

Attachment: make_private_dict_alt.py

[suever]

From mathieu.malaterre on January 20, 2010 10:10:33

In response to your question #2.

Since you are converting (using a machine) a GDCM file, you have to respect the 3 lines GDCM copyright. Basically put somewhere in pydicom distribution that some portion of pydicom are under the GDCM copyright: http://gdcm.sourceforge.net/Copyright.html The GDCM terms are not more restrictive than pydicom copyright so there is no impact at all on pydicom, other that a new txt file being part of the tarball...

HTH

[suever]

From darcymason@gmail.com on January 23, 2010 09:10:21

Dani, Thanks for this code. It's nicely written and works perfectly. I replaced the existing pydicom "make" code and its output with this one in revision 7a96388681 , i.e. I removed the 'alt' from the file names and internal descriptions. Other than that I think I only made a minor edit to the comment header to match the style of the other pydicom files a little more closely. Getting the GDCM file directly with the url was a nice trick, it will make it easier to update periodically in the future with updates to the GDCM file.

Mattieu, thanks for pointing to this file, this is a cleaner solution than in the past. The pydicom license file was updated to note the portion from GDCM and includes the GDCM license.

I haven't closed the issue yet as it can stay open for the main (non-private) DICOM dictionary as well.

Status: Started

[suever]

From bastula on January 23, 2010 15:08:13

Attached a script based on Dani's code to update the UIDs from the 2009 DICOM standard, taken from the DCM4CHE project.

1. The DCM4CHE XML file does not have the name_info column, so I replaced it with the alias field which does exist. I am not sure if any current applications/projects based on pydicom rely on this.
2. I replaced the existing file in my checkout and tested with dicompyler and it seems to work fine.

I am working on a similar script to update the DICOM dictionary to the 2009 base standard as well.

Attachment: make_UID_dict_alt.py

[suever]

From bastula on January 29, 2010 22:37:43

Attached a script to update the DICOM dictionary to the 2009 base standard. Again like the previous script, it uses the XML file converted by the DCM4CHE project.

1. Added a new field to the dictionary that includes the new keyword field found in the standard (present in the XML file). This probably needs to be addressed in datadict.py. I did not look into this deeply, as there may be changes which break code. If necessary, this element can be removed to make it look like the existing file.
2. I encoded the resultant file in UTF-8 due to tag 0x00181153 having a micron character in the description: "Exposure in µAs". I tested this tag in in a python interpreter and got 'Exposurein\xc2\xb5As' back. I am not sure where to make the underlying changes in pydicom to correct this or to just use a different encoding in the dictionary file.
3. I tested this with the built-in test "test_dictionary.py" as well as with dicompyler and they both work as expected.

Attachment: make_dicom_dict.py

[suever]

From darcymason@gmail.com on January 30, 2010 12:40:40

bastula, thanks for both these contributions. And you raise good points that will need some investigation. I'd like to put a release package together soon; it would be nice to hold the release a bit if these contributions can be easily included. I'll try them out and see what can be done.

[suever]

From darcymason@gmail.com on December 15, 2011 17:35:49

Closing this issue as the private dictionary issues had been dealt with, and the 0.9.6 release includes the new 2011 DICOM dictionary.

Status: Verified