Slicer Nightly Build Crash loading DICOMs

[juangdiosa (Juan Diosa)]

Hi everybody

I tried to load my DICOMs in the Nightly version but slicer crashed, It is so strange because those DICOMs files I could load without problems in the stable version. I tried load those files on windows and linux versions and after the following message slicer close.
“Warnings detected during load. Examine data in advance mode for details. Load anyway?”. Acording to Advance models - Reference image in series does not contain geometry information please use caution-.

I tried with advance mode, DICOM Module, DICOM Patcher Module and deleting all DICOM data and reload again. Are there another alternative in order to load my files?. My Idea is to use Editor Segmentation module and reduce the processing time.

thanks a lot
are there another alternative in order to load my files?. My Idea is to use Editor Segmentation module and reduce the processing time.

thanks a lot

[pieper (Steve Pieper (Isomics, Inc.))]

Hi -

That’s odd, thanks for reporting the issue. A few things have changed between the 4.6 release and the current nightly but I wouldn’t have thought it would impact loading data.

A few troubleshooting ideas:

• Do you see anything in the error log? (Try the menu Help->Report a Bug). If there’s no patient identifiable information you could send me the info.

• When you are in Advanced mode of the browser is the selected reader Scalar Volume? Are there other readers offered?

• Can you load the data using the File->Add Data menu? Typically if you select one of the dicom files and uncheck the “Single File” option you might get the data to load.

• If you know anything else that might make this data “weird” compared to data that does load in the Nightly slicer please let us know. Or even better if you have sharable data that triggers the behavior that would be best.

• Of course if your main goal is just to use the Segment Editor you could just save the files from 4.6 in nrrd format and load those in the Nightly.

-Steve

[juangdiosa (Juan Diosa)]

Hi Steve. Thanks for your help.

According to error log, slicer has a critical error for two reasons: firstly "could not read scalar volumen using GDCM: Error is FileFormatError. Secondly “Reference image in series does not contain geometry information”.

When I am in advanced mode the reader scalar volume is selected by default, I cannot change to other reader or maybe I do not how to do it.

I could load my DICOMs loading by Data menu and used the Segment Editor without problems.

Here you can access to the data in order to identify the triggers. https://drive.google.com/drive/folders/0B91rlquiQ2OkT1d4ZGRJLVhhV2s?usp=sharing

regards

[lassoan (Andras Lasso)]

I could reproduce the crash. There is something wrong with one of the images (probably the file is corrupted). GDCM handles the error gracefully (reports an error and quits), but DCMTK crashes. It may be this issue: https://issues.itk.org/jira/browse/ITK-3570

To avoid the crash, switch to Advanced mode, click Examine, and uncheck all items (prevent from loading) that has warnings.

Maybe if Warnings detected during load. Examine data in Advanced mode for details. Load anyway? popup is displayed and user clicks OK then we should not load those series that have warnings? @pieper What do you think?

[pieper (Steve Pieper (Isomics, Inc.))]

@juangdiosa thanks for providing the anonymized data for testing.

Another workaround would be to go into the Edit->Application Settings to the DICOM page and pick GCDM in the Reader Approach selection menu. Before this change only GCDM was tried, but we made the defalt behavior to try DCMTK if GDCM failed to load.

@lassoan I think you are right. The stack trace below is what I got on mac. Looks like the same ITK issue you reported.

Regarding the dialog, it could make sense to have a third option where only data with no warnings is loaded, but this would complicate things and the warnings might be false positives sometimes.

