Page MenuHomePhabricator

mitk::DataNodeFactory with DICOM files behaviour
Closed, WontfixPublic

Description

With the mitk::DataNodeFactory it is possible to read any file(s) of any datatype into an MITK datanode.

However, when using this loading mechanism with a DICOM image file, which itself is located in a directory among other DICOM files, the DataNodeFactory also reads these other DICOM files (which are not explicit given)

It is unspecified which DICOM files are read into a single or multiple DataNodes when using the mitk::DataNodeFactory.

Multiple Behaviours are possible:

  1. Read only the single specified DICOM file into a single Node. (DataNodeFactory does not touch other files)
  1. Read the specified DICOM file and all other DICOM files with the same SeriesInstanceUID into a single node
  1. Read all DICOM files in the directory, and group the files with the SeriesInstanceUID into multiple nodes

Open for Discussion!

I tend to option 1, because it is clearly defined, what to load and what not.

Event Timeline

Wouldn't it be possible to load this DICOM files directy into our DICOM Editor?
I.e. if the users tries to open DICOM files via "Open File" the DICOM Editor appears automatically and the whole DICOM directory is loaded into the external dicom data view of the DICOM editor?

One problem I see with Andreas' solution is the lack of consistency for the file opening action. For example, I like the fact that I can drag'n'drop files from my file explorer to the MITK data manager and MITK automatically creates expected nodes. I'm curious to know how you could achieve this behavior with the DICOM editor?

I like Markus' first solution. This is the behavior I expect from such an action. Although I see one exception: multiple 2D DICOM files forming a single 3D volume. I expect MITK to create a single data node with the entire volume even if I opened only a single 2D file.

kislinsk claimed this task.
kislinsk added a subscriber: kislinsk.
This task was automatically closed because it wasn't updated at least since July 2016 (over 2 years). Please re-open this task if you think that it is still relevant. This most probably means that you will resolve it.