View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003999||Slicer4||Module DICOM||public||2015-06-01 13:38||2016-05-26 13:53|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||Fixed in Version|
|Summary||0003999: Not possible to import DICOM data that has non-ascii in the path|
This was reported by Steve, for Chinese characters.
patch from Steve to be tested:
diff --git a/Libs/DICOM/Core/ctkDICOMItem.cpp b/Libs/DICOM/Core/ctkDICOMItem.cpp
index d0de7ee..1d916f0 100644
@@ -115,7 +115,8 @@ void ctkDICOMItem::InitializeFromFile(const QString& filename,
|Tags||No tags attached.|
This is probably related:
Krzysztof Grandys wrote to the slicer-users mailing list:
I found resolution, when I run slicer (in Linux with Polish locales) at this command:
Using characters in the path like 'é' also makes DICOM loading fail. Examine step goes alright, but then when loading it fails. The error message:
Traceback (most recent call last):
FYI I tried various things, but none of them helped:
Thanks for working on this Csaba - amazing how hard this is to fix! What do other projects do?
It seems to me that we cannot get away without switching to 16-bit unicode. It will be extremely hard, as throughout the codebase we use 8-bit character representations (toLatin1, encode(UTF-8,'ignore'), etc). If we constrain this only to file handling then it will be less painful.
I think first of all we need to use unicode-safe VTK functions (see third attempt that resulted in "decoding unicode is not supported") for every step, starting from vtkStringArray all the way to AddArchetypeScalarVolume. I'm not sure how to do that.
Until then we need to advise users not to use non-ascii characters in their file paths.
Do you think there's a way we could detect in advance that user's might run into this? Eg. if we could have an application method to function to validate a path and warn the user if it's non-ascii we could cll that before entering I/O operations initiated from the GUI. That might cover most of the error cases.
You can do this on import, and warn user that the file will need to be copied to the DICOM DB path to be able to load it, and otherwise just not import it at all.
It's a good idea to warn the user until this issue is fixed in a proper way!
As I think currently none of the DICOM plugins support non-ascii paths (ScalarVolumes fails only on load, but for example the RT plugin fails already at the examine step, and I suspect the others will be prone too), we can check the path in a central place, and show a warning to the user.
My best guess right now is DICOMWidgets::examineForLoading, but I'm not completely sure.
I suggest at the time of import. This way you do it once. Why bother about this on a per-plugin basis and do it over and over in examine?
My suggestion was not on per-plugin basis, but when user initiates examine(+load).
I like the idea of making use of the copy feature to allow loading the files later. Maybe we should disable Add link altogether in these cases.
|2015-06-01 13:38||fedorov||New Issue|
|2015-06-01 13:38||fedorov||Status||new => assigned|
|2015-06-01 13:38||fedorov||Assigned To||=> pieper|
|2015-06-01 13:39||fedorov||Assigned To||pieper => mehrtash|
|2015-06-17 11:29||pieper||Note Added: 0013131|
|2016-05-25 12:38||pinter||Note Added: 0013896|
|2016-05-25 13:40||pinter||Note Added: 0013897|
|2016-05-26 07:45||pieper||Note Added: 0013898|
|2016-05-26 11:32||pinter||Note Added: 0013899|
|2016-05-26 13:29||pieper||Note Added: 0013900|
|2016-05-26 13:33||fedorov||Note Added: 0013901|
|2016-05-26 13:40||pinter||Note Added: 0013902|
|2016-05-26 13:42||fedorov||Note Added: 0013903|
|2016-05-26 13:51||pinter||Note Added: 0013904|
|2016-05-26 13:53||pinter||Note Edited: 0013904||View Revisions|