DICOM volume orientation may be bad

Support
1

A DICOM volume loaded in the DICOM module shows up rightly.

When loaded via the ‘Load data’ menu, its orientation is bad. That’s my preferred method, good or bad.

Please see attached images.

Can it be fixed ?

Thanks.

good bad

2

@chir.set: Are you able to share a dataset with this behavior?

The DICOM module add several checks and organizes the data before loading, so it will always be the recommended method. But it would be good to know why this data fails to load correctly and perhaps it could be reported/fixed in the ITK IO code.

3

I’ve noticed this, too. This is a regression in ITK-v5.1rc01.

@dzenanz @thewtex

4

For anonimity, I must export the affected DICOM series in a directory. But when loading the anonymized volume via the ‘Load data’ menu, it is rightly oriented.

Not much I can do to provide sample data.

Regards.

1 Like
5

I’ve filed an ITK bug report: https://github.com/InsightSoftwareConsortium/ITK/issues/1587

This minor ITK version upgrade has caused us so much headache already - build failures in all components that uses ITK (Slicer core, BRAINS, Elastix, etc.), DICOM errors (1, 2), SimpleITK failure on all operating systems with various reasons (Windows issue is fixed now but we still don’t have solution for the MacOS error), lack of filter progress updates, etc. The ITK team is very responsive but it is still quite frustrating that we need to spend so much time with investigating these regressions.

1 Like
6

It is completely screwed up - I can reproduce with public data (this was series 7 from patient 0000 in this TCIA collection. I’ll follow up on the ITK tracker.

image

In this image the volume on the left was loaded via the DICOM module, and the volume on the right was loaded via Add Data.

1 Like
7

This ITK example seems to work right on the same data. I’ll see if I can single step to see what Slicer does differently (there’s some very old code in vtkITK that could be the source of the issue).

1 Like
8

We looked into this and it does appear to be a regression related to the new ITK version.

@lassoan and I discussed that using Add Data to load dicom is never going to be robust, so we are thinking to disable even allowing it. Hopefully his new chagne to streamline dropping files on the DICOM module directly will address sort of the same use case.

If anyone feels very strongly about this, another option could be to add another reader option to the Add Data mechanism that tries to be smarter about files that have .dcm or .IMA extensions since those are very likely to be DICOM. That loader path could use the same logic as in the ITK example linked above. This approach isn’t especially difficult, but it would take a developer some time to implement and test (volunteers?).

1 Like
9

I may end up using the DICOM module then.

It has these disadvantages :

  • Volume information is printed in the 4 corners of 2Dviews, consuming some screen estate.
  • Study name is imposed by the study, and not really intuitive to select in combo boxes. They may be changed, with a few clicks. Many times a day, it becomes tedious.
  • All studies must be scanned by the DICOM module before we can load one.
  • A database must be managed, transparently though. But that’s good for the vast majority of users. In my workflow however, I prefer data to be independent of the application.

With the Load Data module

  • A personalized string may be typed right away before loading.
  • 2D views are not overloaded with corner annotations.
  • As an inconvenience, we don’t know what study we are loading.

Regards.

10

I may add that DICOM files on 99% of CT angioscans on DVDs, from many institutions, do not have any extension, and sometimes end with just a dot.

Now if it’s not possible to maintain the Add Data module for serial study loading, I’ll just use the DICOM module.

11

Yes, that’s why the DICOM module is the right way to go in general, and it makes sense to try to make it more efficient to use.

A lot of the complexity of the Add Data approach is that it tries to use file extensions to determine what’s in the files, but these don’t fully define what’s in the data. Then under the hood it looks inside the files and tries to discover what’s in the file and load it as well as possible.

12

Thanks for the specific feedback, it is very useful and it shows that we are on right track but we should do a couple of things to improve the user experience.

You can configure how much (if any) image details you want to show in “DataProbe” module. We can improve things if you have specific suggestions.

The node name is created from series name/description. In recent Slicer versions, you can see study description and patient name in the DICOM module and you can change it by one double-click. At some point we will replace the current node selector by the subject hierarchy node selector (it is already used at a few places and you can show one by typing this in the Python console:

c = slicer.qMRMLSubjectHierarchyComboBox()
c.setMRMLScene(slicer.mrmlScene)
c.show()

This is inevitable if you want to load the data correctly. This happens automatically, in the background now (without blocking the user interface). We’ll add thumbnail display to shorten “time to first image”.

I don’t understand this point.

13

Well, I mean everytime the DICOM module is loaded, it shows a long list of previously loaded studies. Because I manage data outside Slicer, what’s saved in the SQLite DB is of little interest to me and in effect, I always cleared the list whenever (rarely) I happened to used the DICOM module. Most users won’t do that obviously. How about providing a checkbox below the ‘Import’ button,
labelled ‘Don’t save to DB’ ? I just expect data to be loaded, not imported to a database.

This solves one problem easily.

An this solves another one.