The wish list is provided by members of the ITK development community. These requests will not necessarily be included in ITKv5.

Outstanding wishes

A detailed wish list was put together by the community when preparing for ITK v4. Many of the wishes expressed there could not be fulfilled at the time but are still valid:

• https://itk.org/Wiki/ITK_Release_4/Wish_List

Image IO

• Replacing current integer pixel IO types defined in itk::ImageIOBase by fixed width integer types
  • unsigned short -> uint16_t
  • short -> int16_t
  • unsigned int -> uint32_t
  • int -> int32_t
  • unsigned long -> uint64_t
  • long -> int64_t
  • Portability issue of "char", "signed char" and "unsigned char" need to be discussed and addressed before using uint8_t and int8_t
    • char and unsigned char would keep being defined as char and unsigned char as these types is wildly use image formats.
• Currently, the size of each type may vary from one platform to another.
• This is especially true for 'long' that is 32 bits on Windows/Visual Studio C++ 2013 (64 bits) but 64 bits on 64 bits Unix systems.
• Files saved on one platform should be read the same on a different platform.
• This would avoid having to compare `sizeof(mytype)` to know what type to use on a specific platform.
• This issue was raised in this patch suggestion

Requiring CMake >= 3.0

• Currently supports CMake >=2.8.9 mostly to support Ubuntu 14.04 LTS (5 year support)
• Speed up CMake configure time, by doing less compiler testing or by sharing those results between library components

C++11 throughout

As ITK uses templates heavily, it would greatly benefit from usage of few C++11 goodies, especially auto and decltype.

To take a step further, requiring the latest c++ standard (C++14? C++17?) available when starting a v5 endeavour could also be discussed.

Note: Some c++ >= 11 features may not be supported by CastXML (and by pygccxml): https://github.com/CastXML/CastXML/issues/72 Before implementing fancy stuff it should be double-checked if it does not break the Wrappings.

To justify the change I’d like to see some good use of it in ITK. Some things that first come to mind:

• Support move semantics for the core ITK objects
• Support initializer lists in constructors of array like objects
• Have implementations that make use of C++11 threads
• Have a FunctorFilter which supports lambda expressions
• Rvalue support
• A updated style guideline which requires less typedefs ( auto keyword )

VNL->Eigen

Replace VNL by Eigen, which is much more modern.

Wrapping

• Take into account default template arguments in Python wrappings. See http://review.source.kitware.com/#/c/21606/ for discussion.

Filter Refactoring

• The current Functor based filters create code bloat because each class instance requires two instantiated classes. An alternative Functor approach should be used where the same class can be used any functor. One approach is to use a "SefFunctor" method which generates the GenerateData method.

Uncategorized minor wishes

• Suport for remote module testing against multiple versions of ITK.
• Being able to compile a remote module against an installed ITK would be nice for this structure.
• We should consider stripping down the toolkit into a set of core modules for ITK 5, and putting less-used modules into Remote Modules
  • Measure the code coverage for Remote Modules.
• Measure the code coverage per PR.
• Rolling compiler support. Each new release will support compilers released in the last 3-5 years. This will allow us to gradually adopt newer language versions, as C++ standards committee aims to revise the language every 3 years.
• Better document and advertise tools that seem extremely useful for making the use (configure, build, use) of ITK or the development of new modules less dependent on the local computing resources, or more automated and flexible, improvements to CI, use of cookiecutter, etc. There are other tools/projects such as itk.js whose adoption seem to be low.
• Update icon in maintenance directory.