[BUG] Silent failure when initializing extractor with an invalid path

[jvanlunenburg]

Describe the bug
Silent failure when initializing extractor with an invalid path.

Observed behavior:
When using radiomics.featureextractor.RadiomicsFeatureExtractor with an non-existing path (or one containing ~/ ) the yaml file is not read, but the extractor returns a default object.

Expected behavior:
An error thrown: file not found. Currently, users might continue to execute (and publish?!) thinking the output uses their settings.

PyRadiomics configuration
Not applicable. Any valid pyradiomics yaml.

Version (please complete the following information):

• OS: CentOS 7
• Python version: 3.7.6
• PyRadiomics version: 3.0

Additional context
Running in fresh install base anaconda environment.

[fedorov]

Good point, this can be very dangerous.

If you enable --validate, this issue will be identified, but validation of the parameter file is off by default.

@JoostJM is there a reason to not always validate? How about we switch --validate flag to yes/no, and have it set to yes by default?

[JoostJM]

I will investigate, but as far as I know the parameter file is also validate when running the cmd line normally. --validate uses the regular PyRadiomics interface, but only validates the parameter file and checks if all provide image and mask paths exist.

[fedorov]

I looked yesterday, and I was able to confirm the issue.

[JoostJM]

It's indeed a bug in the __init__ function of the feature extractor, which'll silently fail if a string is path pointing to a non existent file, and then applies the default settings. If will update this.
During validation an error is logged when the parameter file path is invalid.

When passing a valid file path, the parameter file is validated in both cases, I.e. checked if it conforms to the pyradiomics configuration schema. This is also true when a dictionary is passed as a single positional argument for initialization of the feature extractor (not an expanded dictionary/keyword arguments, which are interpreted as "settings" type configuration parameters).

[jvanlunenburg]

This is also true when a dictionary is passed as a single positional argument for initialization of the feature extractor

Regarding this, what kind of dictionary do you mean? Because documentation says:

Parameters of type 1 (image type) and 2 (feature class) can only provided at initialization when using the parameter file

Unless you mean a settings dict, so when I initalize the feature extractor with mydict instead of **mydict it is supposed to work? Because validation in the former case always seems to fail regardless of the dict settings.

Edit: Nevermind, found the relevant documentation:

At initialization, a [...] dictionary can be provided containing all necessary settings (top level containing keys “setting”, “imageType” and/or “featureClass). This is done by passing it as the first positional argument.