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

[Iván Macía]

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.