IO factory registration for Python modules

[dzenanz]

Description

Automatically register remote module IOs for regular image reading and writing in Python.

Expected behavior

pip install itk-scanco

image = itk.imread("file.isq") # image is successfully read

Actual behavior

pip install itk-scanco

ImageType = itk.Image[itk.ctype('signed short'), 3]
reader = itk.ImageFileReader[ImageType].New()
imageio = itk.ScancoImageIO.New()
reader.SetImageIO(imageio)
reader.SetFileName(file_name)
reader.Update()
image = reader.GetOutput() # image is successfully read

Additional Information

Starting point for investigation:

ITK/Wrapping/Generators/Python/itk/support/itkExtras.py

Lines 675 to 678 in 7f36e8e

	if pixel_type:
	image_IO = itk.ImageIOFactory.CreateImageIO(
	io_filename, itk.CommonEnums.IOFileMode_ReadMode
	)

[thewtex]

Perhaps in one of the other support modules we could add a register_remote_module_factories function, e.g.

_REMOTE_FACTORIES_REGISTERED = False

def register_remote_module_factories():
	if _REMOTE_FACTORIES_REGISTERED:
		return
	
	imageio_factories = filter(lambda x: 'ImageIOFactory' in x, dir(itk))
    for factory in imageio_factories:
       # Do we have to worry about duplicate registration here?
       factory.RegisterOneFactory()
	_REMOTE_FACTORIES_REGISTERED = True

Then, call register_remote_module_factories from itk.imread, itk.imwrite.

[blowekamp]

Another possibility is to use ITK's dynamic loading of shared libraries which contain the "itkLoad" method for factory registration. Here is a PR related to generating the required code for factories (ImageIO only?) with CMake:

#134

[thewtex]

ITK's dynamic loading of shared libraries

For performance reasons, we do not want to load all possible shared libraries.

[blowekamp]

For performance reasons, we do not want to load all possible shared libraries.

If the installation structure is such that the libraries with dynamic "itkLoad" methods are in one path/location this could be overcome. However, this may not be the best solution for the issue above, just presenting an option.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[dzenanz]

Did we decide not to do this? When custom IO is required, it needs to be specified in the imread call.

[thewtex]

We should still add this support so the io is not required to be passed to imread.

[tbirdso]

Revisiting this issue as it is especially relevant with FFT factories being added in #2836 which do not have an extra Reader/Writer class to typically handle default registration.

Will investigate additional code injection in igenerator.py, possibly with a new factories field in <Module>Config.py output files that forces files with relevant factories to be actively loaded where ncessary.

@tbirdso

[tbirdso]

Proposing that we bump this to a later milestone than ITK 5.3. This issue has merit but depends on factory synchronization in #2909 / #3071 which is not yet merged. Will require nontrivial changes to Python module loading and dependency checks, including new field(s) in igenerator.py.

Ideally if ITK remote modules register factories to the base object factory list on load, then a workaround for this is to include an itk.force_load() step to ensure all loads take place before any calls that attempt to use the object factories. However, I haven't tested this with remote modules recently and I'm not sure that it will be quite that straightforward.

This issue certainly still has merit and can be pursued in a 5.3.post or 5.4.pre milestone.

cc @dzenanz @thewtex

[tbirdso]

@thewtex Are you taking this one on for 5.3 or still bumped to 5.4?

[thewtex]

@tbirdso looking at this for 5.3 since it impacts another issue reported in Slicer.

[tbirdso]

🎉