View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003023||Slicer4||(No Category)||public||2013-03-20 06:43||2013-04-05 08:17|
|Target Version||Slicer 4.3.0||Fixed in Version||Slicer 4.3.0|
|Summary||0003023: DWI convert doesn't work as a shared library|
Running the converter requests a file name, but since the CLI is built as a shared library the output volume is being passed as an encoded pointer -- but the data is written to a file anyway.
One possible fix is to specify EXECUTABLE_ONLY in cmake.
Another is to fix the module to write through the pointer, which should be doable since the older converter did this.
|Tags||No tags attached.|
Steve, does it write a usable file anywhere? When I run with 2013-02-24 or 2013-03-19 nightlies, DWIConverter produces a 0-byte file in the selected output directory; and there is no data written to the DWINode in Slicer either.
Yes, I was able to get a dwi nrrd file in the selected output directory but the filename was the embedded pointer name, something like slicer:0x015215... but when I changed the name to dwi.nrrd I was able to load it and estimate the tensors (the gradients were not exactly right, but that's a different issue).
This is the first time I'd tried DWI convert so I don't know how it works on other data.
Thanks, I was using DWI-DTI data and didn't get that far, just got the 0-byte file called "slicer". I'm on Windows 7 x64. For the gradients, it might be worth trying the "use B-matrix" option if it is Siemens DWI data.
Ah - makes sense - the : breaks the path on windows (I was testing on mac).
I'll pass on the B-matrix info to Maarten and maybe that will fix his issue.
Ron reports that importing DWI through the DICOM module is also not working. This would be a side-effect of the fact that DWIConvert is not working.
We know what the problem is, we just need to figure out how to integrate with Slicer. DWIConvert is being built as a shared library, and that requires that the ITK image IO be used for writing images. This is not possible because we need to write out all the specialized gradient information, so we write a compliant NRRD file out to disk manually.
We are investigating what is necessary to pass all the necessary information to ITK in order to write out all the necessary meta data for compliant and complete DWI NRRD files.
I think the problem was that DICOMToNRRD was only built as a stand alone application, and DWIConvert is being built as a shared library.
1) Remove the DWIconvert shared library, and attempt to use the slower command line interface to load a DWI data set?
BRAINSTools/DWIConvert/CMakeLists.txt was modified so that EXECUTABLE_ONLY flag is used when building the SEM packages. This disables the failing shared library that was superceeding the execution of the command line version.
The executable only flag does the trick. I've tested this and it works when invoked from the dicom diffusion importer.
|2013-03-20 06:43||pieper||New Issue|
|2013-03-20 06:43||pieper||Status||new => assigned|
|2013-03-20 06:43||pieper||Assigned To||=> hjmjohnson|
|2013-03-20 14:52||inorton||Note Added: 0008182|
|2013-03-21 03:35||pieper||Note Added: 0008183|
|2013-03-21 05:53||inorton||Note Added: 0008184|
|2013-03-21 07:16||pieper||Note Added: 0008191|
|2013-03-27 04:30||pieper||Note Added: 0008248|
|2013-03-27 04:36||hjmjohnson||Note Added: 0008249|
|2013-03-28 05:09||hjmjohnson||Note Added: 0008259|
|2013-03-28 05:09||hjmjohnson||Status||assigned => resolved|
|2013-03-28 05:09||hjmjohnson||Resolution||open => fixed|
|2013-04-05 08:17||pieper||Note Added: 0008320|
|2013-04-05 08:17||pieper||Status||resolved => closed|
|2013-04-05 08:17||pieper||Fixed in Version||=> Slicer 4.3.0|
|2016-02-29 13:56||jcfr||Category||Module Diffusion => (No Category)|