MR Image with wierd rescale slope and window values

[mail.as...@gmail.com]

I have a MR image which has a rescale slope 0.001 and window width as 1.98 and center as 0.99. I have never seen an image like this. Why would modality generate such an image? Currently my code assumes window values to be integers and is not able to handle this case. Should I be calculating the effective center and width by dividing those numbers by the slope?

[Chris Hafey]

On Saturday, June 27, 2015 at 10:56:17 AM UTC-5, mail.as...@gmail.com wrote:
> I have a MR image which has a rescale slope 0.001 and window width as 1.98 and center as 0.99. I have never seen an image like this. Why would modality generate such an image? Currently my code assumes window values to be integers and is not able to handle this case. Should I be calculating the effective center and width by dividing those numbers by the slope?

I don't know why an MRI would do this but your assumption is incorrect - Window Width (0028,1051) and Window Center (0028,1050) are both DS VR's which are floating point. You should look to redesign/refactor your image display pipeline so it is floating point based.

[Muralidhar Chowdary Nagineni]

Yes, As Chris spcified these variables has to decimal type.

Also if you are performing the change of window values interactively using mouse , i think you should change them with "factor" as follows.

factor = 1
factor = factor * rescaleSlope

newWindowWidth = currentWindowWidth + factor * deltaX
newWindowCenter = currentWindowCenter + factor * deltaY

This will make sure the brightness contrast change to be done smoothly for such images.

Regards,
Murlaidhar

[David Clunie]

Once upon a time integers were important.

E.g., see:

http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2231749/

David

[Mathieu Malaterre]

On Saturday, June 27, 2015 at 5:56:17 PM UTC+2, mail.as...@gmail.com wrote:
> I have a MR image which has a rescale slope 0.001 and window width as 1.98 and center as 0.99. I have never seen an image like this. Why would modality generate such an image? Currently my code assumes window values to be integers and is not able to handle this case. Should I be calculating the effective center and width by dividing those numbers by the slope?

No you can't have a Rescale Slope. MR Image Storage do not have Modality LUT:

http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.8.3.html#sect_C.8.3.1

[David Clunie]

Yes you can.

It is arguably valid as a Standard Extended SOP Class:

http://dicom.nema.org/medical/dicom/current/output/chtml/part02/sect_3.11.3.html

The question is, what does it mean and how do you deal with it?

I.e., how do you comply with the statement therein:

"The semantics of the related Standard SOP Class shall not be modified
by the additional Type 3 Attributes when absent."

This boils down to a consideration of what the window values apply
to (the stored pixel values or the rescaled values), and this was
never defined until Presentation States were added. E.g., CT
modalities typically assume one pattern, PET the opposite.

Philips caused such a problem doing this with their MR that they
made it configurable on the modality; e.g.:

http://incenter.medical.philips.com/doclib/enc/5147977/DICOM_Conformance_Statement_Intera_R7,_R8_and_R9.pdf%3Ffunc%3Ddoc.Fetch%26nodeid%3D5147977

Note the discussion in there about what the window values apply
to.

When we did Enhanced MR, Philips insisted that rescaling be
included; at least its semantics were then unambiguous.

See also this article:

http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3998685/

for some context for the use case in MR.

David

[Mathieu Malaterre]

Hi David,

Technically the behavior for Philips (old) MR Image Storage is slightly more complex. Per:

https://www.vuiis.vanderbilt.edu/~welcheb/manuals/R3.2.1/DICOM_Conformance_Statement_US.pdf

We have:

[...]
Rescale Slope 0028,1053 DS ALWAYS AUTO When a value is present and not 1, then this value shall be used in the scaling calculation for the correct Window setting.
[...]

I have seen cases (Achieva) such that:


