Page MenuHomePhabricator
Create Task
Maniphest T11900

ExtApp fails to load DICOM files if filename starts with a dot
Closed, WontfixPublic
Actions

Description

Despite of the way of loading ( open, drag'n'drop ) the ExtApp won't process a DICOM dataset which filename starts with a '.' like the dataset attached to the bug. After removing the point, the data set can be loaded normally.

.MR..0001.0001.2012.05.11.14.27.56.394374.2644327.IMA583 KBDownload

Related Objects

Event Timeline

• hering added projects: MITK, Bugzilla.May 15 2012, 2:26 PM
kislinsk added a subscriber: kislinsk.Jul 17 2012, 10:48 AM

Additionally, the ExtApp won't process a DICOM dataset if there is any non-ASCII character in the path, e.g. ü or é.

nolden added a comment.Nov 19 2012, 11:59 AM

I think the nicest way to fix this would be a test first approach:

  1. Create a test that creates files starting with a dot and/or containing Umlaute (or create them by CMake, copying the test data files)
  2. Pass these files to several readers and verify result

This should fail and could be fixed.

• fetzer added a subscriber: • fetzer.Jan 23 2013, 2:11 PM

Updating target_milestone

• fetzer added a comment.Jun 27 2013, 1:32 PM

This bug has a high severity and was not fixed within the 2013-06 release. Setting target milestone to next release.

maerz added a subscriber: maerz.Jul 17 2013, 2:47 PM

This bug is not reproducible under windows 7 x64.
I'll try to get on a Linux machine.

zelzer added a subscriber: zelzer.Jul 17 2013, 3:14 PM

New remote branch pushed: bug-11900-DicomFilesStartingWithDotNotLoaded

maerz added a comment.Jul 17 2013, 5:47 PM

The Problem lies in DicomSeriesReader::GetSeries().

Here, a GDMC Directory is created and thenm a load call performed. GDMC states, that load ignores UNIX style hidden files.

We need to use another method to load files here.

• fetzer added a comment.Dec 9 2013, 3:51 PM

Current release is finished. Reseting target milestone...

nolden edited projects, added MITK (2016-11); removed MITK.Oct 10 2016, 10:35 AM

Just checked: problem still exists. Does not load with default reader, "autoselect" even crashes.

Quoted Text

nolden added a comment.Oct 10 2016, 10:35 AM

Just checked: problem still exists. Does not load with default reader, "autoselect" even crashes.

Quoted Text

nolden removed nolden as the assignee of this task.Oct 10 2016, 10:36 AM
nolden added a subscriber: nolden.
floca claimed this task.Oct 14 2016, 9:36 AM
floca moved this task from 2016-11 to Bugsquashing - In Progress on the MITK board.
floca edited projects, added MITK; removed MITK (2016-11).
floca mentioned this in T20203: Workbench/DICOMReader services crashes due to invalid/nonexistant file input.Oct 28 2016, 3:55 PM
floca removed floca as the assignee of this task.Nov 11 2016, 10:18 AM
floca lowered the priority of this task from High to Normal.
floca added a subscriber: floca.

The crash @nolden mentioned is fixed with T20203.
The original problem with "special" file names on linux is still open. The problem is identified (sie comments above). The solution is to use a directory crawler that can handle invisible or special file names on linux.

Options discussed so far:

  • gdcm (current): No. has the problem
  • itk: No. Has the same problem
  • boost directory: No. Can handle it, but is not header only and we don't want boost binary depedency as default
  • poco: No. Is problematic for MINT in the DICOMReader module
  • c++14 directory: Currently no. Because we do not want to make c++14 the requirement for MITK.

So unless we find no other option, we decided to keep the problem unfixed for linux so far. The most suitable candidate currently would be c++14 some where in the future.

zelzer added a comment.EditedNov 11 2016, 6:41 PM

Since this seems to be Linux specific, I am surprised I do not see a native POSIX approach listed here. Use the dirent structure and related functions from header <dirent.h>.

floca added a comment.Nov 14 2016, 10:01 AM

Hi Sascha, the explanation is simple.

  1. If you let baker make the menu, it will be something with bread (The people discussing the issues where no nix-cracks; Marco was aways and it seems you are missing ;).
  2. We tried hard to came up with a solution that keeps the mitk code clean (without macro switches). It seems we have filtered implicitly.

But thanks for the hint. Currently you proposal is the best solution (hidding it behind an interface). Waiting for C++14 could be a little long...

kislinsk closed this task as Wontfix.May 26 2020, 11:17 AM
kislinsk claimed this task.
kislinsk added a project: Auto-closed.

Hi there! 🙂

This task was auto-closed according to our Task Lifecycle Management.
Please follow this link for more information and don't forget that you are encouraged to reasonable re-open tasks to revive them. 🚑

Best wishes,
The MITK devs

floca reopened this task as Open.May 26 2020, 11:56 AM
floca edited projects, added Missing Info; removed Auto-closed.

As we now have c++14 we could just go and use this option the get rid of the problem (if it still exists).

kislinsk removed kislinsk as the assignee of this task.May 26 2020, 12:09 PM
kislinsk removed a subscriber: kislinsk.
kislinsk closed this task as Wontfix.Mar 10 2021, 9:02 AM
kislinsk added a project: Auto-closed.

Hi there! 🙂

This task was auto-closed according to our Task Lifecycle Management.
Please follow this link for more information and don't forget that you are encouraged to reasonable re-open tasks to revive them. 🚑

Best wishes,
The MITK devs

MITK · MIC · IMSY · DKFZ