Modality LUT Sequence issue

[nroduit]

I want to know if there is any restriction to apply Modality LUT
Sequence to the image pixels. I've implemented this feature in the
viewer Weasis, but it seems most of viewers do not handle Modality LUT
Sequence.

See the discussion and the DICOM sample at
http://forums.dcm4che.org/jiveforums/thread.jspa?messageID=26831

[David Clunie]

Hi Nicolas

The Modality LUTs are pretty screwy.

"Normally" they are intended to be processed as part of the forward
transformation of stored pixel values in the grayscale rendering
pipeline.

BUT, in the XA/XRF case (IODs that include the X-Ray Image Module),
if Pixel Intensity Relationship (0028,1040) is present with a
value of LOG or DISP, then the Modality LUT is NOT applied to the
stored pixel values before windowing; rather it is intended to
be used to map pixels backward to linear to X-Ray intensity (for
some king of analysis or processing).

See PS 3.3 C.8.7.1.1.2, and also PS 3.4 N.2.1.2.

In the Enhanced XA/XRF objects, this bizarre behavior has been
separated out into a Pixel Intensity Relationship LUT, rather
than abusing the Modality LUT.

By the way, in general, it can be difficult to decide whether or
not to apply the conceptual Modality LUT step before windowing,
even if it is specified by Rescale Slope/Intercept values rather
than an actual LUT. For example, in MR images to which Philips
has added the rescale values, these should not be applied before
their window values; likewise in PET images, especially those
with GML Units and rescale values to SUV (small decimal numbers),
the window values are historically usually in stored pixel values
rather than SUVs. Making the correct decision may require comparing
the range of possible rescaled output values (across the domain of
possible input stored pixel values) with the specific window values,
to see if the latter "make sense".

In Presentation States, the full pipeline is specified explicitly,
but historically, in the images, this is a mess, apart from CT.

In more recent image objects, the Real World Value Mapping Sequence
is used for most of the use cases that previously required a
Modality LUT step to report physical units, with the intention
of separating the rendering pipeline from the value extraction
pipeline. Note also that the window values reported in the user
interface can be in physical units, but converted into stored
pixel value (identity Modality LUT) "units" for persistence,
if appropriate. In some case, the newer objects fix Rescale Slope
and Intercept to 1 and 0 respectively to prevent implementers
getting creative by adding them, but sometimes there are legitimate
reasons to (such as to take advantage of widespread support for
them in reporting ROI values, where as there is little support
in viewers for the Real World Value Mapping Sequence yet).

David

On 10/25/12 2:14 PM, nroduit wrote:> I want to know if there is any restriction to apply Modality LUT

[Wim Corbijn]

Stephen,

I don't agree with your remark on Philips MR data.
For proper display of the data the rescaling information must be applied before the windowing information. If this is not done the image will show up either too dark or too bright.

Wim

[Wim Corbijn]

Op woensdag 31 oktober 2012 16:25:51 UTC+5:30 schreef Wim Corbijn het volgende:

David,

sorry reply was meant for you not for Stephen.
Philips MR is following the DICOM standard stating for the display pipeline that Rescaling should be used before windowing if it is present.

Wim

[Colby Dillion]

Wim,

That works fine for display, but what about CAD or other tools that perform calculations based on image data values? The MR IOD explicitly states that the Modality LUT is not one of its modules, so do you calculate based on the image data values or the rescaled values?

Colby

[Wim Corbijn]

Colby,

For Philips MR you need to use the rescale information also when you want you use the data for measurements.
The Classic MR object has indeed the rescaling not defined, so there has been quite some discussions about this. Some say Philips should not add it others take it into account because it is present. Don't need to repeat this discussion. It was made configurable to include the rescaling, this to make sure that viewing is correct. But if rescaling is removed you can no longer perform measurements correctly.
For the new Enhanced MR object it is clear.
Rescaling is there for the viewing pipeline and the Realworld value chain is there for measurements.
For now if you want to perform measurements on Philips MR data you need to use the rescaling information if send in Classic format, for the Enhanced format you need to use the realworld value chain.

Wim

[nroduit]

Thanks David,

> BUT, in the XA/XRF case (IODs that include the X-Ray Image Module),
> if Pixel Intensity Relationship (0028,1040) is present with a
> value of LOG or DISP, then the Modality LUT is NOT applied to the
> stored pixel values before windowing; rather it is intended to
> be used to map pixels backward to linear to X-Ray intensity (for
> some king of analysis or processing).
> See PS 3.3 C.8.7.1.1.2, and also PS 3.4 N.2.1.2.

I was missing this point.

> By the way, in general, it can be difficult to decide whether or
> not to apply the conceptual Modality LUT step before windowing,
> even if it is specified by Rescale Slope/Intercept values rather
> than an actual LUT. For example, in MR images to which Philips
> has added the rescale values, these should not be applied before
> their window values; likewise in PET images, especially those
> with GML Units and rescale values to SUV (small decimal numbers),
> the window values are historically usually in stored pixel values
> rather than SUVs. Making the correct decision may require comparing
> the range of possible rescaled output values (across the domain of
> possible input stored pixel values) with the specific window values,
> to see if the latter "make sense".

I will try to add a function to validate the Modality LUT.

> In more recent image objects, the Real World Value Mapping Sequence
> is used for most of the use cases that previously required a
> Modality LUT step to report physical units, with the intention
> of separating the rendering pipeline from the value extraction
> pipeline. Note also that the window values reported in the user
> interface can be in physical units, but converted into stored
> pixel value (identity Modality LUT) "units" for persistence,
> if appropriate. In some case, the newer objects fix Rescale Slope
> and Intercept to 1 and 0 respectively to prevent implementers
> getting creative by adding them, but sometimes there are legitimate
> reasons to (such as to take advantage of widespread support for
> them in reporting ROI values, where as there is little support
> in viewers for the Real World Value Mapping Sequence yet).

This way of separating display values and physical values for
processing sounds better.
I still have to implement a list of Real World Value Mapping Sequence
which the user could select to change the pixel values for statistics
(with ROI tools).