$ gdcmdump MR0001.dcm | grep -1 Rescale
(0028,1051) DS [16.88 ] # 6,1-n Window Width
(0028,1053) DS [1.0 ] # 4,1 Rescale Slope
(0028,2110) CS [00] # 2,1 Lossy Image Compression
--
(fffe,e000) na (Item with undefined length)
(0028,1052) DS [0.0 ] # 4,1 Rescale Intercept
(0028,1053) DS [2.487424] # 8,1 Rescale Slope
(0028,1054) LO [normalized] # 10,1 Rescale Type
(2001,0010) LO [Philips Imaging DD 001] # 22,1 Private Creator
--
(2005,1406) SS 0 # 2,1 ?
(2005,1409) DS [0.0 ] # 4,1 Rescale Intercept Philips
(2005,140a) DS [2.48742368742368] # 16,1 Rescale Slope Philips
(2005,140b) LO [normalized] # 10,1 Rescale Type Philips
(2005,140e) SQ (Sequence with undefined length) # u/l,1 ?


The Philips private attributes Rescale Slope/Intercept seems to be consistent when one choose to use the Real World Value Mapping Sequence display path (C.7.6.16.2.11.1.1):

$ gdcmdump MR0001.dcm | grep -A 3 Real
(0040,9096) SQ (Sequence with undefined length) # u/l,1 Real World Value Mapping Sequence
(fffe,e000) na (Item with undefined length)
(0040,9224) FD 0 # 8,1 Real World Value Intercept
(0040,9225) FD 2.48742 # 8,1 Real World Value Slope
(fffe,e00d)
(fffe,e0dd)
(2001,0010) LO [Philips Imaging DD 001] # 22,1 Private Creator


So I suspect (old) MR Image Storage from Philips have always the public Rescale Slope set to 1 nowadays. Thus Real World Value Mapping Sequence information should be used to scale the stored pixel before processing and/or display.

The values for Real World Value Intercept/Slope are identical across all Series I've seen so far, so this is less messy than with some PET Image Storage with changing Rescale Slope/Intercept.

[c.w.c...@gmail.com]

On Thursday, October 22, 2015 at 3:53:00 PM UTC+5:30, Mathieu Malaterre wrote:

Hi Mathieu,

Your assumption is not correct.

Since long the user can decide per node if he wants to send the rescale values or not, this is a configuration option per node called "combine MR Rescaling".
If you don't want to send them the rescaling is made 0 and 1 and the windowing values are corrected accordingly.
If you want to send them the values will be send unchanged.

The private tags are used to preserve the original values as these are important for the packages that perform quantitative analysis.
The analysis is done after applying the rescaling, so for that the original values are preserved.

Real world value is until now indeed a copy of the rescale values, but don't count on this for the future.

Regards,
Wim

[Mathieu Malaterre]

Wim,

Thanks a lot for taking the time to clarify this ! Just to be clear, when doing quantitative analysis on -say- 3D T1, you mentioned:

> The private tags are used to preserve the original values as these are important for the packages that perform quantitative analysis.
> The analysis is done after applying the rescaling, so for that the original values are preserved.

Thus I'll have two cases to handle:

1. When "combine MR Rescaling" is set to ON. Then I can simply read the Modality LUT (Rescale Intercept/Slope/Type) and apply it to the Pixel Data buffer.

2. When "combine MR Rescaling" is set to OFF. Then I need to find the private field representing the Modality LUT:
- 2005,09,"Philips MR Imaging DD 005" // aka Rescale Intercept Philips
- 2005,0a,"Philips MR Imaging DD 005" // aka Rescale Slope Philips
- 2005,0b,"Philips MR Imaging DD 005" // aka Rescale Type Philips
and apply it to the Pixel Data buffer.


Again I am not interested in simple display, but really only quantitative image analysis. The above stated mechanism seems to be consistent with the paper D. Clunie sent (Errors in Quantitative Image Analysis due to Platform-Dependent Image Scaling), and in particular:

- https://github.com/fedorov/DICOMPhilipsRescalePlugin

Thanks again for your time.

[c.w.c...@gmail.com]

On Monday, October 26, 2015 at 1:46:04 PM UTC+5:30, Mathieu Malaterre wrote:
Mathieu,

Just the other way around, when it is said to TRUE rescaling is removed (made 0 and 1) and you need the private elements. In this case also the windowing is changed to keep the same output values for display.
When it is FALSE the values are exported unchanged and you can use them.

The private elements are by the way always present with the right value for data coming from the scanner.

Other situations should not be present.

Regards,
Wim

[Mathieu Malaterre]

Wim,

Indeed you are quite right:

> The private elements are by the way always present with the right value for data coming from the scanner.

