Hi,

you have this file in the DCMTK provide by offis
website : www.offis.de

a écrit dans le message de
news:1110210869.095197.80420@o13g2000cwo.googlegro ups.com...
> As I learn more about DICOM, it becomes clearer to me that if DICOM
> were being implemented from scratch today, there would be a lot of
> benefit to basing it on XML rather than on a low level proprietary
> binary format. But we all live with history... :-)
>
> There are several converters that translate DICOM to XML, but has
> anyone gone to the effort of creating a DTD grammar (or equivalent) to
> test the legitimacy of the XML so produced? It would be a great help to
> have such a utility.
>
> -Kelly
>

kellyatdentrix@gmail.com wrote:

> As I learn more about DICOM, it becomes clearer to me that if DICOM
> were being implemented from scratch today, there would be a lot of
> benefit to basing it on XML rather than on a low level proprietary
> binary format. But we all live with history... :-)

I'm not sure whether you're right. People nowadays tend to claim that
XML makes everything much easier but ...

> There are several converters that translate DICOM to XML, but has
> anyone gone to the effort of creating a DTD grammar (or equivalent)
> to test the legitimacy of the XML so produced? It would be a great
> help to have such a utility.

It's true that there is no standard mapping between DICOM and XML but
a lot of tools implementing something like this. For example our
DICOM toolkit DCMTK provides a tool called "dcm2xml" (and "xml2dcm"
for the reverse direction) which performs such a conversion and comes
with a DTD.

Regards,
Joerg Riesmeier
OFFIS

PS: "He said Jehova. Stone him!"

Stay tuned,

There is sanctioned work going on to transcode DICOM SR to CDA (HL7
V3.0 XML) It is very likely that the transcoding is going to be
generic. As far using standard XML tools to validate DICOM
objects...dream on, Dicom validators are complex pieces of code
because of all the conditionals, and not well formaed rules of DICOM,
that we inherited over the years, and off course from ACR-NEMA V2.0.
As far as the benefits of having DICOM objects in XML format...well it
is overrated. The beausty of XML is that it is neither machine or
human readable, even though it is claimed to be both. I rarely ever
look at binary dumps of dicom objects, The toolkits do a good job of
abstracting the format and provide the information in a trully human
consumable format. I am certain that i would not try to read dicom
objects in XML format either, at a minimum i would use a style sheet.


dee
;-D

kellyatdentrix@gmail.com wrote:
> As I learn more about DICOM, it becomes clearer to me that if DICOM
> were being implemented from scratch today, there would be a lot of
> benefit to basing it on XML rather than on a low level proprietary
> binary format. But we all live with history... :-)
>
> There are several converters that translate DICOM to XML, but has
> anyone gone to the effort of creating a DTD grammar (or equivalent)
to
> test the legitimacy of the XML so produced? It would be a great help
to
> have such a utility.
>
> -Kelly

kellyatdentrix@gmail.com wrote:

> As I learn more about DICOM, it becomes clearer to me that if DICOM
> were being implemented from scratch today, there would be a lot of
> benefit to basing it on XML rather than on a low level proprietary
> binary format. But we all live with history... :-)

ASN.1 might have been a better choice, and was a standard at the time
DICOM was created, but perhaps not when the original ACR-NEMA encoding
on which DICOM is based was defined.

XML can't carry the bulk binary pixel or waveform data efficiently, so
is a very poor choice (by itself) for image encoding in production.

If you look at JPEG 2000 as a modern example of an image format, the
compressed pixel data is carried as a binary encoding, as are the
attributes necessary to encode the critical information for decoding
the bit stream, and the meta data is carried in the (optional) JP2
header that does make use of XML, albeit wrapped in marker segments
as a a "box" as they call it. To be fair, JPEG 2000 did want to reuse
the old JPEG marker segments to the extent possible.

PNG is another contemporary example; no XML there either.

