View Issue Details

IDProjectCategoryView StatusLast Update
0003999Slicer4Module DICOMpublic2016-05-26 13:53
Reporterfedorov Assigned Tomehrtash  
PrioritynormalSeverityminorReproducibilityhave not tried
Status assignedResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0003999: Not possible to import DICOM data that has non-ascii in the path

This was reported by Steve, for Chinese characters.

Additional Information

patch from Steve to be tested:

diff --git a/Libs/DICOM/Core/ctkDICOMItem.cpp b/Libs/DICOM/Core/ctkDICOMItem.cpp

index d0de7ee..1d916f0 100644

--- a/Libs/DICOM/Core/ctkDICOMItem.cpp

+++ b/Libs/DICOM/Core/ctkDICOMItem.cpp

@@ -115,7 +115,8 @@ void ctkDICOMItem::InitializeFromFile(const QString& filename,

DcmDataset *dataset;

DcmFileFormat fileformat;

  • OFCondition status = fileformat.loadFile(filename.toLatin1().data(), readXfer, groupLength, maxReadLength, readMode);

  • //OFCondition status = fileformat.loadFile(filename.toLatin1().data(), readXfer, groupLength, maxReadLength, readMode);

  • OFCondition status = fileformat.loadFile(filename.toLocal8Bit().data(), readXfer, groupLength, maxReadLength, readMode);

    dataset = fileformat.getAndRemoveDataset();

    if (!status.good())

TagsNo tags attached.




2015-06-17 11:29

administrator   ~0013131

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:

LANG=en_US ./Slicer
then all dicoms opening correctly.
I thing this is a little bug



2016-05-25 12:38

developer   ~0013896

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):
File "C:/d/S4R/Slicer-build/lib/Slicer-4.5/qt-scripted-modules\DICOMLib\", line 712, in loadCheckedLoadables
File "C:/d/S4R/Slicer-build/lib/Slicer-4.5/qt-scripted-modules\DICOMLib\", line 762, in proceedWithReferencedLoadablesSelection
if not plugin.load(loadable):
File "C:/d/S4R/Slicer-build/lib/Slicer-4.5/qt-scripted-modules/", line 303, in load
volumeNode = self.loadFilesWithArchetype(loadable.files,
File "C:/d/S4R/Slicer-build/lib/Slicer-4.5/qt-scripted-modules/", line 298, in loadFilesWithArchetype
TypeError: AddArchetypeScalarVolume argument 1: (unicode conversion error)



2016-05-25 13:40

developer   ~0013897

FYI I tried various things, but none of them helped:

  • slicer.util.unicodeify: 'UnicodeDecodeError: 'ascii' codec can't decode byte ...'
  • f.encode('UTF-8', 'ignore'): same as above
  • unicode(file, errors='replace'): Error when adding to VTK container (TypeError: decoding Unicode is not supported)


2016-05-26 07:45

administrator   ~0013898

Thanks for working on this Csaba - amazing how hard this is to fix! What do other projects do?



2016-05-26 11:32

developer   ~0013899

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.



2016-05-26 13:29

administrator   ~0013900

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.



2016-05-26 13:33

developer   ~0013901

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.



2016-05-26 13:40

developer   ~0013902

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.



2016-05-26 13:42

developer   ~0013903

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?



2016-05-26 13:51

developer   ~0013904

Last edited: 2016-05-26 13:53

View 2 revisions

My suggestion was not on per-plugin basis, but when user initiates examine(+load).
However import time seems to make more sense indeed.

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.
Of course then we need to make sure that the SlicerDICOMDatabase folder is also in an ascii-only path.

Issue History

Date Modified Username Field Change
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