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

[Mathieu Malaterre]

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).

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!).

> 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*.

> 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.

> 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.

> 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 ?


-- 
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.