I think it would be better to put effort into making sure ITK doesn’t crash or if that’s not easy then go back to using only GDCM as the default behavior.

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_platform.dylib      	0x00007fffda61dfd1 _platform_memmove$VARIANT$Ivybridge + 49
1   libITKIODCMTK-4.12.1.dylib    	0x00000001082f7ec9 itk::DCMTKImageIO::Read(void*) + 233
2   libvtkITK.dylib               	0x0000000106ad6a1a itk::ImageFileReader<itk::Image, itk::DefaultConvertPixelTraits >::GenerateData() + 474
3   libITKCommon-4.12.1.dylib     	0x000000010ad0e89f itk::ProcessObject::UpdateOutputData(itk::DataObject*) + 223
4   libvtkITK.dylib               	0x0000000106a98ae7 itk::ImageSeriesReader<itk::Image >::GenerateData() + 1399
5   libITKCommon-4.12.1.dylib     	0x000000010ad0e89f itk::ProcessObject::UpdateOutputData(itk::DataObject*) + 223
6   libvtkITK.dylib               	0x0000000106a91143 vtkITKArchetypeImageSeriesScalarReader::RequestData(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 27747
7   libvtkCommon-7.1.1.dylib      	0x000000010f4197d2 vtkExecutive::CallAlgorithm(vtkInformation*, int, vtkInformationVector**, vtkInformationVector*) + 66
8   libvtkCommon-7.1.1.dylib      	0x000000010f4144bd vtkDemandDrivenPipeline::ExecuteData(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 61
9   libvtkCommon-7.1.1.dylib      	0x000000010f40fcab vtkCompositeDataPipeline::ExecuteData(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 107
10  libvtkCommon-7.1.1.dylib      	0x000000010f413c0b vtkDemandDrivenPipeline::ProcessRequest(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 1291
11  libvtkCommon-7.1.1.dylib      	0x000000010f42eeea vtkStreamingDemandDrivenPipeline::ProcessRequest(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 762
12  libvtkCommon-7.1.1.dylib      	0x000000010f41424c vtkDemandDrivenPipeline::UpdateData(int) + 252
13  libvtkCommon-7.1.1.dylib      	0x000000010f42f37c vtkStreamingDemandDrivenPipeline::Update(int, vtkInformationVector*) + 252

[fedorov (Andrey Fedorov)]

Tangentially related to this issue, we experienced situation (not consistently reproducible) with Slicer crashing while in ITK/GDCM reader (at least that’s what it looked like from the trace)… @che85 was working on this. It belongs to a separate discussion, but I just wanted to bring it up to loop Christian in.

[pieper (Steve Pieper (Isomics, Inc.))]

I spent some more time debugging and looking through the ITK code and didn’t see an obvious fix to propose.

I’m thinking we should change the Slicer default reader back to only use GDCM but leave in place the option to enable DCMTK.

[lassoan (Andras Lasso)]

I’ve checked the ITK code, too, and it seemed that the problem is caused by a design error, which is not obvious how should be fixed. I agree that instead of urging ITK developers we should just temporarily prevent automatic fallback to DCMTK. I’ve added an issue in Slicer bugtracker to track this: https://issues.slicer.org/view.php?id=4454

[fedorov (Andrey Fedorov)]

Instead of disabling the fallback, we could also check for SamplesPerPixel in the input dataset, and not invoke the fallback if it is not 1.

[lassoan (Andras Lasso)]

We would need to then parse each file twice: once just parse the header with GDCM IO or low-level DCMTK API to find out if we may try to parse it using DCMTK IO. Doable, but may be slow and some development work. Also, the fact that DCMTK IO is so fragile indicates that it is not used/tested well enough yet, so it may not be ready for real-world use.

[lassoan (Andras Lasso)]

@thewtex What do you think? Is ITK’s DCMTK IO ready for production use? Is there a chance somebody can fix the crash in time before the new stable version of Slicer (in about 2 weeks)?

[fedorov (Andrey Fedorov)]

@lassoan

We would need to then parse each file twice

I meant to do this check in the DICOM python plugin code, before calling the DCMTK IO plugin. At that point, the dataset is already parsed, and it is just about checking another tag. I agree DCMTK IO is not used/tested well enough, but it does allow to load certain datasets that do not work with GDCM IO. And it will never become used/tested if we don’t use it…

[thewtex (Matt McCormick)]

A number of fixes have been made to ITK / DCMTK recently. Francois is going to take a look at ITK-3570. We will bump up the priority on this issue.

[fbudin69500 (Francois Budin)]

@lassoan: Can I add the image you attached to the ITK bug report to create a new test in ITK?

[lassoan (Andras Lasso)]

Yes, you can add the image to the test suite.

[fbudin69500 (Francois Budin)]

I created a patch for ITK. Let me know if that solves your problem:
http://review.source.kitware.com/#/c/22723/

[jcfr (Jean Christophe Fillion Robin (Kitware))]

Thanks to @fbudin69500 who work on the ITK fix, this is fixed in r26486 .