Padding of odd length string types with Vm > 1 - DICOM

This is a discussion on Padding of odd length string types with Vm > 1 - DICOM ; String types (AE, CS, LO, ST, etc.) are required to have an even length with space padding the end as necessary to achieve this end. My question is if you had a Vm of 2 and the two words were ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Padding of odd length string types with Vm > 1

  1. Padding of odd length string types with Vm > 1

    String types (AE, CS, LO, ST, etc.) are required to have an even length
    with space padding the end as necessary to achieve this end.

    My question is if you had a Vm of 2 and the two words were
    "STONE" and "IMAGE", would you pad them like this:
    STONE_IMAGE_ (Length 12)

    or just like this?
    STONEIMAGE (Length 10)

    I'm guessing it's the first, is that right? Or is the requirement only
    for the entire length to be even when Vm > 1?

    -Kelly


  2. Re: Padding of odd length string types with Vm > 1

    The value length represents the length of the entire element value,
    regardless of its VM so it's the entire content that needs to be of
    even length.

    As for your example with STONE and IMAGE, a correct VM = 2
    representation (such as in the case of a PN, for instance) would be
    "STONE\IMAGE " with a white-space at the end.

    Note that the value multiplicity doesn't have a "real" representation
    at the dicom-elements level, being rather "induced" in the element
    content.

    HTH,
    ~~Razvan


  3. Re: Padding of odd length string types with Vm > 1

    Thank you, that clarifies it nicely.

    -Kelly

    Razvan Costea-Barlutiu wrote:
    > The value length represents the length of the entire element value,
    > regardless of its VM so it's the entire content that needs to be of
    > even length.
    >
    > As for your example with STONE and IMAGE, a correct VM = 2
    > representation (such as in the case of a PN, for instance) would be
    > "STONE\IMAGE " with a white-space at the end.
    >
    > Note that the value multiplicity doesn't have a "real" representation
    > at the dicom-elements level, being rather "induced" in the element
    > content.
    >
    > HTH,
    > ~~Razvan



+ Reply to Thread