[Insight-users] Possible bug reading DICOM MONOCHROME1 images with Pixel Padding Value != 2^bits stored-1

[Iván Macía]

Hi again,

I come back with the technical details. My diagnosis of the problem does not
seem totally correct and does not seem so simple. In many of the MG images
we have with Photometric Interpretation MONOCHROME1, simply inverting the
stored pixel values for presentation works (this is the current
implementation in GDCM 1.x in ITK). Rescale Slope/Intercept are 1 and 0 so
these are not the problem right now.

Now we have this other MG image which is also MONOCHROME1 but that appears
all black with the WL/WW values taken from DICOM. A careful look at the
pixel values obtained for the ITK image shows that:

- The padded pixel values, that occupy most of the area of the image but the
right side, take a value of 32768 which results from the inversion of 
  ( 65535 - 32767 ) in gdcm::PixelReadConvert::ConvertFixGreyLevels() which
on the other hand would be incorrect. This is because Pixel Padding Value
(0028,0120) is 32767 where the software expects 65535 for 16 bits stored. 
- The right area of the screen, which is occupied by the breast itself holds
stored values around 9000 which are converted to 65535 - 9000 = 56535. This
is the final value stored in the ITK image without any WW/WL applied which
is incorrect.

However if instead of inverting using x = 65535 - x, I use x = 32767 - x,
the padded pixel values get 0 intensity and are displayed in black, but the
breast itself appears all white after applying WL/WW. A careful look at
these values shows that they are about 20000, which for a WL/WW value of
7800/3600 of course appear in white. It seems like the values of the breast
should remain untouched.

The image seems to be correct since there are some softwares able to
interpret it as I would expect.

Now looking more carefully at the DICOM metadata I found these tags which
may be involved in the problem:
(2050,0020) Presentation LUT Shape : INVERSE
And also
(0008,0068) Presentation Intent Type : FOR PRESENTATION

The problem is that I don't totally understand the explanation in the
standard but it seems like this tag is overriding the MONOCHROME1
photometric interpretation. In any case, the padding value needs to be
modified and converted to 0 for display otherwise the result is incorrect.

I read this text in part 3 of the standard C.8.11.3.1.2 Pixel Intensity
Relationship and Grayscale Transformations

"Photometric Interpretation (0028,0004) indicates whether lower values that
are the output of the
VOI Attributes should be displayed as darker or lighter. Since the output of
the equivalent of a
conceptual Presentation LUT is in P-Values, which are defined in PS 3.14
such that lower values
correspond to lower luminance levels, then the definition of the
Presentation LUT Shape
PS 3.3 - 2008
Page 670
- Standard -
(2050,0020), otherwise intended to be an identity transformation, must take
into account the effect
of the value specified for Photometric Interpretation (0028,0004).
Note: Regardless of the values of Pixel Intensity Relationship (0028,1040)
and Pixel Intensity
Relationship Sign (0028,1041), the grayscale transformations to be applied
to the Pixel Data
(7FE0,0010) are defined by the equivalent of the Modality LUT (Rescale Slope
(0028,1053) and
Rescale Intercept (0028,1052)), Value of Interest Attributes, Photometric
Interpretation
(0028,0004) and the equivalent of the Presentation LUT (Presentation LUT
Shape
(2050,0020)). However, the combination of the grayscale transformations and
the description of
the pixel intensity relationship, together define whether, for example, air
is expected to be
displayed as black or white."

And this other in the Part 4 of the standard in N.2.1.2 Presentation LUT

" Since the grayscale transformation pipeline fully defines all
transformations applied to the
stored pixel values in the referenced image object, the value of Photometric
Interpretation
(0028,0004) in the referenced image object is ignored and overridden. This
implies that either
the creator of the presentation state chose a pipeline that reflects the
Photometric
Interpretation (0028,0004) , or chose to ignore or override the Photometric
Interpretation, and
invert the image relative to what is specified by Photometric
Interpretation. If the Modality LUT
and VOI LUT do not have a negative slope, one can achieve the effect of
inversion of the
polarity of an image by choosing Presentation LUT Shape of IDENTITY or
INVERSE that
displays the minimum pixel value as white rather than black in the case of a
Photometric
Interpretation of MONOCHROME2, or black rather than white in the case of a
Photometric
Interpretation of MONOCHROME1. If Presentation LUT Data is sent, then one
can invert the
value of the entries in the LUT table to achieve inversion of polarity."

Does someone know how this pixel data should be correctly interpreted? It
seems like in this case I should not invert pixels, but in this case what
would happen with the padding value?

Thanks in advance

Iván


