Slope and Intercept in MR Image IOD - DICOM

This is a discussion on Slope and Intercept in MR Image IOD - DICOM ; To my understanding, the old MR Image IOD does not include the Modality LUT module and therefore, slope and intercept should be ignored. I recently came across some SIEMES MR cardio studies with slope and intercept values that seem to ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Slope and Intercept in MR Image IOD

  1. Slope and Intercept in MR Image IOD

    To my understanding, the old MR Image IOD does not include the Modality
    LUT module and therefore, slope and intercept should be ignored.
    I recently came across some SIEMES MR cardio studies with slope and
    intercept values that seem to be necessary. (Slope 2 and Intercept
    -4096)

    How should one handle Slope and Intercept attribute in the MR IOD ?

    Regards,
    Andreas


  2. Re: Slope and Intercept in MR Image IOD


    Andreas Knopke wrote:
    > To my understanding, the old MR Image IOD does not include the Modality
    > LUT module and therefore, slope and intercept should be ignored.
    > I recently came across some SIEMES MR cardio studies with slope and
    > intercept values that seem to be necessary. (Slope 2 and Intercept
    > -4096)
    >
    > How should one handle Slope and Intercept attribute in the MR IOD ?


    I have also seen the issue with PMS (Philips Medical Systems), coming
    from Intera or Achieva. They are written as MR Image Storage but they
    also contains a Rescale Slope and Rescale Intercept.
    My guess would be to put a warning, or let the user acknowledge that
    you will be applying an operation that violates the definition in the
    standard...

    2 cents
    Mathieu


  3. Re: Slope and Intercept in MR Image IOD

    Thank you, Mathieu

    the problem I found is, that there are some strange images out there
    that seem to "misuse" these attributes for other things. I have for
    instance an MR image study from ELSCINT with a Slope value of 2107 and
    no Intercept attribute. Applying the Slope value leads to an all black
    image, but applying 1 for slope results in an appropriate display.

    Both, the MR images with sort of "necessary" values and the MR images
    with "misused" values are fortunately very rare. What I want to find
    out is, which one of the two is more common.
    The warning message would of course be the most conformant solution but
    will only confuse the regular user. How can he deside how to handle
    non-conformant attributes when we as the developers don't know either
    and would'nt it be very annoying to answer these question every time in
    the unfortunate case the customer uses one of these MR devices to
    blame?

    Regards,
    Andreas

    Ps.: Congratulations for your J2K implementation! I am currently trying
    to do the same with Delphi and found some issues with Jasper and 16bit
    grayscale.





    Mathieu Malaterre schrieb:

    > Andreas Knopke wrote:
    > > To my understanding, the old MR Image IOD does not include the Modality
    > > LUT module and therefore, slope and intercept should be ignored.
    > > I recently came across some SIEMES MR cardio studies with slope and
    > > intercept values that seem to be necessary. (Slope 2 and Intercept
    > > -4096)
    > >
    > > How should one handle Slope and Intercept attribute in the MR IOD ?

    >
    > I have also seen the issue with PMS (Philips Medical Systems), coming
    > from Intera or Achieva. They are written as MR Image Storage but they
    > also contains a Rescale Slope and Rescale Intercept.
    > My guess would be to put a warning, or let the user acknowledge that
    > you will be applying an operation that violates the definition in the
    > standard...
    >
    > 2 cents
    > Mathieu



  4. Re: Slope and Intercept in MR Image IOD

    Hi Andreas,

    See my comments interlaced.

    Andreas Knopke wrote:
    > Thank you, Mathieu
    >
    > the problem I found is, that there are some strange images out there
    > that seem to "misuse" these attributes for other things. I have for
    > instance an MR image study from ELSCINT with a Slope value of 2107 and
    > no Intercept attribute. Applying the Slope value leads to an all black
    > image, but applying 1 for slope results in an appropriate display.


    OMG ! At least I understand when people do not respect the standard
    simply because it help them achieve something. But in this case, they
    did not even open the specification...

    > Both, the MR images with sort of "necessary" values and the MR images
    > with "misused" values are fortunately very rare. What I want to find
    > out is, which one of the two is more common.
    > The warning message would of course be the most conformant solution but
    > will only confuse the regular user. How can he deside how to handle
    > non-conformant attributes when we as the developers don't know either
    > and would'nt it be very annoying to answer these question every time in
    > the unfortunate case the customer uses one of these MR devices to
    > blame?


    Well depends on how you build your application. But let say I am using
    your app, I am propose by the application an operation. If the result
    is all black...I simply close the application and start again without
    applying the operation the application ask me. On the second try I
    should get something correct. Scary, but at least you have warn your
    user.

    > Ps.: Congratulations for your J2K implementation! I am currently trying


    Real congrats should go to the openjpeg team ! http://www.openjpeg.org/

    All I have done is complained and they fixed the bug for me

    > to do the same with Delphi and found some issues with Jasper and 16bit
    > grayscale.


    Why not build a Pascal wrapper on top of a c lib (C is great for that!)
    As a side note Jasper 1.900 (dont ask about the numbering) has been
    released with a bunch of (unprecised) bug fixes (According to author).
    If you are not -yet- mad at them you can give yet another try to the
    lib:
    Ref:
    http://tech.groups.yahoo.com/group/j...n/message/1567


    I did not get that announcement. I am puzzled why Adams did not
    announce this in the usual online forum.
    I see nothing in the download, nor Adams's web page that actually says
    what has been changed other than "changes have been made".
    I am disappointed that Adams did not ask either Dmitry or me to at
    least be a Beta tester, since we are the most active users.
    Essentially before it can be used, this must first be thoroughly tested
    because what's changed is not being revealed by Adams.
    This will stifle is acceptance, which is counter productive.
    Until this version is incorporated into GeoJasPer, it is not useful to
    me and many others, and I can not being testing it until it can do at
    least what GeoJasPer can do.


    Good luck !
    -M


+ Reply to Thread