> There are several converters that translate DICOM to XML, but has
> anyone gone to the effort of creating a DTD grammar (or equivalent) to
> test the legitimacy of the XML so produced? It would be a great help to
> have such a utility.

Most DICOM to XML converters, including my own most recent effort at:

http://www.dclunie.com/pixelmed/soft...ctFactory.html

produce very literal XML of trivial complexity, and hence no DTD could
really do justice to validating the original DICOM object, but would
only validate the convertor implementation rather than the original
valid or invalid object.

Not to say that one could not use the resulting XML to analyze whether
or not the original DICOM object complied with the standard in terms of
low level encoding as well as compliance with the IODs. A DTD is not
powerful enough to do this, Schema might be able to do some of it, but
the complexity of some of the conditions requires a lot of XPath-like
expressions to navigate through the objects, which is why I use XSL-T
for this. See:

http://www.dclunie.com/pixelmed/soft...Validator.html

Note that I have only bothered to type in the IODs for the new CT and MR
enhanced IODs to test this concept - they have relatively complex conditions
between attributes; one of these days I will get around to typing in
all the other composite IODs but in the meantime you are stuck with
my old dciodvfy or some other tool.

Just to give you a sense of what this kind of approach requires, here is
an example of a rule for just one of hundreds of attributes in one of the
new MR IODs:

condition="/DicomObject/SharedFunctionalGroupsSequence/Item[@number=1]/MRImageFrameTypeSequence/Item[@number=1]/FrameType/value[@number=1]='ORIGINAL' or (name(../../..) =
'PerFrameFunctionalGroupsSequence' and ../../MRImageFrameTypeSequence/Item[@number=1]/FrameType/value[@number=1]='ORIGINAL') or (name(../../..) = 'SharedFunctionalGroupsSequence' and
/DicomObject/PerFrameFunctionalGroupsSequence/Item[*]/MRImageFrameTypeSequence/Item[@number=1]/FrameType/value[@number=1]='ORIGINAL')" mbpo="T">



which then gets translated (by some XSL-T) into the actual XSLT that is
applied to the XML representation of the DICOM object:













therwise>





therwise>










Warning: MRFOVGeometryMacro/MRFOVGeometrySequence/MRAcquisitionFrequencyEncodingSteps/:



: value of 0 is not illegal, but is unlikely to be correct




which as you can see calls several separate functions that do most of the
actual work in addition to the "native" XSL-T itself, one of which looks
like:


aram name="description"/>
aram name="element"/>
aram name="vmmin"/>
aram name="vmmax"/>
aram name="vr"/>

Error: : select="$element"/>: Duplicate attribute



Error: : select="$element"/>: Incorrect value multiplicity - got but expected select="$vmmin"/>-


Error: : select="$element"/>: Type 1C attribute may not be zero length when present




Simple this is not, and frankly I find it harder to write this declarative
pattern matching stuff to build validators than to just write procedural code,
especially given the relatively primitive (standard) XSL-T functions available;
the primary reason I did it this way to avoid having to reinvent something
like XPath.

I will also say that using a DICOM to XML conversion then an XSL-T validation
is incredibly slow for large objects compared to just doing it procedurally
from the binary, even though the XML is never actually instantiated and
is passed as SAX events to the XSL-T engine - I have some pretty powerful
machines but this is one of the very few jobs I still go away for a cup of
coffee whilst waiting to complete (reminds me of the days when builds ran
overnight rather than in milliseconds).

Next time, I will probably write a binary validator and just use XPath alone
to specify paths and conditions to locations in a hypothetical rather than
concrete instantiation of an XML representation, and avoid XSL-T altogether.

Note that I am just talking about IOD validation here - a completely separate
issue is the validation of DICOM SR objects for compliance with a particular
template, which is essentially a whole other layer on top of all this stuff,
and something that a transliteration into a "higher level" XML representation
at the content item level makes a lot easier. However, the XML I would produce
for this purpose would be a completely different form from that which I might
produce say to convert to an HL7 CDA representation, since there is not really
a reversible transliteration between DICOM SR and HL7 CDA, despite the wishful
thinking by some that this might be the case.

David

David Clunie wrote:

> Note that I am just talking about IOD validation here - a completely
> separate issue is the validation of DICOM SR objects for compliance
> with a particular template, which is essentially a whole other layer
> on top of all this stuff, and something that a transliteration into
> a "higher level" XML representation at the content item level makes
> a lot easier.

I agree, and in fact our SR XML tools "dsr2xml" and "xml2dsr" use a
totally different XML language than the general DICOM XML tools
"dcm2xml" and "xml2dcm". Btw, the XML Schema for the SR specific
tools has more than 800 lines of text

However, the detection of SR templates using pattern matching is
still a challenging task and, in my opinion, it's not always possible
to determine which templates have been used by the document's creator.
Although templates have been introduced to increase interoperability
the flexibility of the DICOM SR model and the fact that the creator
cannot always indicate which templates were used do not make life
easier for the SR reader ...

Regards,
Joerg Riesmeier
OFFIS

Joerg Riesmeier wrote:
> kellyatdentrix@gmail.com wrote:
>
> > As I learn more about DICOM, it becomes clearer to me that if DICOM
> > were being implemented from scratch today, there would be a lot of
> > benefit to basing it on XML rather than on a low level proprietary
> > binary format. But we all live with history... :-)
>
> I'm not sure whether you're right. People nowadays tend to claim that
> XML makes everything much easier but ...

I don't claim that XML is a silver bullet. On the other hand, there are
a thousand people who understand XML for each one who understands
DICOM. DICOM is to programming what the tax code is to accounting; a
guarantee of full employment to those vested in the dark robes of the
priesthood for years to come. To the fully initiated, the benefits may
be clear, but to the acolyte (newbie), it is a solution that seems more
complex than the problems it is meant to solve. Granted, this is
undoubtedly to a large extent because of DICOM's debt to history and
backwards compatibility. I don't think anyone would disagree that
without this debt to history, DICOM could be improved upon.

Perhaps I'm slow (although you would have to fight my mother if you
said it in front of her) but it took me several days of reading the
DICOM standard to even get to the point of understanding that it's all
about the tags, and that understanding came from looking at a part 10
file with a binary editor.

> It's true that there is no standard mapping between DICOM and XML but
> a lot of tools implementing something like this. For example our
> DICOM toolkit DCMTK provides a tool called "dcm2xml" (and "xml2dcm"
> for the reverse direction) which performs such a conversion and comes
> with a DTD.

That's great! I have DCMTK, but I don't see any DTD or XML files, would
you be so kind as to point out where these files could be found. Also,
with respect to Dr. Clunie's response, do you feel your DTD is
complete, or merely helpful?

>From my work thus far, it seems that one of the biggest problems with
DICOM is that because the rules are so rich and complex, it seems to be
easy to create badly formed DICOM data sets, and then you have to adopt
your code not only to read legal DICOM data sets, but everyone else's
poorly formed ones as well.

-Kelly

kellyatdentrix@gmail.com wrote:

> That's great! I have DCMTK, but I don't see any DTD or XML files,
> would you be so kind as to point out where these files could be
> found.

The file "dcm2xml.dtd" is located in "dcmtk-3.5.3/dcmdata/apps"
(source code package) and "/lib" (binary package or after
installation), respectively.

> Also, with respect to Dr. Clunie's response, do you feel your DTD
> is complete, or merely helpful?

The DTD does completely describe the output format of "dcm2xml".
However, its main purpose is to validate the input for "xml2dcm"
and not to check whether a certain file conforms to the DICOM
standard.

