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

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

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