Difference between revisions of "IpPic Free Core"
Jump to navigation
Jump to search
m (JasminMetzger moved page Development/IpPicFreeCore to IpPic Free Core) |
|||
| Line 1: | Line 1: | ||
__NOTOC__ | __NOTOC__ | ||
<!-- ## page was renamed from development/IpPicFreeCore --> | <!-- ## page was renamed from development/IpPicFreeCore --> | ||
| − | |||
| − | |||
This page documentes the changes in the interface and code structure which were necessary for completely removing the dependancy of the Core module to the IpPic module. | This page documentes the changes in the interface and code structure which were necessary for completely removing the dependancy of the Core module to the IpPic module. | ||
| Line 8: | Line 6: | ||
Consequently, the `.pic` data format was replaced by the `.nrrd` data format on the position of the standard MITK data format. In the near future, storing to a `.pic` will be disabled. The loading of `.pic` will be supported longer. | Consequently, the `.pic` data format was replaced by the `.nrrd` data format on the position of the standard MITK data format. In the near future, storing to a `.pic` will be disabled. The loading of `.pic` will be supported longer. | ||
| − | The most affected class is `mitk::Image` since the whole management of the image data was done by the ` | + | The most affected class is `mitk::Image` since the whole management of the image data was done by the `IpPicDescriptor`. |
== Changes in mitk::Image == | == Changes in mitk::Image == | ||
| − | <pre><nowiki> | + | <pre><nowiki> |
'''Summary''' | '''Summary''' | ||
| Line 26: | Line 24: | ||
* '''mitk::ImageDescriptor''' which holds the dimension information for the image and a `std::vector` of descriptors for the image's channels | * '''mitk::ImageDescriptor''' which holds the dimension information for the image and a `std::vector` of descriptors for the image's channels | ||
* '''mitk::ChannelDescriptor''' which holds the essential information for a channel, i.e. its size and pixel type | * '''mitk::ChannelDescriptor''' which holds the essential information for a channel, i.e. its size and pixel type | ||
| + | |||
=== Image statistics === | === Image statistics === | ||
| − | All members of the `mitk::Image` class related to statistics computation were moved to a new object '''ImageStatisticsHolder'''. For temporary backward compatibility, the methods for accessing the statistics like ` | + | All members of the `mitk::Image` class related to statistics computation were moved to a new object '''ImageStatisticsHolder'''. For temporary backward compatibility, the methods for accessing the statistics like `GetScalarValueMax()` are still available in the interface of mitk::!Image, but are marked as deprecated. ''Old-style'' calls like: |
| − | <pre><nowiki> | + | <pre><nowiki> |
double scMax = m_Image->GetScalarValueMax(); | double scMax = m_Image->GetScalarValueMax(); | ||
</nowiki></pre> | </nowiki></pre> | ||
| Line 37: | Line 36: | ||
have to be replaced by: | have to be replaced by: | ||
| − | <pre><nowiki> | + | <pre><nowiki> |
double scMax = m_Image->GetStatistics()->GetScalarValueMax(); | double scMax = m_Image->GetStatistics()->GetScalarValueMax(); | ||
</nowiki></pre> | </nowiki></pre> | ||
| − | == Changes in mitk:: | + | == Changes in mitk::PixelType == |
With IpPic present, the PixelType was forced to hold a member of type `mitkIpPicType_t`. The re-worked PixelType stores the `std::type_info`. Also the creation of a PixelType instance has changed. There are three methods how to instantiate a PixelType object: | With IpPic present, the PixelType was forced to hold a member of type `mitkIpPicType_t`. The re-worked PixelType stores the `std::type_info`. Also the creation of a PixelType instance has changed. There are three methods how to instantiate a PixelType object: | ||
| Line 48: | Line 47: | ||
Single component pixel types ( i.e. scalar types) can be created like the following `float` type: | Single component pixel types ( i.e. scalar types) can be created like the following `float` type: | ||
| − | <pre><nowiki> | + | <pre><nowiki> |
mitk::PixelType myScalarPType = | mitk::PixelType myScalarPType = | ||
mitk::MakeScalarPixelType< float >(); | mitk::MakeScalarPixelType< float >(); | ||
| Line 55: | Line 54: | ||
PixelType instances for ITK image types are created like: | PixelType instances for ITK image types are created like: | ||
| − | <pre><nowiki> | + | <pre><nowiki> |
typedef itk::Image<itk::RGBAPixel<unsigned char>, 3> itkImageType; | typedef itk::Image<itk::RGBAPixel<unsigned char>, 3> itkImageType; | ||
| Line 63: | Line 62: | ||
And fully customized PixelType instances are created like: | And fully customized PixelType instances are created like: | ||
| − | <pre><nowiki> | + | <pre><nowiki> |
mitk::PixelType myCustomPType = | mitk::PixelType myCustomPType = | ||
mitk::MakePixelType<char, YMKType<char>, 3>(); | mitk::MakePixelType<char, YMKType<char>, 3>(); | ||
| Line 70: | Line 69: | ||
There are two public methods for getting the type_info from a PixelType object. | There are two public methods for getting the type_info from a PixelType object. | ||
| − | * ` | + | * `GetPixelTypeId()` returns the type of the whole pixel type |
| − | * ` | + | * `GetTypeId()` returns the type of the component ( i.e. unsigned char for the myPType in the example given above) |
| − | == Usage of | + | |
| + | |||
| + | == Usage of IpPic == | ||
Multiple algorithms located in the MitkExt module and also some Bundles still need to have access to the IpPic module. To provide backward compatibility, there are now two '''new modules''' | Multiple algorithms located in the MitkExt module and also some Bundles still need to have access to the IpPic module. To provide backward compatibility, there are now two '''new modules''' | ||
| Line 79: | Line 80: | ||
** contains all I/O related classes (`Writer`, `Reader`, `IOFactory`) previously located in Core/ | ** contains all I/O related classes (`Writer`, `Reader`, `IOFactory`) previously located in Core/ | ||
* '''LegacyAdaptors''' | * '''LegacyAdaptors''' | ||
| − | ** contains methods for casting between the new image format and an the IpPicDescriptor: ` | + | ** contains methods for casting between the new image format and an the IpPicDescriptor: `CastToIpPicDescriptor`, `CastToImageDescriptor` |
** all methods in this module are marked as '''deprecated''', including this module will cause the compiler to throw compile warnings (if enabled) | ** all methods in this module are marked as '''deprecated''', including this module will cause the compiler to throw compile warnings (if enabled) | ||
** further information is available from the [http://docs.mitk.org/nightly-qt4/mitkLegacyAdaptors_8h.html nightly generated documentation] | ** further information is available from the [http://docs.mitk.org/nightly-qt4/mitkLegacyAdaptors_8h.html nightly generated documentation] | ||
Revision as of 10:56, 19 November 2014
This page documentes the changes in the interface and code structure which were necessary for completely removing the dependancy of the Core module to the IpPic module.
Consequently, the `.pic` data format was replaced by the `.nrrd` data format on the position of the standard MITK data format. In the near future, storing to a `.pic` will be disabled. The loading of `.pic` will be supported longer.
The most affected class is `mitk::Image` since the whole management of the image data was done by the `IpPicDescriptor`.
Changes in mitk::Image
'''Summary''' The art of changes in the `Image` class is twofold. First, the !IpPicDescriptor and all related methods were replaced by new descriptor objects. Second, as part of the refactoring, the whole statistics computation was moved into a new object.
New descriptors
The IpPicDescriptor got replaced by two new descriptors:
- mitk::ImageDescriptor which holds the dimension information for the image and a `std::vector` of descriptors for the image's channels
- mitk::ChannelDescriptor which holds the essential information for a channel, i.e. its size and pixel type
Image statistics
All members of the `mitk::Image` class related to statistics computation were moved to a new object ImageStatisticsHolder. For temporary backward compatibility, the methods for accessing the statistics like `GetScalarValueMax()` are still available in the interface of mitk::!Image, but are marked as deprecated. Old-style calls like:
double scMax = m_Image->GetScalarValueMax();
have to be replaced by:
double scMax = m_Image->GetStatistics()->GetScalarValueMax();
Changes in mitk::PixelType
With IpPic present, the PixelType was forced to hold a member of type `mitkIpPicType_t`. The re-worked PixelType stores the `std::type_info`. Also the creation of a PixelType instance has changed. There are three methods how to instantiate a PixelType object:
Single component pixel types ( i.e. scalar types) can be created like the following `float` type:
mitk::PixelType myScalarPType = mitk::MakeScalarPixelType< float >();
PixelType instances for ITK image types are created like:
typedef itk::Image<itk::RGBAPixel<unsigned char>, 3> itkImageType; mitk::PixelType myPType = mitk::MakePixelType<itkImageType>();
And fully customized PixelType instances are created like:
mitk::PixelType myCustomPType = mitk::MakePixelType<char, YMKType<char>, 3>();
There are two public methods for getting the type_info from a PixelType object.
- `GetPixelTypeId()` returns the type of the whole pixel type
- `GetTypeId()` returns the type of the component ( i.e. unsigned char for the myPType in the example given above)
Usage of IpPic
Multiple algorithms located in the MitkExt module and also some Bundles still need to have access to the IpPic module. To provide backward compatibility, there are now two new modules
- IpPicSupport
- contains all I/O related classes (`Writer`, `Reader`, `IOFactory`) previously located in Core/
- LegacyAdaptors
- contains methods for casting between the new image format and an the IpPicDescriptor: `CastToIpPicDescriptor`, `CastToImageDescriptor`
- all methods in this module are marked as deprecated, including this module will cause the compiler to throw compile warnings (if enabled)
- further information is available from the nightly generated documentation