DICOM and XML - DICOM

This is a discussion on DICOM and XML - DICOM ; 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 ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: DICOM and XML

  1. DICOM and XML

    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


  2. Re: DICOM and XML

    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
    >




  3. Re: DICOM and XML

    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!"

  4. Re: DICOM and XML

    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



  5. Re: DICOM and XML

    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


  6. Re: DICOM and XML

    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


  7. Re: DICOM and XML


    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


  8. Re: DICOM and XML

    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

  9. Re: DICOM and XML

    > 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


  10. Re: DICOM and XML

    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

  11. Re: DICOM and XML

    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


+ Reply to Thread