Source files for DICOM dictionaries

[GoogleCodeExporter]

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 reported on code.google.com by mathieu.malaterre on 12 Nov 2009 at 11:04

[GoogleCodeExporter]

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

Original comment by roy.coding@gmail.com on 12 Nov 2009 at 9:10

[GoogleCodeExporter]

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?

Original comment by darcymason@gmail.com on 19 Nov 2009 at 4:11

[GoogleCodeExporter]

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.

Original comment by bastula on 19 Nov 2009 at 10:51

[GoogleCodeExporter]

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=lo
g
http://gdcm.svn.sf.net/viewvc/gdcm/trunk/Source/DataDictionary/Part7.xml?view=lo
g

and for IOD, I am using only :

http://gdcm.svn.sf.net/viewvc/gdcm/trunk/Source/InformationObjectDefinition/Part
3.xml?view=log

and I used :
http://gdcm.svn.sf.net/viewvc/gdcm/trunk/Source/InformationObjectDefinition/Part
4.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.

Original comment by mathieu.malaterre on 20 Nov 2009 at 8:18

[GoogleCodeExporter]

BTW private elements are here:

http://gdcm.svn.sf.net/viewvc/gdcm/trunk/Source/DataDictionary/privatedicts.xml?
view=log

Original comment by mathieu.malaterre on 20 Nov 2009 at 8:22

[GoogleCodeExporter]

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.

Original comment by darcymason@gmail.com on 20 Nov 2009 at 7:39

• Changed title: Source files for DICOM dictionaries
• Changed state: Accepted
• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

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.

Original comment by DaniN...@gmail.com on 20 Jan 2010 at 3:16

Attachments:

• make_private_dict_alt.py

[GoogleCodeExporter]

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

Original comment by mathieu.malaterre on 20 Jan 2010 at 6:10

[GoogleCodeExporter]

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.

Original comment by darcymason@gmail.com on 23 Jan 2010 at 5:10

• Changed state: Started

[GoogleCodeExporter]

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.

Original comment by bastula on 23 Jan 2010 at 11:08

Attachments:

• make_UID_dict_alt.py

[GoogleCodeExporter]

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.

Original comment by bastula on 30 Jan 2010 at 6:37

Attachments:

• make_dicom_dict.py

[GoogleCodeExporter]

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.

Original comment by darcymason@gmail.com on 30 Jan 2010 at 8:40

[GoogleCodeExporter]

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

Original comment by darcymason@gmail.com on 16 Dec 2011 at 1:35

• Changed state: Verified