> From my work thus far, it seems that one of the biggest problems
> with DICOM is that because the rules are so rich and complex, it
> seems to be easy to create badly formed DICOM data sets, and then
> you have to adopt your code not only to read legal DICOM data sets,
> but everyone else's poorly formed ones as well.

We do recommend to use a DICOM validation tool like DCMCHECK (see
http://dicom.offis.de/dcmcheck ) in order to make sure that a DICOM
file conforms to the DICOM rules. You can get an evaluation copy if
you like: http://dicom.offis.de/evaluation

Nevertheless, I agree that the rules in the DICOM standard are quite
complex and that there are many incorrectly encoded images/files ...

Regards,
Joerg Riesmeier
OFFIS

> The DTD does completely describe the output format of "dcm2xml".
> However, its main purpose is to validate the input for "xml2dcm"
> and not to check whether a certain file conforms to the DICOM
> standard.

I see. When you convert a file using xml2dcm are you guaranteed a
well-formed DICOM file, or is it only well-formed if the original XML
conforms to the DICOM standard?

My original question was aimed at figuring out if the file conformed to
the DICOM standard, so I suppose the answer to that is that the DICOM
standard is too complex to fully describe with the DTD functionality.

> Nevertheless, I agree that the rules in the DICOM standard are quite
> complex and that there are many incorrectly encoded images/files ...

Yeah, that's too bad. The DICOM files my employer outputs currently are
definitely in that category, thus my efforts. Hopefully soon it will be
better.

-Kelly

kellyatdentrix@gmail.com wrote:

> When you convert a file using xml2dcm are you guaranteed a well-formed
> DICOM file, or is it only well-formed if the original XML conforms to
> the DICOM standard?

I would say the created DICOM file will be well-formed but not necessarily
valid ;-) In other words: "xml2dcm" does not check whether e.g. all
mandatory attributes for the particular IOD are really present.

> My original question was aimed at figuring out if the file conformed to
> the DICOM standard, so I suppose the answer to that is that the DICOM
> standard is too complex to fully describe with the DTD functionality.

Yes, definitely. As David pointed out even XML Schema is not powerful
enough to describe the complexity of the DICOM standard rules. Therefore,
you need something like XSLT/XPath or specific tools like dciodvfy and
DCMcheck.

Regards,
Joerg Riesmeier

kellyatdentrix@gmail.com wrote:
> > The DTD does completely describe the output format of "dcm2xml".
> > However, its main purpose is to validate the input for "xml2dcm"
> > and not to check whether a certain file conforms to the DICOM
> > standard.
>
> I see. When you convert a file using xml2dcm are you guaranteed a
> well-formed DICOM file, or is it only well-formed if the original XML
> conforms to the DICOM standard?
>
> My original question was aimed at figuring out if the file conformed
to
> the DICOM standard, so I suppose the answer to that is that the DICOM
> standard is too complex to fully describe with the DTD functionality.
>
> > Nevertheless, I agree that the rules in the DICOM standard are
quite
> > complex and that there are many incorrectly encoded images/files
....

The biggest limitation that XML schemas (or DTDs) for dicom objects
have is that the definition of various constraints that are present in
the standard is very hard to develop. (templates are full of
conditional sequences, not to mention the conditional types of
attributes in the "plain" IODs)

So, you cannot define using XML schemas conditions like:
if this_is_present then the_other_thing_is_present_too.

Oh well... you cannot represent that _easily_ or, better said, there
isn't a "natural" way to do that with schemas.

What you can do to overcome this kind of representation trouble is to
expand all possible branches of a conditional statement using choice
constructs -which can be done for limited nesting levels of
conditionality- but to have such a thing for complex template trees,
you'd need a automatic schema generator.

The resulted schema will certainly not be something you'd want to dig
into and/or try to make a sense of it (unless you're a schema validator
embodiment:-)) it will assure a validation of the dicom instance,
probably using a significand amount of processing power as David
pointed out earlier on a similar trend of though.

~~Razvan