Page MenuHomePhabricator

Compatibility of mitk data types to vtk/itk/vnl data types
Closed, WontfixPublic

Description

At the moment, when using mitk data types (e.g. mitk::Point3D) together with algorithms of itk/vtk/vnl/(etc.) manual conversions between the data types are often needed even for simple mathematical operations like addition or multiplication. This is sometimes caused by different scalar types (e.g. float in mitk and double in itk) or by incompatible data types (e.g. vtk vector and itk vector). The same problems can occur when working with matrices (e.g. vnl matrix with mitk scalar type and itk matrix with double precision).

This leads to many lines of code to convert between the different data types. Some people even implemented their own static help methods to convert and save code.

An example class which already offers conversion methods is mitk::transform (module CameraCalibration), but it is only used for transformations. It would make programming easier and save many lines of codes if this methods would be available all over mitk (e.g. inside the core).

One possibility would be to create a class for mitk::Point3D and include these conversion methods and maybe also overwrite the operators. Similar classes must be extended (or created) for conversion of matrices.

However, other ideas are also welcome.

Event Timeline

We could add conversion operators and suitable constructors to MITK classes for these purposes. However, I think it is not trivial to ensure that the creation of (possibly many) temporary objects within a set of operations requiring conversions does not lead to excessive runtime overhead.

I am also confronted with this task now.

We could add conversion operators and suitable constructors to MITK classes for these purposes.

Since our Vector3D and Point3D are just typedefs, constructor and operator overloading is not possible. We would need to define our own classes first.

For the time being i would prefer Alfreads approach:
Create a class with static conversion functions inside the core.

Some operators could also be implemented as free functions. In some cases, this is preferable anyway.

kislinsk claimed this task.
kislinsk added a subscriber: kislinsk.
This task was automatically closed because it wasn't updated at least since July 2016 (over 2 years). Please re-open this task if you think that it is still relevant. This most probably means that you will resolve it.