Should the following IHE recommendation be absolutely implemented in a viewer?

Basic Image Review (BIR) Page 36, line 860 of https://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_Suppl_BIR.pdf
> The grayscale rendering pipeline shall be appropriate to the SOP Class and modality. If Rescale Slope and Rescale Intercept are present in the image for MR and PET and XA/XRF images, they shall be ignored from the perspective of applying window values, and for those SOP Classes, window values shall be applied directly to the stored pixel values without rescaling.

Because this recommendation conflicts with the need to have pixels with the application of Rescale Intercept and Rescale Slope for SUV calculation on PET exams. In general, the density measurement tools take the pixel values after applying Modality LUT.

SUVbw = (stored pixel value in Pixel Data (0x7FE0,0x0010) + Rescale Intercept (0x0028,0x1052))* Rescale Slope (0x0028,0x1053) * SUVbwScaleFactor

On Thursday, April 27, 2023 at 12:04:36 PM UTC-5, Nicolas Roduit wrote:
> Should the following IHE recommendation be absolutely implemented in a viewer?
>
> Basic Image Review (BIR) Page 36, line 860 of https://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_Suppl_BIR.pdf
> > The grayscale rendering pipeline shall be appropriate to the SOP Class and modality. If Rescale Slope and Rescale Intercept are present in the image for MR and PET and XA/XRF images, they shall be ignored from the perspective of applying window values, and for those SOP Classes, window values shall be applied directly to the stored pixel values without rescaling.
>
> Because this recommendation conflicts with the need to have pixels with the application of Rescale Intercept and Rescale Slope for SUV calculation on PET exams. In general, the density measurement tools take the pixel values after applying Modality LUT.
>
> SUVbw = (stored pixel value in Pixel Data (0x7FE0,0x0010) + Rescale Intercept (0x0028,0x1052))* Rescale Slope (0x0028,0x1053) * SUVbwScaleFactor

Hi Nicolas,

The IHE Rad Tech committee is in the process of promoting BIR to Final Text..
We plan to update this requirement to better follow DICOM display pipeline requirements.
See proposed edits to 4.16.4.2.2.5.4 here: https://docs.google.com/document/d/103W3xlvu125Yz64bmOG2v-WaVYKKshur/edit

Steve

We originally put that requirement in BIR for a reason - practical experience with MR and PET and XA/XRF from the field ... IHE Rad-Tech can screw with the profile in detrimental ways all they like, since I am not there anymore to defend it, but if the viewer doesn't work, don't be surprised if the outcome is not what you expect.

Nicolas, the measurement and rendering pipelines do not need to be the same..

The question is what the creator of the PET images intended their window values (if any) to be applied to.

SUV calculations (with some vendors specificities) are described in detail at https://qibawiki.rsna.org/index.php/Standardized_Uptake_Value_(SUV).

David

On Tuesday, May 2, 2023 at 9:45:42 AM UTC-4, Steven Nichols wrote:
> On Thursday, April 27, 2023 at 12:04:36 PM UTC-5, Nicolas Roduit wrote:
> > Should the following IHE recommendation be absolutely implemented in a viewer?
> >
> > Basic Image Review (BIR) Page 36, line 860 of https://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_Suppl_BIR.pdf
> > > The grayscale rendering pipeline shall be appropriate to the SOP Class and modality. If Rescale Slope and Rescale Intercept are present in the image for MR and PET and XA/XRF images, they shall be ignored from the perspective of applying window values, and for those SOP Classes, window values shall be applied directly to the stored pixel values without rescaling.
> >
> > Because this recommendation conflicts with the need to have pixels with the application of Rescale Intercept and Rescale Slope for SUV calculation on PET exams. In general, the density measurement tools take the pixel values after applying Modality LUT.
> >
> > SUVbw = (stored pixel value in Pixel Data (0x7FE0,0x0010) + Rescale Intercept (0x0028,0x1052))* Rescale Slope (0x0028,0x1053) * SUVbwScaleFactor
> Hi Nicolas,
>
> The IHE Rad Tech committee is in the process of promoting BIR to Final Text.
> We plan to update this requirement to better follow DICOM display pipeline requirements.
> See proposed edits to 4.16.4.2.2.5.4 here: https://docs.google.com/document/d/103W3xlvu125Yz64bmOG2v-WaVYKKshur/edit
>
> Steve
>
On Thursday, April 27, 2023 at 1:04:36 PM UTC-4, Nicolas Roduit wrote:
> Should the following IHE recommendation be absolutely implemented in a viewer?
>
> Basic Image Review (BIR) Page 36, line 860 of https://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_Suppl_BIR.pdf
> > The grayscale rendering pipeline shall be appropriate to the SOP Class and modality. If Rescale Slope and Rescale Intercept are present in the image for MR and PET and XA/XRF images, they shall be ignored from the perspective of applying window values, and for those SOP Classes, window values shall be applied directly to the stored pixel values without rescaling.
>
> Because this recommendation conflicts with the need to have pixels with the application of Rescale Intercept and Rescale Slope for SUV calculation on PET exams. In general, the density measurement tools take the pixel values after applying Modality LUT.
>
> SUVbw = (stored pixel value in Pixel Data (0x7FE0,0x0010) + Rescale Intercept (0x0028,0x1052))* Rescale Slope (0x0028,0x1053) * SUVbwScaleFactor