That makes handling of MR Image Storage much easier since those private attributes can only ever be written by Philips MR Modality.

I'll fix the code in GDCM. This should hopefully propagate into ITK + Slicer.

[Mathieu Malaterre]

To anyone reading that thread. Keep in mind that you can still receive:

$ gdcmdump MR0025.dcm|grep Rescale

(0028,1052) DS [0.0 ] # 4,1 Rescale Intercept

(0028,1053) DS [4.23272283272283] # 16,1 Rescale Slope

(0028,1054) LO [normalized] # 10,1 Rescale Type

(2005,1409) DS [0.0 ] # 4,1 Rescale Intercept Philips

(2005,140a) DS [0.0 ] # 4,1 Rescale Slope Philips
(2005,140b) LO (no value) # 0,1 Rescale Type Philips

Do not assume values are always correct when read from the the private attributes.

[c.w.c...@gmail.com]

Mathieu,

Can you send me this image, would like to see the release and how it was generated.
Don't know of any release that has this problem.

Regards,
Wim

[antonio....@gmail.com]

Mathieu,

I have a problem with the private tags in context of rescale. My DICOM image has two equals private tags with rescale parameters. And rescale parameters are different for these tags. It's strange, isn't it?

Which private tag should I use to get initial value?

Thank you in advance.

[c.w.c...@gmail.com]

Wijchen tags are you using

[antonio....@gmail.com]

вторник, 30 апреля 2019 г., 8:26:59 UTC+3 пользователь c.w....@gmail.com написал:

> Wijchen tags are you using

I tried to find private tags as described here:
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3998685/

I red an dicom file tags via pydicom package (python) and found that there were two private tags containing tag (0028,1052) as an example.


There are the dicom file with this two private tags and txt file with tags' information obtained via pydicom:

https://drive.google.com/drive/folders/1TW5RBQUbhrnOOiMmMx_hgq2O_-oVcgKV?usp=sharing

I always though that dicom tags must be unique in any dicom file.

Initially I tried to obtain the absolute values of MRI signal for phantom experiment.

Best regards,
Anton Troitskii.

[c.w.c...@gmail.com]

You have an Enhanced MR Image object with rescaling in the Per Frame Group.
This means you have different values for each frame.
Next to that you have the original values in a private Philips group (2005, 140f), which stores original values when tags get alternative values on export request. So in total you will find the attribute 4 times but all in their own context.

[antonio....@gmail.com]

пятница, 3 мая 2019 г., 8:50:33 UTC+3 пользователь c.w....@gmail.com написал:

Thank you for your answer. It was really helpful.

I resolved my problem by using inverse transform.
That is my way to see the true signal value on DICOM viewer (I am using HOROS).

I read the private tags

SI = (2005, 100d) [Unknown]                           FL: 0.0
SS = (2005, 100e) [Unknown]                           FL: 0.09568928182125092

To get initial pixel value (IPV) of signal I perform such transformation:
IPV = SPV/SS - SI/SS.

So it is easy to obtain the initial pixel value if I have the stored pixel value (SPV).

How I understood, the values (of pixels) which person see on dicom viewer transform from stored pixel value in this way

DPV = SPV * RS + RI

RI = (0028, 1052) Rescale Intercept                   DS: "0"
RS = (0028, 1053) Rescale Slope                       DS: "1.36630036630036"

I update the values of these tags in such way:

RS = 1/SS and RI = -SI/SS

After that I can see the initial pixel value of the MR signal.

But I have a new BIG question.

Could anybody provide with information about how floating point data transformed to integer (2 bytes) data. How the loss of accuracy can be evaluated for this transformation?

Do you have any Idea?

[SpreadTooThin]

> But I have a new BIG question.
>
> Could anybody provide with information about how floating point data transformed to integer (2 bytes) data. How the loss of accuracy can be evaluated for this transformation?
>
> Do you have any Idea?

I may be over simplifying this but...

we take an integer multiply it by a float (rescale slope) add the intercept and the result is floating point, we wonder what to do with these 'fractions' and how to render them.
If we want to render this chances are your image processing pipeline is not setup to handle gl_float ... so multiply everything by a constant and truncate the fraction and you are back to handling integer data, but everything is scaled (including window width and center)