DWIConvert: no input volume not allowed for lossy conversion from NIFTI FSL to nrrd

Hello,

I am able to run DWI Convert for FSL to NRRD conversion with no input volume by selecting allow lossy conversion on DWIConvert 4.7.1. When I run DWI Convert with the same parameters in version 4.8.0, I get the following error:

Diffusion-weighted DICOM Import (DWIConvert) standard error:

W: DcmItem: Length of element (0300,d7ec) is odd
E: DcmElement: Unknown Tag & Data (0300,d7ec) larger (3855987813) than remaining bytes in file
W: DcmItem: Dataset not in ascending tag order, at element (0300,d7ec)
W: DcmItem: Length of element (8b1f,0808) is odd
E: DcmElement: Unknown Tag & Data (8b1f,0808) larger (1512397297) than remaining bytes in file
W: DcmItem: Length of element (8b1f,0808) is odd
E: DcmElement: Unknown Tag & Data (8b1f,0808) larger (1512500603) than remaining bytes in file
W: DcmItem: Length of element (0300,d7ec) is odd
E: DcmElement: Unknown Tag & Data (0300,d7ec) larger (3855987813) than remaining bytes in file
W: DcmItem: Dataset not in ascending tag order, at element (0300,d7ec)
W: DcmItem: Length of element (0300,d9ec) is odd
E: DcmElement: Unknown Tag & Data (0300,d9ec) larger (3520476281) than remaining bytes in file
W: DcmItem: Dataset not in ascending tag order, at element (0300,d9ec)
W: DcmItem: Length of element (0300,d7ec) is odd
E: DcmElement: Unknown Tag & Data (0300,d7ec) larger (1737862245) than remaining bytes in file
W: DcmItem: Dataset not in ascending tag order, at element (0300,d7ec)
W: DcmItem: Length of element (6600,c139) is odd
E: DcmElement: Unknown Tag & Data (6600,c139) larger (63459087) than remaining bytes in file
Error: no DICOMfiles found in inputDirectory: .
Unable to create converter!

Is a workaround to carry out the conversion in the newer version?

Thanks.

It looks like the module is trying to run in DICOM->NRRD mode. Can you please send a screenshot of the options you selected? (please blank out any confidential information)

Here’s the screenshot for the newer version (4.8.0):

Screenshot from 2017-12-12 10-46-12

EDIT: it is not apparent from the screenshot, but allowLossyConversion has been selected

Ok, looks like an issue which I already fixed. So please try the nightly and let me know if it still doesn’t work. See here for details:

https://issues.slicer.org/view.php?id=4463

1 Like

Hi Isaiah,

Thanks! I am currently working with a build of Slicer that needs this fix. Do you know if there is a way to get it onto the build of Slicer, without having to rebuild everything?

Your screenshot says 2017-10-11, but if you are indeed on 4.8 then I think this branch should build cleanly. So do something like:

  • cd SuperBuild/BRAINSTools
  • git fetch origin
  • git checkout slicer-2017-11-29-v4.7.1-42ac3c3
  • cd SuperBuild/Slicer-build
  • make (or ninja, MSBuild, etc.)

(note that BRAINSTools is an “external module”, so it has a source tree under SuperBuild/BRAINSTools, but actually builds under Slicer-build – it does not have a BRAINSTools-build tree like most other external projects)

Hi Isaiah,

Apologies, but I might have been unclear. I am working with a Slicer 4.7 build. When I said “4.8”, I was referring to the version that appeared in the DWIConvert XML file.

<?xml version="1.0" encoding="utf-8"?> 
<executable> 
  <category>Diffusion.Import and Export</category> 
  <title>Diffusion-weighted DICOM Import (DWIConvert)</title> 
  <description><![CDATA[Converts diffusion weighted MR images in DICOM series into NRRD format for analysis in Slicer. This program has been tested on only a limited subset of DTI DICOM formats available from Siemens, GE, and Philips scanners. Work in progress to support DICOM multi-frame data. The program parses DICOM header to extract necessary information about measurement frame, diffusion weighting directions, b-values, etc, and write out a NRRD image. For non-diffusion weighted DICOM images, it loads in an entire DICOM series and writes out a single dicom volume in a .nhdr/.raw pair.]]></description> 
  <version>4.8.0</version> 

Given this, what would you suggest I do for getting the build to work on the Slicer version 4.7 build.

Thank you.

Update to current trunk :wink:

There was about one year worth of BRAINSTools updates pulled in to Slicer close to when 4.8 was released, so those changes I linked are not likely to apply cleanly. Plus there are probably ITK updates required as well. Figuring out inter-dependencies could easily take more than the two hours it will require to update Slicer+dependencies to current trunk (on any relatively recent 2+ core computer).

Between 2017-10-11 and current trunk I don’t there are any significant API changes affecting your own code, if that is the concern.

Hmm, actually the BRAINSTools update was in September, so you might be able to get away with pulling the changes as I indicated.

Okay, I will try that first. Otherwise, I’ll rebuild Slicer as you suggested. Thanks, Isaiah!