[Insight-users] how to read images with unknown number of channels at build time ?

Karthik Krishnan Karthik.Krishnan at kitware.com
Fri Mar 3 17:41:22 EST 2006


Just to clarify, its the up to you to choose a representation for the 
image (with run time variable number of channels) being read in.

For instance given a diffusion weighted dataset such as (the header): 
ftp://itk.org/pub/namic/DTI/Data/dwi.nhdr, or its meta-image equivalent: 
ftp://itk.org/pub/namic/DTI/Data/xt_dwi.mhd,

You could read such an image as a
1. 3D image with 31 channels -  itk::VectorImage< short, 3 >
2. 31 3D images   - 31 itk::Image< short, 3 >
3. 4D image with dims[3] = 31 - itk::Image< short, 4 >

I assumed you wanted the first, which may not be the case.

Remember that the organization of pixels in the file will affect what 
you read (assuming you were reading naively at one shot..)

1. Readers instantiated over images of kind 1 assume an order.. R G B R 
G B R G B ...
2. Readers instantiated over images of kind 2 and 3 assume ..     R R R 
...G G G... B B B ..

Of course, you could always do your IO tricks to reorganize memory 
locations..

-karthik

Kent Williams wrote:

> It is better, on the whole, to know what you're reading and then 
> respond accordingly.
>
> Presently there is no itk::FileSniffer, as it were. 
> itk::ImageFileReader does try to load whatever path you ask it to and 
> do something reasonable with the data. But there are a couple of  
> 'gotchas' if you want to keep things completely general:
>
> 1. File formats where images of dimension > 3 are stored as 
> two-dimensional slices. Then, itk::ImageSeriesReader is the tool of 
> choice, instead of itk::ImageFileReader.
> 2. Cases such as yours, where some attribute of the file on disk 
> affects how you will process it.
>
> The workaround is to use an itk:ImageFileReader instance to sneak a 
> look at the files attributes, before actually reading the image. Below 
> is a function that illustrates how to snoop around for information 
> about the file you're trying to load.  This feels to me like breaking 
> encapsulation, but there currently isn't any other way.
> To get even more nefarious, you can call 
> itk::ImageIOBase::GetNameOfClass() to find out which file reader 
> claims to be able to read the file.  We use this in order to handle 
> DICOM images specially. Our application (which didn't originally use 
> ITK Image I/O) had the convention that when you give the name of a 
> slice of a DICOM file, then you want to read all the slices in the 
> containing directory that are members of the same DICOM series.
>
> int FileInfo(const std::string &path)
> {
>  typedef itk::Image<char,4> TestImageType; // pixel type doesn't 
> matter for current purpose
>  typedef itk::ImageFileReader<TestImageType> TestFileReaderType; // 
> reader for testing a file
>  TestFileReaderType::Pointer onefileReader = TestFileReaderType::New();
>   onefileReader->SetFileName(path.c_str());
>  try
>    {
>    onefileReader->GenerateOutputInformation();
>    }
>  catch(itk::ExceptionObject &excp)
>    {
>    return -1;
>    }
>    // grab the ImageIO instance for the reader
>  itk::ImageIOBase *imageIO = onefileReader->GetImageIO();
>    unsigned int NumberOfDimensions =  imageIO->GetNumberOfDimensions() 
> std::endl;
>    unsigned dims[32];   // almost always no more than 4 dims, but ...
>    unsigned origin[32];
>    double spacing[32];
>    std::vector<double> directions[32];
>    for(unsigned i = 0; i < NumberOfDimensions && i < 32; i++)
>      {
>      dims[i] = imageIO->GetDimensions(i);
>      origin[i] = imageIO->GetOrigin(i);
>      spacing[i] = imageIO->GetSpacing(i);
>      directions[i] = imageIO->GetDirection(i);
>      }
>   // PixelType is SCALAR, RGB, RGBA, VECTOR, COVARIANTVECTOR, POINT, 
> INDEX
>   itk::ImageIOBase::PixelType pixelType = imageIO->GetPixelType();
>   // IOComponentType is UCHAR, CHAR, USHORT, SHORT, UINT, INT, ULONG, 
> LONG, FLOAT, DOUBLE
>   itk::ImageIOBase::IOComponentType componentType = 
> imageIO->GetIOComponentType();
>    const std::type_info &typeinfo typeInfo = 
> imageIO->GetComponentTypeInfo();
>    // NumberOfComponents is usually one, but for non-scalar pixel 
> types, it can be anything
>   unsigned int NumberOfComponents = imageIO->GetNumberOfComponents();
>   return 0;
> }
>
> Gaetan Lehmann wrote:
>
>> Hi,
>>
>> Is it possible to write code able to read an image with an unknown 
>> number of channels at build time, and to extract each channel in an 
>> individual image ?
>> If yes, with which classes can it be done ?
>>
>> Thanks,
>>
>> Gaetan
>>  
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Insight-users mailing list
>> Insight-users at itk.org
>> http://www.itk.org/mailman/listinfo/insight-users
>>  
>>
>
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
>


More information about the Insight-users mailing list