> -----Mensaje original-----
> De: Iván Macía [mailto:imacia at vicomtech.org]
> Enviado el: martes, 17 de febrero de 2009 17:15
> Para: 'Mathieu Malaterre'
> CC: 'Bill Lorensen'; 'insight-users at itk.org'; 'David Clunie'
> Asunto: RE: [Insight-users] Possible bug reading DICOM MONOCHROME1
> images with Pixel Padding Value != 2^bits stored-1
> 
> Hi again Mathieu,
> 
> This was quite illustrative, I understand better the implications,
> thank you.
> 
> My comments below...
> 
> 
> > -----Mensaje original-----
> > De: Mathieu Malaterre [mailto:mathieu.malaterre at gmail.com]
> > Enviado el: martes, 17 de febrero de 2009 15:35
> > Para: Iván Macía
> > CC: Bill Lorensen; insight-users at itk.org; David Clunie
> > Asunto: Re: [Insight-users] Possible bug reading DICOM MONOCHROME1
> > images with Pixel Padding Value != 2^bits stored-1
> >
> > Hi Ivan,
> >
> > On Tue, Feb 17, 2009 at 3:13 PM, Iván Macía <imacia at vicomtech.org>
> > wrote:
> > > Hi Mathieu, all,
> > >
> > > I understand your point and probably from a technical point of view
> > you may
> > > be right but I don't totally agree. Sorry if this is a long post,
> > just take
> > > a breath and read :)
> > >
> > > My knowledge of DICOM is limited, but, if I understand you well,
> you
> > mean
> > > that the final application should do all the work of interpreting
> > things
> > > like the Photometric Interpretation, Rescale Slope/Intercept and
> > other pixel
> > > interpretation operations, which are needed not only at a
> > presentation level
> > > but also at an image processing level. This means I would need to
> > introduce
> > > this code in every application that uses DICOM.
> >
> > Hum, I was simply talking about Photometric Interpretation. I
> > completely agree that Rescale Slope/Intercept should be applied on a
> > par file, as it can vary from one slice to the other and thus would
> > make a complete non-sense volume from an ITK point of view. And this
> > is the default gdcm 2.x behavior (=apply rescale slope, but do not
> > invert MONOCHROME1 image).
> 
> I have to check gdcm 2.x better. Last time I missed some things from
> gdcm 1.x and didn’t dare to switch since we use it directly in several
> places.
> 
> >
> > ITK does not clearly define Photometric Interpretation (contrarily to
> > VTK) as it is a Pixel oriented library (it is even templated over the
> > Pixel Type, isn't it great!).
> 
> I think this is one of the problems. If I don’t have Photometric
> interpretation in ITK and the resulting image output ITK image from the
> DICOM reader is not interpreted and converted to MONOCHROME2, I would
> not know that it is MONOCHROME1 and would have to invert. For example
> with color images RGB is always returned and don’t have to care. If one
> thing happens and the other not this is inconsistent IMO.
> 
> >
> > > IMHO, interpreting some important DICOM fields is a repetitive and
> > bug prone
> > > work that users of the library try to avoid. Otherwise I would have
> > to
> > > program my own library or layer on top of GDCM or ITK to do exactly
> > this
> > > (which would generate buggy code etc etc). If you ask me, I would
> > introduce
> > > part of this code as part of the library (maybe as some auxiliary
> > classes).
> > > In fact, this is what itk::GDCMImageIO does (i.e. applying Rescale
> > Slope /
> > > Intercept) and then, following this philoshophy, the code for
> > interpreting
> > > MONOCHROME1 should be introduced in itk. I agree with this, and as
> > you
> > > mention, maybe applying Rescale Slope / Intercept is not correct
> > after
> > > ConvertFixGrayLevels() but before. Also, maybe rescale/slope
> > intercept
> > > values could be modified at ITK level if images are MONOCHROME1,
> > knowing
> > > that this transformation has been applied (as a temporary patch).
> >
> > You made your point about Rescale Slope/Intercept very clear, and I
> > fully agree. You seems to be exaggerating a little over the impact of
> > MONOCHROME1 vs MONOCHROME2 as it only an inversion of the lookup
> table
> > *at rendering time*.
> >
> 
> Ok, ok maybe exaggerating a little in this case :)
> 
> > > Following your point of view transformations such as Rescale Slope
> /
> > > Interpret shouldn't be applied by the library, in this case ITK,
> but
> > some of
> > > the operations, are needed not only at a presentation level, but at
> > an image
> > > processing level too. I have seen in several forum threads problems
> > with
> > > researchers that don't know how to interpret the Rescale Slope /
> > Intercept
> > > tags and don't know if they are handling let's say the real CT
> > Hounsfield
> > > values when they should be focusing on developing algorithms and
> > methods
> > > that work with those images, regardless of how they are stored and
> > how to
> > > interpret DICOM format. This is what ITK does right now with
> Rescale
> > Slope /
> > > Intercept and I think this is a very nice feature. If someone
> really
> > really
> > > needs raw pixel data, options could be provided for this, or the
> > libraries
> > > could be used at a lower level.
> >
> > Still ok with you on rescale slope/intercept.
> >
> > > Not to mention that there are already some other operations that
> are
> > applied
> > > at a presentation level, such as W/L transformation, pixel transfer
> > to
> > > textures, etc. I would like not to focus on interpreting DICOM
> > specific
> > > things as if I loaded a MetaImage.
> >
> > That would be ideal, but again DICOM is NOT an image format (*). I do
> > not believe switching from MONOCHROME2 to MONOCHROME1 is such an easy
> > task as it was initially thought in GDCM 1.x early implementation. I
> > am pretty sure that changing this attribute would mean regenerating
> > the UIDs (among other things) as we are touching the Pixel Data
> > values.
> >
> 
> I understand and agree. This is already being touched in 1.x in
> ConvertFixGreyLabels() and ConvertHandleColor(), which, on the other
> hand, makes me possible to load, process and display any color image
> using itk::RGBPixel without headaches :)
> 
> > > We have already introduced quite a lot of code to further interpret
> > some
> > > DICOM peculiarities (such as series with intermixed volumes, with
> > different
> > > orientation, pixel types and sizes in their images, time series vs
> > volumes
> > > vs 3D+t series vs multi-frame images...). I would prefer to trust
> on
> > a
> > > public, well tested DICOM library to do this but unfortunately none
> > fulfills
> > > all our requirements. The closest thing we have found so far is
> GDCM
> > for
> > > DICOM and ITK for medical image processing. Currently they are
> being
> > used
> > > extensively in our applications and we would like to use them as
> much
> > as
> > > possible, report bugs, contribute bug fixes/code if necessary etc.
> >
> > Cool :) Thanks.
> >
> > > Of course this is my idea of what I would like the libraries to be
> > with
> > > respect to DICOM, and since I am not the original developer nor I
> pay
> > > anything for it, it is up to the developers/maintainers decide what
> > goes and
> > > what does not go in it.
> >
> > Long story short, I really do not feel comfortable changing the Pixel
> > Value simply to match a presentation request. One should be able to
> > request min/max value of the image and look for the value in the
> DICOM
> > dictionary and indeed verify they actually match the computed values.
> >
> > > Regarding the solution you propose mixing 1.x and 2.x, it is an
> > option, but
> > > I don't see it very practical for our current development since
> > several
> > > developers will have to follow the same process and some of them
> are
> > not
> > > into our organization. I would prefer to provide a patch myself,
> for
> > > internal use if necessary, at least as a temporary solution. Thanks
> > anyway,
> > > I will try and see what works and let you know.
> >
> > Well gdcm is open source, if you write a proper patch it will be
> > integrated in gdcm. This is clearly an issue. But keep in mind that
> > noone has worked on new feature on gdcm 1.x in years now.
> >
> 
> I need to think first a bit what is more convenient for us in the short
> tem. First I will try a quick solution since I don’t have much time. I
> will let you know if I can provide a decent patch later.
> 
> > > Buf, that was long and quite philosophical. But I would like to
> know
> > what
> > > are the future plans for DICOM in ITK in order to take some
> decisions
> > with
> > > time.
> > >
> > > On the other hand, like me finish thanking you all developers for
> the
> > nice
> > > work you are doing with these nice libraries that makes our life as
> > > developers/researchers a little easier ;)
> >
> > As you proposed there should be a way to preserve the old behavior of
> > inverting the grayscale values. This will be the expected behavior
> for
> > people registraring X-ray and MR (different photometric
> > interpretation). But this means there will be -potentially- incorrect
> > dicom attribute loaded in the DICOM data dictionary. Is this ok with
> > you ?
> >
> 
> Yes, that was what I meant that some of those conversions where needed
> for image processing. I think the behavior should be kept at least
> optionally. Regarding the DICOM, as long as I know what is happening
> with the data and saving DICOM is consistent it is ok for me.
> 
> Thanks again
> 
> Ivan
> 
> >
> > --
> > Mathieu
> >
> > (*) Not to mention that every vendors have the right to extend the
> > standard (Extended SOP) with there own set of tags, which means we
> are
> > potentially keeping attributes relating to the old value of the Pixel
> > Data.