[ITK-dev] Unexpected Voxel Size difference between ITK3 & ITK4

[Seun Odutola]

Hello everyone,

       I have got this problem when reading a Minc2 file. I’m currently on the verge of completing the transition of ITK 3 to ITK 4 but realized on testing some of our minc2 files (Unit test) which previously passed in 3 seem to fail in 4. On further investigation of both codes (ITK 3 & 4) I noticed the reason for this failure was that for example reading a specific file I was expecting the Component Type returned to be SHORT whereas I was getting FLOAT.

Note: am running ITK git master

// snippet

// In ITK 4 (ITK git master)
// ITK file name : itkMINCImageIO.cxx
// function -> ReadImageInformation
// Minc2 test file :  mni_icbm152_t1_tal_nlin_asym_09c.mnc

// set the file data type
  if(slice_scaling_flag || global_scaling_flag)
    {
    switch ( volume_data_type )
      {
      case MI_TYPE_FLOAT:
        this->SetComponentType(FLOAT);
        break;
      case MI_TYPE_DOUBLE:
        this->SetComponentType(DOUBLE);
        break;
      case MI_TYPE_FCOMPLEX:
        this->SetComponentType(FLOAT);
        break;
      case MI_TYPE_DCOMPLEX:
        this->SetComponentType(DOUBLE);
        break;
      default:
        this->SetComponentType(FLOAT);
        break;
      } //end of switch
        //file will have do
    }
  else


// In ITK 3 (3.20.1)
// ITK file name : itkMINC2ImageIO.cxx
// function -> ReadImageInformation
// Minc2 test file :  mni_icbm152_t1_tal_nlin_asym_09c.mnc

// lines 397 onwards
// set the file data type
  switch (volume_data_type)
    {
    case MI_TYPE_BYTE:
      this->SetComponentType(CHAR);
      break;
    case MI_TYPE_UBYTE:
      this->SetComponentType(UCHAR);
      break;
    case MI_TYPE_SHORT:
      this->SetComponentType(SHORT);
      break;
    case MI_TYPE_USHORT:
      this->SetComponentType(USHORT);
      break;
    case MI_TYPE_INT:
      this->SetComponentType(INT);
      break;
    case MI_TYPE_UINT:
      this->SetComponentType(UINT);
      break;
    case MI_TYPE_FLOAT:
      this->SetComponentType(FLOAT);
      break;
    case MI_TYPE_DOUBLE:
      this->SetComponentType(DOUBLE);
      break;
    case MI_TYPE_SCOMPLEX:
      this->SetComponentType(SHORT);
      break;
    case MI_TYPE_ICOMPLEX:
      this->SetComponentType(INT);
      break;
    case MI_TYPE_FCOMPLEX:
      this->SetComponentType(FLOAT);
      break;
    case MI_TYPE_DCOMPLEX:
      this->SetComponentType(DOUBLE);
      break;
    default:
      itkDebugMacro("Bad data type ");
      return;
    } //end of switch


Note that in ITK 3 the slice_scaling_flag is set to way above the snippet but is never used as a condition for setting the ComponentType so in my case I get back the SHORT I was expecting whereas in ITK 4 (see code above) the slice_scaling_flag is always set to 1 and the ComponentType is redefined as FLOAT which isn’t what I’m expecting. Lastly, I have also confirmed that indeed it’s expected to be a SHORT not FLOAT by using Minc Info to examine the above file named test file. So my question is could this have been a mistake in ITK 4 which means the way ITK 3 went about handling the file was correct or could it have been the other way around.

Thanks 

Regards,
   Seun



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20151120/6db3e4b4/attachment.html>