[Dcmlib] [Fwd: Re: Pixel type in template code]

[Mathieu Malaterre]

On why gdcmFile.GetPixelType is *very* limited for application level...

-------- Original Message --------
Subject: Re: Pixel type in template code
Date: Fri, 11 Nov 2005 12:41:47 GMT
From: David Clunie <dclunie at dclunie.com>
Reply-To: dclunie at dclunie.com
Newsgroups: comp.protocols.dicom
References: <JtHcf.63976$Bv6.7705 at twister.nyroc.rr.com> 
<dl1t7c$5h4 at news.Informatik.Uni-Oldenburg.DE>

Hi Marco, Mathieu

One needs to distinguish between what is necessary to store and
interpret the stored pixel values, as opposed to what is necessary
to store and/or interpret further down the grayscale pipeline.

A 16 bit integer is sufficient to store the pixel data in the
Pixel Data tag, iff that integer can be signed or unsigned as
per Pixel Representation, and downstream operations handle it
accordingly ... if passing the presence or absence of a sign
causes a problem, then as Marco says it is safer to promote the
values to the next size up, a signed 32 bit integer, since that
can represent either a signed or unsigned 16 bit pixel value
(don't forget to sign extend -ve values).

However, it is NOT advisable to store the values after the output
of the rescale operation, since these may be fractional ... for
example in PET, Rescale Slope is typical a very small fractional
value to convert pixel data values in MBq/ml to SUV. (Note that
all PET vendors "misinterpret" the standard and apply the VOI
window operation to the stored pixel values, not to the output
of the rescale operation, an irritating inconsistency).

In other words, in the general case, there is no integer
representation that can reliably encode the output of the
rescale operation, so it is better that one not do this,
but rather factor in the rescaling "on the fly" when
deriving transformations to apply windowing or report
back pixel values. Unless one stores floating point values,
and even if one does, PET windowing is a special case.

Don't forget that there are also some 32 bit images (RT Image
allows 32 bits as I recall, and the original single frame
secondary capture image is completely unconstrained in this
regard).

To get back to the first part of original question, given the
potential range of stored pixel values (e.g. in your case 0 to
255) and given a set of rescale parameters (e.g. in your case
a slope of 1 and intercept of -64), then the range of the data
after the rescaling is potentially -64 to 191. Whether or not
the actual pixel values use all that range cannot be determined
without reading them all, but you have to allow for the
possibility, especially if you want to store the output of
the rescaling. The "real final range" is largely irrelevant
from an encoding perspective is it not, particularly for an
individual slice, since likely the next slice will have a
different "real final range" ?

But I reiterate that in the general case, if you are going to
store the output of the rescale operation, it has to be in a
float.

David

Marco Eichelberg wrote:
> Mathieu Malaterre wrote:
> 
>>     I was wondering if anyone has already deal with this problem. For 
>> instance let say your image is stored on 8bits unsigned data. What if 
>> you read an Intercept of -64. Does this means I have to read the data 
>> on signed short (16bits) data ? Or do people go over the data to find 
>> out the min and max of Pixel Data to find out the real final range ?
> 
> 
> DCMTK's implementation (our DicomImage class) would indeed use signed
> shorts to store the pixel values after application of the modality
> transformation. We don't compute a histogram in this case, which could
> be quite time consuming. DCMTK always uses the largest integer type
> that can represent the complete possible pixel range, i.e. byte,
> short or 32-bit int, signed or unsigned, to store each sample.
> 
>> Another nasty problem is if your slope is express as a floating point 
>> value, in that case whatever type was used to store the image, in the 
>> end you need to declare your image as Pixel Type= float.
> 
> 
> Not necessarily. Our implementation would perform the transformation
> in floating point, but would store the results as integer numbers
> since pixel values cannot be float in DICOM anyway, i.e. all further
> steps of the grayscale processing pipeline produce integers as
> output and expect integers as input.
> 
> Regards,
> Marco Eichelberg
> OFFIS