Uniqueness of In-Stack Number (0020,9057) - DICOM

This is a discussion on Uniqueness of In-Stack Number (0020,9057) - DICOM ; I am trying to make sense of an apparent inconsistency around Stacks in multiframe objects. Figure C.7.6.16-3 indicates that "In-Stack Number (0020,9057) shall be unique within Stack ID (0020,9056)" (PS 3.3 - 2008 Page 359), which I would interpret ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Uniqueness of In-Stack Number (0020,9057)

  1. Uniqueness of In-Stack Number (0020,9057)

    I am trying to make sense of an apparent inconsistency around Stacks
    in multiframe objects.

    Figure C.7.6.16-3 indicates that "In-Stack Number (0020,9057) shall
    be unique within Stack ID (0020,9056)" (PS 3.3 - 2008 Page 359), which
    I would interpret to mean that within a single stack, no two frames
    can have the same In-Stack Number.

    However, later in the same section, there is the statement that "[i]n
    order to allow interoperable operations on stacks, 2 different frames
    with the same Stack ID (0020,9056) can only have the same In-Stack
    Position Number (0020,9057) if they have the same values for the
    following attributes..." (PS 3.3 - 2008 Page 360) followed by the
    attributes that are required to be the same.

    I would assume, given the level of detail around the second statement,
    it is correct and the first statement should be qualified in some way.
    This is consistent with the example datasets.

    Is there something I'm missing?

    Regards,

    Jonathan Whitby

  2. Re: Uniqueness of In-Stack Number (0020,9057)

    Hi Jonathan,

    I forwarded your question to Kees Verduin, who is chair of DICOM WG 16
    and a major contributer to the new MR SOP Class. His reaction:

    The answer is
    yes and no:

    YES: the text is not completely correct:
    In-Stack Number (0020,9057) shall be unique within Stack ID
    (0020,9056)
    Text should be
    In-Stack Position Number (0020,9057) shall be unique within Stack ID
    (0020,9056)


    NO: the conditions are correctly described:

    There may be more sets of frames with the same STACK ID in the same
    object.
    They may also be in different objects.
    In order to process them (usefully) , they must have the identical
    attributes as described in the bullets 1-6 as in the text under fig C.
    7.6.16-4 . This described the conditions for such a situation.

    (One can think of 2 image sets , one with pre-contrast and one with
    post-contrast images)

    So, more frames may have the same In-Stack Position Number (0020,9057)
    with the same Stack ID , but then they have by definition also the
    same position and orientation in the patient.
    regards,

    Kees Verduin
    Product Manager Magnetic Resonance, Interoperability
    Philips Healthcare

    Building QP 1330, 5680 DA Best , The Netherlands

    Tel +31-40-2762030
    email: Kees.Verduin
    (at) philips.com

    On Jul 16, 3:06 pm, JWhitby wrote:
    > I am trying to make sense of an apparent inconsistency around Stacks
    > in multiframe objects.
    >
    >Figure C.7.6.16-3 indicates that "In-Stack Number (0020,9057) shall
    > be unique within Stack ID (0020,9056)" (PS 3.3 - 2008 Page 359), which
    > I would interpret to mean that within a single stack, no two frames
    > can have the same In-Stack Number.
    >
    > However, later in the same section, there is the statement that "[i]n
    > order to allow interoperable operations on stacks, 2 different frames
    > with the same Stack ID (0020,9056) can only have the same In-Stack
    > Position Number (0020,9057) if they have the same values for the
    > following attributes..." (PS 3.3 - 2008 Page 360) followed by the
    > attributes that are required to be the same.
    >
    > I would assume, given the level of detail around the second statement,
    > it is correct and the first statement should be qualified in some way.
    > This is consistent with the example datasets.
    >
    > Is there something I'm missing?
    >
    > Regards,
    >
    > Jonathan Whitby



+ Reply to Thread