[Insight-developers] GDCM: How to find out the correct pixel type

[Mathieu Malaterre]

The code you send me previously (the GetImageType thing) would return
INT for the following DICOM file:

(0028,0100) US 16                                       #   2, 1 BitsAllocated
(0028,0101) US 12                                       #   2, 1 BitsStored
(0028,0102) US 11                                       #   2, 1 HighBit
(0028,0103) US 0                                        #   2, 1
PixelRepresentation
(0028,1052) DS [-1000]                                  #   6, 1
RescaleIntercept
(0028,1053) DS [1]                                      #   2, 1 RescaleSlope

whereas it clearly fits into a SHORT buffer.

The old code would assume that if the pixel was allocated on a 16bits
space then it's min/max could be deduce from the min/max of a 'short'
thus by applying a shift/scale or 1 * x - 1000 the assumed proper
PixelType would have been INT. However in DICOM you have another
notion: the size the pixel stored, even if you allocated 16bits on
disk you can only stored 12bits data, in which case the min/max of
this pixel is different and therefore even after applying the
shift/scale the PixelType one can use SHORT.

The issues I can think of are:
- if you have regression testing where one would check that the
instanciated itk::ImageFileReader was done using INT.
- A test written with hardcoded INT assuming that the output of the
reader would be INT might fail right now.

I guess that's all I can think of.

-Mathieu

On Dec 10, 2007 4:10 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> Mathieu,
>
> It's not clear from your message how this affects Slicer3.
>
> Bill
>
>
> On Dec 10, 2007 8:24 AM, Mathieu Malaterre <mathieu.malaterre at gmail.com>
> wrote:
>
> > Hi everyone,
> >
> >  I have finally implemented a fix for the issue with the slicer
> > plugin that would instanciate a INT or UINT itk::ImageFileReader where
> > a SHORT or USHORT would suffice. The fix was rather trivial
> >
> > $ cvs ci -m"ENH: Fix feature request: 0006138: Finding proper pixel
> > type for DICOM is cumbersome" itkGDCMImageIO.cxx
> > /cvsroot/Insight/Insight/Code/IO/itkGDCMImageIO.cxx,v  <--
> itkGDCMImageIO.cxx
> > new revision: 1.128; previous revision: 1.127
> >
> >  At the same time I added a small example that would dump the
> > component type / pixel type needed to properly instanciate the
> > itk::ImageFileReader so that also ITK user can take advantage of it.
> > This should hopefully solve the issue where a user would not be aware
> > of the DICOM specification for storing pixel data:
> >
> > $ cvs ci -m"ENH: Adding a piece of code to dump the correct pixel type
> > to instanciate the itk::ImageFileReader" DicomImageReadPrintTags.cxx
> > /cvsroot/Insight/Insight/Examples/IO/DicomImageReadPrintTags.cxx,v
> > <--  DicomImageReadPrintTags.cxx
> > new revision: 1.18; previous revision: 1.17
> >
> >  So the problem here is that a piece code and a particular dataset in
> > Slicer would instanciated a INT itk::ImageFileReader, whereas now it
> > will instanciate a SHORT itk::ImageFileReader. Does this violate the
> > backwarc compatible policy ?
> >
> >
> > Thanks,
> >
> > -Mathieu
> >
> > On Nov 22, 2007 3:49 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> >
> >
> >
> > > Mathieu,
> > >
> > > Here is some code we use in Slicer3 plugins to determine pixel and
> component
> > > type at run-time:
> > >
> > > namespace itk
> > > {
> > >   // Description:
> > >   // Get the PixelType and ComponentType from fileName
> > >   void GetImageType (std::string fileName,
> > >                      ImageIOBase::IOPixelType &pixelType,
> > >                      ImageIOBase::IOComponentType &componentType)
> > >     {
> > >       typedef itk::Image<unsigned char, 3> ImageType;
> > >       itk::ImageFileReader<ImageType>::Pointer imageReader =
> > >         itk::ImageFileReader<ImageType>::New();
> > >       imageReader->SetFileName(fileName.c_str());
> > >       imageReader->UpdateOutputInformation();
> > >
> > >       pixelType = imageReader->GetImageIO()->GetPixelType();
> > >       componentType = imageReader->GetImageIO()->GetComponentType();
> > >     }
> > >
> > >   // Description:
> > >   // Get the PixelTypes and ComponentTypes from fileNames
> > >   void GetImageTypes (std::vector<std::string> fileNames,
> > >                       std::vector<ImageIOBase::IOPixelType> &pixelTypes,
> > >                       std::vector<ImageIOBase::IOComponentType>
> > > &componentTypes)
> > >     {
> > >     pixelTypes.clear();
> > >     componentTypes.clear();
> > >
> > >     // For each file, find the pixel and component type
> > >     for (std::vector<std::string>::size_type i = 0; i <
> fileNames.size();
> > > i++)
> > >       {
> > >       ImageIOBase::IOPixelType pixelType;
> > >       ImageIOBase::IOComponentType componentType;
> > >
> > >       GetImageType (fileNames[i],
> > >                     pixelType,
> > >                     componentType);
> > >       pixelTypes.push_back(pixelType);
> > >       componentTypes.push_back(componentType);
> > >       }
> > >     }
> > >   }
> > >
> > > Bill
> > >
> >
> >
> >
> > --
> > Mathieu
> >
>
>



-- 
Mathieu