Add checks for unsupported characters within image path and output path#4390
Add checks for unsupported characters within image path and output path#4390Pfleiderer-Adrian wants to merge 1 commit intoInsightSoftwareConsortium:mainfrom
Conversation
There was a problem hiding this comment.
Thank you for contributing a pull request! 🙏
Welcome to the ITK community! 🤗👋☀️
We are glad you are here and appreciate your contribution. Please keep in mind our community participation guidelines. 📜
More support and guidance on the contribution process can be found in our contributing guide. 📖
This is an automatic message. Allow for time for the ITK community to be able to read the pull request and comment
on it.
d1bdbce to
7304267
Compare
dzenanz
left a comment
There was a problem hiding this comment.
Ah, this check in makes sense via Python interface. Mostly looks good.
|
There may be something in the SWIG layer that can be down with the conversion. There is some information here: That needs to be gone through. |
|
@Pfleiderer-Adrian thanks for having a look at this. A few comments:
|
|
The second commit should be squashed into the first one. |
| try: | ||
| filename.encode('ascii') | ||
| except UnicodeEncodeError: | ||
| msg += "\nThe output path contains not supported special characters. \n" + f"Filename = {filename}" |
There was a problem hiding this comment.
It may be useful to place this check into a function.
|
Thank you for your feedback! I'll post an update this weekend. :) |
|
Thank you for diving into this issue, @Pfleiderer-Adrian Do I understand correctly that this issue (#4388) is only a problem for Windows users, not for Linux users? (Specifically, only those Windows users that do not have UTF-8 support enabled and selected a locale that does not support the filename?) I'm asking, because it feels too strict to only accept ASCII characters from now, for all users. So is it really the intention to reject any non-ASCII character in file names, for any user? Aren't we then throwing the baby out with the bath water? Would it be an idea to only do those checks after trying to use |
- In `imwrite` function, add validation to ensure the output directory exists, raising an error if not. - Check for unsupported special characters in file paths, raising an error if present. - Apply similar checks to `itkTemplate` to validate input file paths for existence and encoding.
hjmjohnson
left a comment
There was a problem hiding this comment.
This comment should be addressed before this is finalized.
|
Nowadays, UTF-8 support appears possible on any supported Windows machine, using a manifest file (XML) and a |
dzenanz
left a comment
There was a problem hiding this comment.
This makes the Python wrapping behave differently from C++.
|
|
||
| # Check if output path exists | ||
| msg = "" | ||
| if not os.path.isdir(os.path.dirname(filename)): |
There was a problem hiding this comment.
This will most likely interfere with Slicer's MRML ID ImageIO. Scratch that - Slicer uses C++ version of ITK for "writing" temporary files.
| msg = "" | ||
| if not os.path.isfile(inputFileName): | ||
| msg += "\nThe file doesn't exist. \n" + f"Filename = {inputFileName}" | ||
| # Check if image path contains not supported special characters. |
Description
I encountered an issue while attempting to load images using the ITK / SimpleITK framework in my Python script. The traceback indicates that the problem arises when attempting to create an IO object for reading an image file that contains Umlauts (ä, ü, ö) in its path. See: #4388
Providing a more descriptive error message indicating that the path cannot be read due to special characters, such as Umlauts, would be helpful for users to understand and address the issue.
Changes
I have added a simple filepath check for illegal characters in the _NewImageReader and imwrite routines. Additionally, for the imwrite routine, a check was added to verify if the output directory exists.
PR Checklist