`import dicom` resolves differently across platforms

It appears that import dicom works inconsistently across platforms, perhaps this is due to runtime load ordering issues:

mac (resolves to pydicom):

>>> import dicom
>>> print dicom
<module 'dicom' from '/Applications/Slicer.app/Contents/lib/Python/lib/python2.7/

linux (resolves to Slicer DICOM module):

>>> import dicom
>>> print dicom
<module 'dicom' from '/media/psf/Home/Slicer-4.9.0-2018-09-10-linux-amd64/lib/

Anyone has a workaround for this problem?

I suspect this happens on case-insensitive filesystem.

If this is the case:

  • switch to case sensistive filesystem
  • rename faulty module to have different name
1 Like

Thank you JC, this indeed appears to have been the case. I was using Parallels, and installed Slicer on a mounted volume. The file names were not showing up as case-insensitive in the file browser, but apparently this was the issue. After I installed Slicer in a local FS Parallels folder, things returned back to normal.

Do we have documentation anywhere saying that a case sensitive file system is suggested? Maybe we should have a small test that runs on startup and warns if a case-insensitive file system is detected.

a small test that runs on startup and warns if a case-insensitive file system is detected.

Great idea

For the buildsystem, what about:

file(WRITE "${CMAKE_CURRENT_BINARY_DIR}/TestCaseSensitiveFileSystem.txt" "1")
file(WRITE "${CMAKE_CURRENT_BINARY_DIR}/Testcasesensitivefilesystem.txt" "0")
file(READ "${CMAKE_CURRENT_BINARY_DIR}/TestCaseSensitiveFileSystem.txt" is_case_sensitive_filesystem)
if(NOT is_case_sensitive_filesystem)
  message(FATAL_ERROR "")

and for the runtime, we could do similar test in C++ or python. Or use an existing system call …

1 Like

And to clarify, I would be happy to review a pull-request if someone want to implement such configure and/or runtime test

1 Like

For reference, here is the corresponding Slicer issue: https://issues.slicer.org/view.php?id=4606

Windows uses case-insensitive file system, topic. Why it is not a problem there (it imports pydicom)?

Both Slicer’s DICOM module and pydicom is very brave to claim such a generic word as “dicom” for its name, but especially pydicom, as a Python package, it should have chosen a more specific name. Anyway, we cannot expect pydicom to be renamed, so should we change the Slicer module name? Maybe to DICOMBrowser?

1 Like

It was just renamed for the 1.0 release - dicom now it’s pydicom.

But the whole thing does seem very fragile. Isn’t there some other way to namespace these things? Like what if someone decides to name their python package slicer? (guess we should grab that one).

That makes sense. :+1:

1 Like

Good point. There are no problem on windows. See experiment below.

That said, the path containing DICOM.py is indeed listed first in sys.path


I suspect that the function listing files in a directory on a case insensitive macOS always return lower case files whereas on windows the case is maintained in the listing.

Also worth noting that ~/.local/lib/python2.7 is listed … more on that below.

import of dicom vs DICOM / macOS, Linux, Window / Installed Slicer from Sept 11 (r27399)


Here is what happen using the latest windows nightly build:


The two paths are:

  • lib/Python/Lib/site-packages/dicom (which contains __init__.py)
  • lib/Slicer-4.9/qt-scripted-modules (which contains DICOM.py)


On linux, using the latest nightly, we have:

>>> import dicom
>>> dicom.__file__
>>> import DICOM
>>> DICOM.__file__

The two paths are also:

  • lib/Python/lib/python2.7/site-packages/dicom
  • lib/Slicer-4.9/qt-scripted-modules



The two paths are also:

  • lib/Python/lib/python2.7/site-packages/dicom
  • lib/Slicer-4.9/qt-scripted-modules

Not sure what is happening … it may be worth doing more experiment in that setup.

PYTHONNOUSERSITE seems to be ignored on macOS

While looking at the issue, I printed the sys.path and we can see that the one containing DICOM is first.



Does that mac have a case-sensitive filesystem?