Thank you for the answers.

I give the point of view of someone who would like to implement the BIR profile. The LUT pipeline seems to me already quite complicated and I notice that there are few viewers that strictly implement all aspects of the pipeline. Therefore, doubling the pipeline doesn't seem to me to be the best idea, not to mention that it would have an effect on the performance by doubling the creation of 16-bit images. If we go in this direction, we should have a clear definition of the use cases for both.

In general, it seems to me more logical that the measurement tools (density, statistics, SUV...) should report the pixel value at the Modality LUT level of the pipeline of what is displayed. By having 2 pipelines, we will measure data from an image that is not part of the render pipeline.

@David can you specify the field issues? Is it in relation to the output values after the transformation?

Le Wednesday, May 3, 2023 à 11:33:41 PM UTC+2, David Clunie a écrit :
> We originally put that requirement in BIR for a reason - practical experience with MR and PET and XA/XRF from the field ... IHE Rad-Tech can screw with the profile in detrimental ways all they like, since I am not there anymore to defend it, but if the viewer doesn't work, don't be surprised if the outcome is not what you expect.
>
> Nicolas, the measurement and rendering pipelines do not need to be the same.
>
> The question is what the creator of the PET images intended their window values (if any) to be applied to.
>
> SUV calculations (with some vendors specificities) are described in detail at https://qibawiki.rsna.org/index.php/Standardized_Uptake_Value_(SUV).
>
> David
> On Tuesday, May 2, 2023 at 9:45:42 AM UTC-4, Steven Nichols wrote:
> > On Thursday, April 27, 2023 at 12:04:36 PM UTC-5, Nicolas Roduit wrote:
> > > Should the following IHE recommendation be absolutely implemented in a viewer?
> > >
> > > Basic Image Review (BIR) Page 36, line 860 of https://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_Suppl_BIR.pdf
> > > > The grayscale rendering pipeline shall be appropriate to the SOP Class and modality. If Rescale Slope and Rescale Intercept are present in the image for MR and PET and XA/XRF images, they shall be ignored from the perspective of applying window values, and for those SOP Classes, window values shall be applied directly to the stored pixel values without rescaling.
> > >
> > > Because this recommendation conflicts with the need to have pixels with the application of Rescale Intercept and Rescale Slope for SUV calculation on PET exams. In general, the density measurement tools take the pixel values after applying Modality LUT.
> > >
> > > SUVbw = (stored pixel value in Pixel Data (0x7FE0,0x0010) + Rescale Intercept (0x0028,0x1052))* Rescale Slope (0x0028,0x1053) * SUVbwScaleFactor
> > Hi Nicolas,
> >
> > The IHE Rad Tech committee is in the process of promoting BIR to Final Text.
> > We plan to update this requirement to better follow DICOM display pipeline requirements.
> > See proposed edits to 4.16.4.2.2.5.4 here: https://docs.google.com/document/d/103W3xlvu125Yz64bmOG2v-WaVYKKshur/edit
> >
> > Steve
> >
> On Thursday, April 27, 2023 at 1:04:36 PM UTC-4, Nicolas Roduit wrote:
> > Should the following IHE recommendation be absolutely implemented in a viewer?
> >
> > Basic Image Review (BIR) Page 36, line 860 of https://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_Suppl_BIR.pdf
> > > The grayscale rendering pipeline shall be appropriate to the SOP Class and modality. If Rescale Slope and Rescale Intercept are present in the image for MR and PET and XA/XRF images, they shall be ignored from the perspective of applying window values, and for those SOP Classes, window values shall be applied directly to the stored pixel values without rescaling.
> >
> > Because this recommendation conflicts with the need to have pixels with the application of Rescale Intercept and Rescale Slope for SUV calculation on PET exams. In general, the density measurement tools take the pixel values after applying Modality LUT.
> >
> > SUVbw = (stored pixel value in Pixel Data (0x7FE0,0x0010) + Rescale Intercept (0x0028,0x1052))* Rescale Slope (0x0028,0x1053) * SUVbwScaleFactor

