Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

N4BiasFieldCorrection fails for compiled ANTS #3138

Closed
salma1601 opened this issue Jan 4, 2020 · 7 comments · Fixed by #3273
Closed

N4BiasFieldCorrection fails for compiled ANTS #3138

salma1601 opened this issue Jan 4, 2020 · 7 comments · Fixed by #3273
Milestone

Comments

@salma1601
Copy link
Contributor

Summary

N4BiasFieldCorrection throws an error

Actual behavior

The rescale_intensities trait is set by default to False while it must not be specified for ANTS version under 2.1.0

Expected behavior

rescale_intensities should be undefined by default

How to replicate the behavior

We can replicate the behavior with compiled ANTs

Script/Workflow details

My Ants version

salma@salma-Latitude-E7450:~/CODE/sammba-mri $ N4BiasFieldCorrection --version
ANTs Version: 0.0.0.0
Compiled: Dec 22 2019 22:03:46

Ants version as read by nipype

salma@salma-Latitude-E7450:~/CODE/sammba-mri $ python -c "from nipype.interfaces import ants; print(ants.base.Info.version())"
200104-19:14:53,203 nipype.utils INFO:
	 Running nipype version 1.5.0-dev+g7f6cc2de2 (latest: 1.4.0)
0.0.0
from nipype.interfaces import ants

bias_correct = ants.N4BiasFieldCorrection().run
bias_correct(input_image='/tmp/func.nii.gz')

throws the following error

200104-19:20:52,963 nipype.utils INFO:
	 Running nipype version 1.5.0-dev+g7f6cc2de2 (latest: 1.4.0)
---------------------------------------------------------------------------
Exception                                 Traceback (most recent call last)
<ipython-input-1-9321c82e17d6> in <module>
      2 
      3 bias_correct = ants.N4BiasFieldCorrection().run
----> 4 bias_correct(input_image='/tmp/func.nii.gz')

~/CODE/nipype/nipype/interfaces/base/core.py in run(self, cwd, ignore_exception, **inputs)
    348         self.inputs.trait_set(**inputs)
    349         self._check_mandatory_inputs()
--> 350         self._check_version_requirements(self.inputs)
    351         interface = self.__class__
    352         self._duecredit_cite()

~/CODE/nipype/nipype/interfaces/base/core.py in _check_version_requirements(self, trait_object, raise_exception)
    281                         raise Exception(
    282                             "Trait %s (%s) (version %s < required %s)"
--> 283                             % (name, self.__class__.__name__, version, min_ver)
    284                         )
    285 

Exception: Trait rescale_intensities (N4BiasFieldCorrection) (version 0.0.0 < required 2.1.0)

while forcing the trait rescale_intensities to be undefined solves the issue

from nipype.interfaces.base import traits                                                                                                                                                                                                                                 

bias_correct(input_image='/tmp/func.nii.gz', rescale_intensities=traits.Undefined)

Platform details:

200104-19:19:19,39 nipype.utils INFO:
	 Running nipype version 1.5.0-dev+g7f6cc2de2 (latest: 1.4.0)
{'commit_hash': '7f6cc2de2',
 'commit_source': 'repository',
 'networkx_version': '2.4',
 'nibabel_version': '3.0.0',
 'nipype_version': '1.5.0-dev+g7f6cc2de2',
 'numpy_version': '1.17.4',
 'pkg_path': '/home/salma/CODE/nipype/nipype',
 'scipy_version': '1.3.2',
 'sys_executable': '/home/salma/miniconda3/bin/python',
 'sys_platform': 'linux',
 'sys_version': '3.7.4 (default, Aug 13 2019, 20:35:49) \n[GCC 7.3.0]',
 'traits_version': '5.2.0'}```

### Execution environment
- My python environment outside container
@satra
Copy link
Member

satra commented Jan 5, 2020

this seems like an issue with ants version rather than nipype itself. nipype appears to be doing the correct thing.

@salma1601
Copy link
Contributor Author

@satra yes ANTs version is not correct. Yet is it expected that for versions less than 2.1.0 that the N4BiasFieldCorrection fails unless rescale_intensities is explicitely set to Undefined?
My understanding of the requirement min_ver="2.1.0" for the rescale_intensities trait is that it should not be specified for versions less than 2.1.0. I do not specify it, but here by default it is set to False.

@satra
Copy link
Member

satra commented Jan 5, 2020

thanks @salma1601 - this is then a bug in the nipype core. at present the handling of use_default is conflicting with version checking.

in such a situation we should either:

  1. create a version dependent inputspec (this is roughly what we do with some interfaces for FSL and SPM).
  2. disable it
  3. keep it but not use it (this gets tricky between commandline and non-commandline interfaces).

my preference is towards 2, but this will require some modifications to how inputs are handled.

@salma1601
Copy link
Contributor Author

If I understand correctly, this is a more general problem than specific to N4BiasFieldCorrection.
What do you mean by disable it ?

@satra
Copy link
Member

satra commented Jan 7, 2020

this is a more general problem than specific to N4BiasFieldCorrection.

yes

What do you mean by disable it ?

when you create an instance of an interface, the inputs that are available will depend on a scan through min_ver/max_ver and the interface.version property. one way would be to add a metadata property unavailable=True and every place where inputs are iterated would exclude any inputs with that property.

this would allow hashing of inputs properly and not using those inputs in format_arg, parse_arg, etc.,. also when we do interface.inputs it should not list disabled inputs.

however, this would be a bigger change and we would have to ensure our tests cover the issues this may cause.

@effigies effigies added this to the 1.6.0 milestone Feb 23, 2020
@effigies
Copy link
Member

Let's try to resolve the primary issue in 1.6.0.

@effigies
Copy link
Member

@satra Ran across this while thinking about pushing for a 1.6.0 release. If you get some minutes, would you mind refreshing yourself on the issue and estimating how big a lift this would be? I can probably find time to do it if the path is reasonably clear.

satra added a commit that referenced this issue Nov 21, 2020
Potential hack for #3138
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants