Enhanced MR/CT Image Storage - DICOM

This is a discussion on Enhanced MR/CT Image Storage - DICOM ; Hi, As far as I understand the standard, - There is no restriction on the ordering of the frames. For instance Image Position (Patient) is not guaranteed to be monotonically increasing/decreasing along the normal to the plane defined by the ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Enhanced MR/CT Image Storage

  1. Enhanced MR/CT Image Storage

    Hi,

    As far as I understand the standard,

    - There is no restriction on the ordering of the frames. For instance
    Image Position (Patient) is not guaranteed to be monotonically
    increasing/decreasing along the normal to the plane defined by the
    Image Orientation (Patient).

    - There is no restriction either that the Rescale Intercept/Slope
    present in the Per-frame Functional Groups Sequence should be equal
    for all frames.

    - When the IOP is only present in the Per-frame Functional Groups
    Sequence, all IOPs should be equal, right ?

    Thanks
    -Mathieu

  2. Re: Enhanced MR/CT Image Storage

    Hi Mathieu

    Mathieu Malaterre wrote:

    > - There is no restriction on the ordering of the frames. For instance
    > Image Position (Patient) is not guaranteed to be monotonically
    > increasing/decreasing along the normal to the plane defined by the
    > Image Orientation (Patient).


    Correct.

    > - There is no restriction either that the Rescale Intercept/Slope
    > present in the Per-frame Functional Groups Sequence should be equal
    > for all frames.


    Correct.

    And unlike the "old" MR object, the rescale values are mandatory;
    though the mapping to different units can/should be done using
    the Real World Value Mapping attributes.

    > - When the IOP is only present in the Per-frame Functional Groups
    > Sequence, all IOPs should be equal, right ?


    You mean Image Orientation (Patient) ?

    No. When it is in the Shared Functional Groups sequence it is equal
    (has to be , see it is only encoded once); when it is in the Per-frame
    Functional Groups Sequence it may sometimes not be equal.

    David

  3. Re: Enhanced MR/CT Image Storage

    On May 29, 12:34 pm, David Clunie wrote:
    > Hi Mathieu
    >
    > Mathieu Malaterre wrote:
    > > - There is no restriction on the ordering of the frames. For instance
    > > Image Position (Patient) is not guaranteed to be monotonically
    > > increasing/decreasing along the normal to the plane defined by the
    > > Image Orientation (Patient).

    >
    > Correct.
    >
    > > - There is no restriction either that the Rescale Intercept/Slope
    > > present in the Per-frame Functional Groups Sequence should be equal
    > > for all frames.

    >
    > Correct.
    >
    > And unlike the "old" MR object, the rescale values are mandatory;
    > though the mapping to different units can/should be done using
    > the Real World Value Mapping attributes.
    >
    > > - When the IOP is only present in the Per-frame Functional Groups
    > > Sequence, all IOPs should be equal, right ?

    >
    > You mean Image Orientation (Patient) ?
    >
    > No. When it is in the Shared Functional Groups sequence it is equal
    > (has to be , see it is only encoded once); when it is in the Per-frame
    > Functional Groups Sequence it may sometimes not be equal.


    Thanks !

    That's what I feared
    I was hoping to be dealing with a '3D volume' dataset, rather than a
    multi-frames dataset. So you could even potentially have a mixed T1/T2
    sequence of frames. This is going to required some serious 'tweaking'
    before gdcm can be declared compliant with Enhance CT/MR Image
    Storage.

    -Mathieu

  4. Re: Enhanced MR/CT Image Storage

    Hi Mathieu

    You can tell from the Dimensions Module (if present) that it
    is a simple 3D or 4D volume, and use the frame index values to
    traverse it.

    I presume you have downloaded and examined all of the test
    multi-frame images that are available at NEMA ?

    And that you have reviewed my slides on enhanced multi-frame
    that describe the dimension and stack mechanisms ?

    David

    Mathieu Malaterre wrote:
    > On May 29, 12:34 pm, David Clunie wrote:
    >> Hi Mathieu
    >>
    >> Mathieu Malaterre wrote:
    >>> - There is no restriction on the ordering of the frames. For instance
    >>> Image Position (Patient) is not guaranteed to be monotonically
    >>> increasing/decreasing along the normal to the plane defined by the
    >>> Image Orientation (Patient).

    >> Correct.
    >>
    >>> - There is no restriction either that the Rescale Intercept/Slope
    >>> present in the Per-frame Functional Groups Sequence should be equal
    >>> for all frames.

    >> Correct.
    >>
    >> And unlike the "old" MR object, the rescale values are mandatory;
    >> though the mapping to different units can/should be done using
    >> the Real World Value Mapping attributes.
    >>
    >>> - When the IOP is only present in the Per-frame Functional Groups
    >>> Sequence, all IOPs should be equal, right ?

    >> You mean Image Orientation (Patient) ?
    >>
    >> No. When it is in the Shared Functional Groups sequence it is equal
    >> (has to be , see it is only encoded once); when it is in the Per-frame
    >> Functional Groups Sequence it may sometimes not be equal.

    >
    > Thanks !
    >
    > That's what I feared
    > I was hoping to be dealing with a '3D volume' dataset, rather than a
    > multi-frames dataset. So you could even potentially have a mixed T1/T2
    > sequence of frames. This is going to required some serious 'tweaking'
    > before gdcm can be declared compliant with Enhance CT/MR Image
    > Storage.
    >
    > -Mathieu


  5. Re: Enhanced MR/CT Image Storage

    Hi David,

    On May 29, 11:47 pm, David Clunie wrote:
    > Hi Mathieu
    >
    > You can tell from the Dimensions Module (if present) that it
    > is a simple 3D or 4D volume, and use the frame index values to
    > traverse it.


    Hum... nope I must have skip this part from the standard. Thanks for
    the info !

    > I presume you have downloaded and examined all of the test
    > multi-frame images that are available at NEMA ?


    Hum...nope (again), just realized they were there:
    ftp://medical.nema.org/MEDICAL/Dicom.../WG16/Philips/

    So far, I have only been playing with your sample:

    http://www.dclunie.com/images/BRTUM001.dcm

    and one we have in gdcmData:

    http://www.creatis.insa-lyon.fr/~jpr..._0028_0030.dcm

    This one has Image Orientation (Patient) in the Per-frame Functional
    Groups SQ.


    > And that you have reviewed my slides on enhanced multi-frame
    > that describe the dimension and stack mechanisms ?



    This one ?

    http://www.dclunie.com/papers/PACS20...COMObjects.pdf


    Thanks & regards,
    -Mathieu

    > David
    >
    > Mathieu Malaterre wrote:
    > > On May 29, 12:34 pm, David Clunie wrote:
    > >> Hi Mathieu

    >
    > >> Mathieu Malaterre wrote:
    > >>> - There is no restriction on the ordering of the frames. For instance
    > >>> Image Position (Patient) is not guaranteed to be monotonically
    > >>> increasing/decreasing along the normal to the plane defined by the
    > >>> Image Orientation (Patient).
    > >> Correct.

    >
    > >>> - There is no restriction either that the Rescale Intercept/Slope
    > >>> present in the Per-frame Functional Groups Sequence should be equal
    > >>> for all frames.
    > >> Correct.

    >
    > >> And unlike the "old" MR object, the rescale values are mandatory;
    > >> though the mapping to different units can/should be done using
    > >> the Real World Value Mapping attributes.

    >
    > >>> - When the IOP is only present in the Per-frame Functional Groups
    > >>> Sequence, all IOPs should be equal, right ?
    > >> You mean Image Orientation (Patient) ?

    >
    > >> No. When it is in the Shared Functional Groups sequence it is equal
    > >> (has to be , see it is only encoded once); when it is in the Per-frame
    > >> Functional Groups Sequence it may sometimes not be equal.

    >
    > > Thanks !

    >
    > > That's what I feared
    > > I was hoping to be dealing with a '3D volume' dataset, rather than a
    > > multi-frames dataset. So you could even potentially have a mixed T1/T2
    > > sequence of frames. This is going to required some serious 'tweaking'
    > > before gdcm can be declared compliant with Enhance CT/MR Image
    > > Storage.

    >
    > > -Mathieu



  6. Re: Enhanced MR/CT Image Storage

    Hi Mathieu

    There is a whole bunch more stuff at:

    ftp://medical.nema.org/MEDICAL/Dicom/Multiframe/
    ftp://medical.nema.org/MEDICAL/Dicom...edMRIWorkshop/

    David

    Mathieu Malaterre wrote:
    > Hi David,
    >
    > On May 29, 11:47 pm, David Clunie wrote:
    >> Hi Mathieu
    >>
    >> You can tell from the Dimensions Module (if present) that it
    >> is a simple 3D or 4D volume, and use the frame index values to
    >> traverse it.

    >
    > Hum... nope I must have skip this part from the standard. Thanks for
    > the info !
    >
    >> I presume you have downloaded and examined all of the test
    >> multi-frame images that are available at NEMA ?

    >
    > Hum...nope (again), just realized they were there:
    > ftp://medical.nema.org/MEDICAL/Dicom.../WG16/Philips/
    >
    > So far, I have only been playing with your sample:
    >
    > http://www.dclunie.com/images/BRTUM001.dcm
    >
    > and one we have in gdcmData:
    >
    > http://www.creatis.insa-lyon.fr/~jpr..._0028_0030.dcm
    >
    > This one has Image Orientation (Patient) in the Per-frame Functional
    > Groups SQ.
    >
    >
    >> And that you have reviewed my slides on enhanced multi-frame
    >> that describe the dimension and stack mechanisms ?

    >
    >
    > This one ?
    >
    > http://www.dclunie.com/papers/PACS20...COMObjects.pdf
    >
    >
    > Thanks & regards,
    > -Mathieu
    >
    >> David
    >>
    >> Mathieu Malaterre wrote:
    >>> On May 29, 12:34 pm, David Clunie wrote:
    >>>> Hi Mathieu
    >>>> Mathieu Malaterre wrote:
    >>>>> - There is no restriction on the ordering of the frames. For instance
    >>>>> Image Position (Patient) is not guaranteed to be monotonically
    >>>>> increasing/decreasing along the normal to the plane defined by the
    >>>>> Image Orientation (Patient).
    >>>> Correct.
    >>>>> - There is no restriction either that the Rescale Intercept/Slope
    >>>>> present in the Per-frame Functional Groups Sequence should be equal
    >>>>> for all frames.
    >>>> Correct.
    >>>> And unlike the "old" MR object, the rescale values are mandatory;
    >>>> though the mapping to different units can/should be done using
    >>>> the Real World Value Mapping attributes.
    >>>>> - When the IOP is only present in the Per-frame Functional Groups
    >>>>> Sequence, all IOPs should be equal, right ?
    >>>> You mean Image Orientation (Patient) ?
    >>>> No. When it is in the Shared Functional Groups sequence it is equal
    >>>> (has to be , see it is only encoded once); when it is in the Per-frame
    >>>> Functional Groups Sequence it may sometimes not be equal.
    >>> Thanks !
    >>> That's what I feared
    >>> I was hoping to be dealing with a '3D volume' dataset, rather than a
    >>> multi-frames dataset. So you could even potentially have a mixed T1/T2
    >>> sequence of frames. This is going to required some serious 'tweaking'
    >>> before gdcm can be declared compliant with Enhance CT/MR Image
    >>> Storage.
    >>> -Mathieu

    >


+ Reply to Thread