Do you want it to be simple, or do you want it to work?

When a modality vendor creates images with rescale values that produce small floating point results, yet includes window values that are clearly intended to apply to large integers (presumably stored pixel values), what are you going to do (whether they were "right" or not to do that in the first place)?

The original BIR requirement, poorly worded or not, is intended to address this concern.

The MR IOD [1] does NOT include the Modality LUT Module (despite the encoding by some vendors), nor does the MR Image Module contain Rescale attributes, so the additional presence of Rescale attributes undermines the interpretation of the VOI LUT Module (i.e., it violates the Standard Extended rules [2]). "Bad" though such an object may be, the user doesn't care (just wants it to work, not look all black by default, and report measurements as intended by the creator). A proposed CP to add Rescale attributes to the MR Image IOD was rejected (CP 63).

The PET IOD [3] does NOT include the Modality LUT Module either, but does include the Rescale attributes in the PET Image Module [4], so these are valid, but PET vendors seem to sometimes ignore the expectation of applying the window values to the rescaled values, rather than the stored pixel values, unfortunately.

Going forward, with real-world values intended for measurements to replace any hokey unreliable dependence on rescaling, we have consciously separated measurement from rendering [5].

David

1. https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_A.4.3.html

2. https://dicom.nema.org/medical/dicom/current/output/chtml/part02/sect_7.3.html#para_56636f6b-5190-427b-8fc3-4a96d8e5704e

3. https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_A.21.3.html

4. https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.8.9.4.html

5. https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.6.16.2.html#figure_C.7.6.16-6

On Friday, May 5, 2023 at 3:42:43 AM UTC-4, Nicolas Roduit wrote:
> Thank you for the answers.
>
> I give the point of view of someone who would like to implement the BIR profile. The LUT pipeline seems to me already quite complicated and I notice that there are few viewers that strictly implement all aspects of the pipeline. Therefore, doubling the pipeline doesn't seem to me to be the best idea, not to mention that it would have an effect on the performance by doubling the creation of 16-bit images. If we go in this direction, we should have a clear definition of the use cases for both.
>
> In general, it seems to me more logical that the measurement tools (density, statistics, SUV...) should report the pixel value at the Modality LUT level of the pipeline of what is displayed. By having 2 pipelines, we will measure data from an image that is not part of the render pipeline.
>
> @David can you specify the field issues? Is it in relation to the output values after the transformation?
> Le Wednesday, May 3, 2023 à 11:33:41 PM UTC+2, David Clunie a écrit :
> > We originally put that requirement in BIR for a reason - practical experience with MR and PET and XA/XRF from the field ... IHE Rad-Tech can screw with the profile in detrimental ways all they like, since I am not there anymore to defend it, but if the viewer doesn't work, don't be surprised if the outcome is not what you expect.
> >
> > Nicolas, the measurement and rendering pipelines do not need to be the same.
> >
> > The question is what the creator of the PET images intended their window values (if any) to be applied to.
> >
> > SUV calculations (with some vendors specificities) are described in detail at https://qibawiki.rsna.org/index.php/Standardized_Uptake_Value_(SUV).
> >
> > David
> > On Tuesday, May 2, 2023 at 9:45:42 AM UTC-4, Steven Nichols wrote:
> > > On Thursday, April 27, 2023 at 12:04:36 PM UTC-5, Nicolas Roduit wrote:
> > > > Should the following IHE recommendation be absolutely implemented in a viewer?
> > > >
> > > > Basic Image Review (BIR) Page 36, line 860 of https://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_Suppl_BIR.pdf
> > > > > The grayscale rendering pipeline shall be appropriate to the SOP Class and modality. If Rescale Slope and Rescale Intercept are present in the image for MR and PET and XA/XRF images, they shall be ignored from the perspective of applying window values, and for those SOP Classes, window values shall be applied directly to the stored pixel values without rescaling.
> > > >
> > > > Because this recommendation conflicts with the need to have pixels with the application of Rescale Intercept and Rescale Slope for SUV calculation on PET exams. In general, the density measurement tools take the pixel values after applying Modality LUT.
> > > >
> > > > SUVbw = (stored pixel value in Pixel Data (0x7FE0,0x0010) + Rescale Intercept (0x0028,0x1052))* Rescale Slope (0x0028,0x1053) * SUVbwScaleFactor
> > > Hi Nicolas,
> > >
> > > The IHE Rad Tech committee is in the process of promoting BIR to Final Text.
> > > We plan to update this requirement to better follow DICOM display pipeline requirements.
> > > See proposed edits to 4.16.4.2.2.5.4 here: https://docs.google.com/document/d/103W3xlvu125Yz64bmOG2v-WaVYKKshur/edit
> > >
> > > Steve
> > >
> > On Thursday, April 27, 2023 at 1:04:36 PM UTC-4, Nicolas Roduit wrote:
> > > Should the following IHE recommendation be absolutely implemented in a viewer?
> > >
> > > Basic Image Review (BIR) Page 36, line 860 of https://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_Suppl_BIR.pdf
> > > > The grayscale rendering pipeline shall be appropriate to the SOP Class and modality. If Rescale Slope and Rescale Intercept are present in the image for MR and PET and XA/XRF images, they shall be ignored from the perspective of applying window values, and for those SOP Classes, window values shall be applied directly to the stored pixel values without rescaling.
> > >
> > > Because this recommendation conflicts with the need to have pixels with the application of Rescale Intercept and Rescale Slope for SUV calculation on PET exams. In general, the density measurement tools take the pixel values after applying Modality LUT.
> > >
> > > SUVbw = (stored pixel value in Pixel Data (0x7FE0,0x0010) + Rescale Intercept (0x0028,0x1052))* Rescale Slope (0x0028,0x1053) * SUVbwScaleFactor

