Elements missing from classes

Questions regarding the DCMRT library, a DCMTK add-on that implements support for the various DICOM Radiation Therapy (RT) IODs

Moderator: Moderator Team

Post Reply
Message
Author
rmoore
Posts: 4
Joined: Thu, 2011-05-05, 18:52
Location: Gainesville, Florida, USA
Contact:

Elements missing from classes

#1 Post by rmoore » Fri, 2011-05-06, 21:02

Ran across the following while implementing an RTPlan sender:

PrimaryFluenceModeSequence is missing from DRTBeamSequenceInRTPlanIOD
CumulativeDoseReferenceCoefficient is missing from DRTReferencedDoseReferenceSequence::Item
AccessoryCode is missing from DRTApplicatorSequence::Item

I was able to fix the ::Item ones by adding new members to the classes and remaking the library. The fluence mode sequence however requires a whole new class, as well as modifying the beam sequence class, which is probably beyond my current knowledge level.

Suggestion: It would be nice to be able to add and get "other" elements to the classes. Perhaps maintained as an internal DcmItem. This would solve the problem of private tags and data. Varian Medical Systems, for instance, is famous for throwing private tags into everything.

I'd also like to commend you guys on the work you've done here. The toolkit is extremely easy to use. Well done!
Russ Moore
Medical Applications Programmer
University of Florida
rmoore@neurosurgery.ufl.edu

J. Riesmeier
DCMTK Developer
Posts: 2008
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

#2 Post by J. Riesmeier » Wed, 2011-05-11, 09:00

First of all, thank you for testing "dcmrt" and for your comments.

With regard to the missing attributes: You might have realized that more than 99% of the classes (including their implementation) are generated automatically from a machine-readable version of the DICOM standard. The comment header of these source files contains the following line:

Code: Select all

Generated automatically from DICOM PS 3.3-2007
That means the 2007 edition of the DICOM standard has been used for this purposes and this version did not yet contain these attributes. As soon as there is a more recent machine-readable version of the DICOM standard, we'll use that and regenerate the classes - which is just a matter of some seconds :-) However, I guess you're right regarding CumulativeDoseReferenceCoefficient - I'll check that ...

With regard to your suggestion: The other elements can be accessed directly via the dcmdata API using the dataset that is passed to the read() or write() method.

J. Riesmeier
DCMTK Developer
Posts: 2008
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

#3 Post by J. Riesmeier » Thu, 2011-05-12, 09:28

I checked the sequence classes and found another "specialty" (or let's call it abnormality?) of the DICOM RT IODs: The same sequence attribute might be defined completely differently depending on where it is used, i.e. the attributes contained in the sequence items can be different and, therefore, the C++ classes also have to be. This was already known for different IODs (e.g. RT Plan vs. RT Dose IOD) but now I found out that the same sequence can also be defined differently for a single IOD. Fortunately, it seems that this only happens for different modules, so it should be possible to change the generating XSLT scripts accordingly.

J. Riesmeier
DCMTK Developer
Posts: 2008
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

#4 Post by J. Riesmeier » Mon, 2011-05-30, 16:31

I guess we've fixed this issue with the latest snapshot. Thanks again for the report!

Post Reply

Who is online

Users browsing this forum: Bing [Bot] and 1 guest