Page MenuHomePhabricator

The desired behavior of mitk::PixelType::operator==(std::type_info&) is unclear
Closed, InvalidPublic


mitk::PixelType has multiple private members to store the pixel type...
const std::type_info* m_TypeId;
const std::type_info* m_ItkTypeId;
the problem is, that the method

bool mitk::PixelType::operator==(const std::type_info& typeId) const

if (GetItkTypeId() == NULL)
  return false;
return (*GetItkTypeId() == typeId);


compares the internal type of ITkTypyId instead of m_TypeId. This leads to unexpected behaviour, if ITKTypeId is not set.

either a ITKTypeid, which matches the m_TypeId is generated when constructing the the object, or the type id should only be saved AND compared in the m_TypeId member. The operator== method should be adapted accordingly.

Event Timeline

I'm resetting the ? on core_modification_needed so that I'll get a new mail reminder once there is a change request.

@description: which of the two solutions would you implement?

Since I'm not sure about the desired behaviour I don't feel confident to decide this.

If we could generate a valid ItkTypeID in all cases, I would prefer to do it. But I fear that this will not be possible. Nevertheless, the code regarding generating ItkTypeIDs should be extended:

if(m_NumberOfComponents == 1)
  m_ItkTypeId = m_TypeId;
  m_ItkTypeId = NULL;

The m_TypeId refers only to the type_info of the scalar (!) type (see the docu). Thus, two PixelTypes may acutally be different although they have the same m_TypeId (maybe we should rename it in m_ScalarTypeId), if the number of components are different.

I guess the savest way would be to completely remove the operator== for std::type_info& (NOT the one for comparing two PixelType objects).

A preliminary test by declaring the supposably obsolete methods:

bool operator == (std::type_info .. )
bool operator != (std::type_info .. )


private yielded the following results:

getItkTypeId() is never used and could be removed consequentely

the operator, although comparing only the scalar type is definitely the "wrong" way, is utilized in the following macro, which can be found in mitkImageAccessByItk.h

#define _accessByItk_1(mitkImage, itkImageTypeFunction, pixeltype, dimension, param1) \

if ( pixelType == typeid(pixeltype) )                                                          \
{                                                                                              \
  typedef itk::Image<pixeltype, dimension> ImageType;                                          \
  typedef mitk::ImageToItk<ImageType> ImageToItkType;                                          \
  itk::SmartPointer<ImageToItkType> imagetoitk = ImageToItkType::New();                        \
  imagetoitk->SetInput(mitkImage);                                                             \
  imagetoitk->Update();                                                                        \
  itkImageTypeFunction(imagetoitk->GetOutput(), param1);                                       \

it could be replaced by pixelType.GetTypeId()== typeid(pixeltype)

However, I suggest leaving the == operator in and removing the "memory pointer" on the itkTypeid, so that only necessarys information is stored and ambiguities are avoided.

Bug is not relevant any more because itkTypeID is not obsolete any more; for vector valued images, itkTypeID is NULL by default;

kislinsk changed the task status from Invalid to Spite.Jun 27 2018, 1:33 PM
kislinsk added a project: Bulk Edit.
kislinsk changed the task status from Spite to Invalid.Jun 27 2018, 1:37 PM
kislinsk removed a project: Bulk Edit.