Proposal to improve ITK factory registration CMake infrastructure


The key idea of the proposal linked below was to introduce a CMake function called itk_configure_factory allowing to associate relevant properties to CMake targets.

Ultimately, for each target, this function will configure the header


and will set the following target properties:


While reviewing ITK PR-2836 discussing the addition of a new type of factory related to FFT, I recalled about a proposal we put together to improve how factories are registered in ITK.

The original document was created in June 2016 and is publicly available as 2016.06.24_ITK_Improve_IO_Factory.

Related discussion

cc: @Tom_Birdsong @dzenanz @Niels_Dekker @Lee_Newberg @matt.mccormick

Some of the things proposed in this document have been implemented in the last 5 years.

@matt.mccormick I guess we should add this to the TODO list for ITKv6.

Thank you for including me with this topic! Slightly related, I recently “discovered” that the current approach does create many unnecessary RegisterManager instances for some applications. Specifically, until recently, 86 itk::ImageIOFactoryRegisterManager instances and 83 itk::MeshIOFactoryRegisterManager instances were constructed automatically, when starting the elastix executable! Each time a “RegisterManager.h” is included into another cxx file, another instance is constructed.

For elastix I suppressed the creation of these RegisterManager instances, by #undef ITK_IO_FACTORY_REGISTER_MANAGER, to avoid an indirect #include (via an ITK Reader or Writer). Then I just did #include those “RegisterManager.h” files directly, just once, in one dedicated cxx file. Not sure if that’s an official way to do it. :slight_smile:

@Niels_Dekker It may be beneficial to set the CMake variable ITK_NO_IO_FACTORY_REGISTER_MANAGER. That was the way it was done in SimpleITK. You may want to look at the UseITK.cmake file and documentation in the file to determine the side effect of not having that CMake variable defined.

1 Like