Thank you David for the clarification.

I'd like it to work properly without necessarily being complicated ;)

It's only for PET where it seems more difficult to reconcile windowing with SUV values that are calculated from pixels.

Indeed, it would have been more appropriate to calculate the SUV with the Real World Value sequence. However, as PETs have no Modality LUT Data, we can calculate the SUVs (min, max and pixel mean) from the result of the original pixels by applying a linear transformation.

Another solution would simply be to handle a float image as output when the Rescale Slope is a small value. The Modality LUT Module already transforms unsigned image types into signed ones. This is relatively simple if the viewer tools already support DICOM floating point pixel data.

Le Friday, May 5, 2023 à 2:58:56 PM UTC+2, David Clunie a écrit :
> Do you want it to be simple, or do you want it to work?
>
> When a modality vendor creates images with rescale values that produce small floating point results, yet includes window values that are clearly intended to apply to large integers (presumably stored pixel values), what are you going to do (whether they were "right" or not to do that in the first place)?
>
> The original BIR requirement, poorly worded or not, is intended to address this concern.
>
> The MR IOD [1] does NOT include the Modality LUT Module (despite the encoding by some vendors), nor does the MR Image Module contain Rescale attributes, so the additional presence of Rescale attributes undermines the interpretation of the VOI LUT Module (i.e., it violates the Standard Extended rules [2]). "Bad" though such an object may be, the user doesn't care (just wants it to work, not look all black by default, and report measurements as intended by the creator). A proposed CP to add Rescale attributes to the MR Image IOD was rejected (CP 63).
>
> The PET IOD [3] does NOT include the Modality LUT Module either, but does include the Rescale attributes in the PET Image Module [4], so these are valid, but PET vendors seem to sometimes ignore the expectation of applying the window values to the rescaled values, rather than the stored pixel values, unfortunately.
>
> Going forward, with real-world values intended for measurements to replace any hokey unreliable dependence on rescaling, we have consciously separated measurement from rendering [5].
>
> David
>
> 1. https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_A.4.3.html
>
> 2. https://dicom.nema.org/medical/dicom/current/output/chtml/part02/sect_7.3.html#para_56636f6b-5190-427b-8fc3-4a96d8e5704e
>
> 3. https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_A.21.3.html
>
> 4. https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.8.9.4.html
>
> 5. https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.6.16.2.html#figure_C.7.6.16-6
> On Friday, May 5, 2023 at 3:42:43 AM UTC-4, Nicolas Roduit wrote:
> > Thank you for the answers.
> >
> > I give the point of view of someone who would like to implement the BIR profile. The LUT pipeline seems to me already quite complicated and I notice that there are few viewers that strictly implement all aspects of the pipeline. Therefore, doubling the pipeline doesn't seem to me to be the best idea, not to mention that it would have an effect on the performance by doubling the creation of 16-bit images. If we go in this direction, we should have a clear definition of the use cases for both.
> >
> > In general, it seems to me more logical that the measurement tools (density, statistics, SUV...) should report the pixel value at the Modality LUT level of the pipeline of what is displayed. By having 2 pipelines, we will measure data from an image that is not part of the render pipeline.
> >
> > @David can you specify the field issues? Is it in relation to the output values after the transformation?
> > Le Wednesday, May 3, 2023 à 11:33:41 PM UTC+2, David Clunie a écrit :
> > > We originally put that requirement in BIR for a reason - practical experience with MR and PET and XA/XRF from the field ... IHE Rad-Tech can screw with the profile in detrimental ways all they like, since I am not there anymore to defend it, but if the viewer doesn't work, don't be surprised if the outcome is not what you expect.
> > >
> > > Nicolas, the measurement and rendering pipelines do not need to be the same.
> > >
> > > The question is what the creator of the PET images intended their window values (if any) to be applied to.
> > >
> > > SUV calculations (with some vendors specificities) are described in detail at https://qibawiki.rsna.org/index.php/Standardized_Uptake_Value_(SUV).
> > >
> > > David
> > > On Tuesday, May 2, 2023 at 9:45:42 AM UTC-4, Steven Nichols wrote:
> > > > On Thursday, April 27, 2023 at 12:04:36 PM UTC-5, Nicolas Roduit wrote:
> > > > > Should the following IHE recommendation be absolutely implemented in a viewer?
> > > > >
> > > > > Basic Image Review (BIR) Page 36, line 860 of https://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_Suppl_BIR.pdf
> > > > > > The grayscale rendering pipeline shall be appropriate to the SOP Class and modality. If Rescale Slope and Rescale Intercept are present in the image for MR and PET and XA/XRF images, they shall be ignored from the perspective of applying window values, and for those SOP Classes, window values shall be applied directly to the stored pixel values without rescaling.
> > > > >
> > > > > Because this recommendation conflicts with the need to have pixels with the application of Rescale Intercept and Rescale Slope for SUV calculation on PET exams. In general, the density measurement tools take the pixel values after applying Modality LUT.
> > > > >
> > > > > SUVbw = (stored pixel value in Pixel Data (0x7FE0,0x0010) + Rescale Intercept (0x0028,0x1052))* Rescale Slope (0x0028,0x1053) * SUVbwScaleFactor
> > > > Hi Nicolas,
> > > >
> > > > The IHE Rad Tech committee is in the process of promoting BIR to Final Text.
> > > > We plan to update this requirement to better follow DICOM display pipeline requirements.
> > > > See proposed edits to 4.16.4.2.2.5.4 here: https://docs.google.com/document/d/103W3xlvu125Yz64bmOG2v-WaVYKKshur/edit
> > > >
> > > > Steve
> > > >
> > > On Thursday, April 27, 2023 at 1:04:36 PM UTC-4, Nicolas Roduit wrote:
> > > > Should the following IHE recommendation be absolutely implemented in a viewer?
> > > >
> > > > Basic Image Review (BIR) Page 36, line 860 of https://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_Suppl_BIR.pdf
> > > > > The grayscale rendering pipeline shall be appropriate to the SOP Class and modality. If Rescale Slope and Rescale Intercept are present in the image for MR and PET and XA/XRF images, they shall be ignored from the perspective of applying window values, and for those SOP Classes, window values shall be applied directly to the stored pixel values without rescaling.
> > > >
> > > > Because this recommendation conflicts with the need to have pixels with the application of Rescale Intercept and Rescale Slope for SUV calculation on PET exams. In general, the density measurement tools take the pixel values after applying Modality LUT.
> > > >
> > > > SUVbw = (stored pixel value in Pixel Data (0x7FE0,0x0010) + Rescale Intercept (0x0028,0x1052))* Rescale Slope (0x0028,0x1053) * SUVbwScaleFactor