Hello!
I tried to convert my MR-resting state folders in nifti but most of the time a window with "out of memory" appeared and the text "Warning: for compatibility, converting UINT16->FLOAT32, range: 38409
If you prefer filesize over compatibility, edit your preference named UINT16toFLOAT32" in the converter.

He converted some folders anyway if I closed and opened it with a blank converter but a few persons seems to be unconvertible. All data were recorded with the same scanner and sequence.

What can or should I do?

Thank you and kind regards,
Barbara Landsmann

Hello-

 1.) It might help to know the dcm2nii version and operating system you are using. This is listed when you run the program, for example on my OS X computer I am using "dcm2nii :: 4AUGUST2014 32bit BSD License"

2.) I am not sure if you are using dcm2nii (which comes with MRIcron) or the newer dcm2niix (which comes with MRIcroGL). I would recommend you try out dcm2niix - it was designed from the ground up for large datasets.

3.) The standard NIfTI 16-bit data type is 16-bit SIGNED integers - this can losslessly encode values from -32768..+32767. This is typically fine, as most classic MRI systems use 12-bit ADC (range 0..4096). However, it is clear that your software is set up to convert to 16-bit UNSIGNED (0..65535). This is really way beyond the SNR expected for EPI data, but it poses a problem for true lossless conversion. In this situation my software provides you with two options:
 a.) save as unsigned 16-bit integers (UINT16): this keeps the raw data from your scanner unchanged. However, this is a legal but atypical NIfTI data format so subsequent tools may fail.
 b.) save as 32-bit floating point (FLOAT32): this is a standard format that has ample precision. However, the files will require twice as much disk space and will probably require more time to process.
 So I think the choice depends on what tools you will use for subsequent analysis. 

 4.) In general, if data in different folders is from different image series (e.g. either a different individual or a different sequence) you could process on folder at a time. This will dramatically reduce the memory usage on your machine. In addition, I would suggest you get a 64-bit version of dcm2niix newer than June 12, 2015: this will use dramatically less memory than other tools for conversion. You can get the source code and some recent compilations from
   https://github.com/neurolabusc/dcm2niix 

5.) If all else fails you can provide me with a sample dataset to evaluate.

Hello,

I used the "Chris Rorden's dcm2nii :: Nov 11 2011" and also downloaded the newest version "Chris Rorden's dcm2nii :: 1JUNE2015 32bit BSD License" for Windows (7) 32 bit system.
Which one is the dcm2niix-version?
The new version gave me the same error report with the "out of memory"warning and with additional information about the MB-factor and slice time correction.

Ok, so it would be better for my subsequent analysis to save as FLOAT32. How and were should I save it this way? I am not really good at these kind of technical things.
I tried to convert only the folder with the resting state sequence or the folder of the person. with the persons folder, convertion sometimes succeed.

I will try to install the dcm2niix file too.
Thank you!

Hello,

I've tried the suggestions on the post, it converts something but it gives too many files where I can only see squares, I assume each file has only a portion of information. This is what the message while processing gives

intensity range requires saving as rare 16-bit UNSIGNED integer. Subsequent tools may require 32-bit conversion

How can I convert these files?

Thank you.

1.) Maybe you can tell me a bit about your system and your files. For example "I tried to convert DICOM data from our Prisma E11 resting state sequence. I used dcm2niix version 5May2016 on an OSX computer. It generated warnings about 16-bit UNSIGNED integer data, and when I viewed these files with MRIcroGL version 5May2016 on OSX I only saw squares."

2.) In general, older scanners only used 12-bit ADC, and the original Analyze format did not support 16-bit unsigned integer (UINT16) data. While the NIfTI format (a modern extension of the Analyze format) does support UINT16, this can cause problems for some tools, though this is becoming less of an issue. Therefore, a warning is warranted.

3.) I would suggest you convert your data with dcm2niix - given that your data is UINT16, it must be a modern dataset and I would use a modern converter like dcm2niix instead of dcm2nii. In general, I would only use dcm2nii for scans for legacy data from the previous century that predate the DICOM standard (Elscint, proprietary GE, proprietary Siemens). On the other hand, dcm2niix does not attempt to support ancient software and hardware but often does a nice job with modern DICOM datasets. You may also want to convert your images with the protocol name in the output name (e.g. with dcm2niix "-f %p_%s" will save the protocol name and series number). This will check your assumption of how the files relate to the series you ran. In general, most sequences (T1 MPRAGE, resting state EPI, DTI EPI) will all be saved as a single file, but localizer/scout scans will need to be broken into multiple files because the NIfTI standard requires all slices have the same spatial alignment (so axial, transverse and coronal slices can not be stacked into a single file).

4.) As I noted before, feel free to send me a personal email with a sample dataset and I can provide more feedback.

Hello Lucero,

Thanks for your sample images. There are two issues with your images:

1.) first the Siemens CSA headers have been stripped away. Once this data is removed there is no way to determine important parameters such as slice order, slice timing, bvec, bval
   http://nipy.org/nibabel/dicom/siemens_csa.html
2.) The original uncompressed image data was saved as the DICOM-specific, ancient, lossless JPEG compression (transfer syntax 1.2.840.10008.1.2.4.70).
  https://www.nitrc.org/plugins/mwiki/index.php/dcm2nii:MainPage#Transfer_Syntaxes_and_Compressed_Images
While in theory my software can handle these, it expects 3D data to be saved as single JPEG with multitple frames, while your data stores each slice as a separate image fragment. Therefore, unless my software is modified it only converts the first slice of each 3D volume. While an engineer could modify my code to support this variation of this format, I am disinclined to do so, as I do not like this format because 
 a.) none of the popular standard JPEG libraries support it
 b.) some vendors mis-interpreted the standard, so following the specification does not always lead to correct decompression
 c.) this method tends to yield very poor compression ratios, if you want to save disk space you will do much better with generic file compression schemes like zip or gz

Solutions:
 1.) You could uncompress your image data using dcmdjpeg. Future versions of my software will provide the user with a hint when it encounters files like yours: "Unable to decode all slices (1/48). Please use dcmdjpeg to uncompress data." Once this is done, you can convert your images.
 2.) You could update dcm2niix to handle your images (look at function nii_loadImgJPEGC3) 
  https://github.com/neurolabusc/dcm2niix/blob/master/console/nii_dicom.cpp 
3.) Neither solution 1 or 2 can do anything about the missing CSA data. The best solution is to go directly to your scanner and get the original images before they had vital aspects removed and were saved in an arcane format.

Dear Chris,

Thanks for developing such a nice tool!

I wonder how can I change the output nifti file to be saved as FLOAT 32 in dcm2niix?
The version I applied is "Chris Rorden's dcm2niiX version v1.0.20170130 (64-bit Linux)"

Thanks a lot!

Best regards,
KC

Originally posted by Chris Rorden:

Hello-

 dcm2niix is a file format converter that converts DICOM to NIfTI. It is not a datatype converter: it losslessly converts images preserving the original data type where ever possible. Therefore, the way to get FLOAT32 output is to provide input images that use the FLOAT32 data type. I have two suggestions: first, see if the subsequent tools you are using can be upgraded to support integer data. This will substantially reduce the amount of disk space. Further, many tools (like my MRIcron and MRIcroGL) use substantially less RAM when dealing with 16-bit data and are substantially quicker (using integer rather than floating point math and exploiting lookup tables). There are no benefits from upsampling beyond compatibility with tools that do not support the more compact format.

If you really want to want to upsample data to FLOAT32, here are options (listed from easiest to hardest):
 1.) Leverage the fact that fslmaths defaults to the FLOAT32 datatype:
   fslmaths chris_t1 -add 0.0 fchris_t1
 2.) Use a simple SPM script
   https://github.com/rordenlab/spmScripts/blob/master/nii_change_datatype.m
3.) Modify the dcm2niix code to save as FLOAT32. In particular, you would want to edit the nii_saveNII3D() function of nii_dicom_batch.cpp. If you want to share your solution you can submit a pull request.

Dear Chris,

Thanks very much for your kind reply and the explanations/suggestions are really informative and helpful.

It seems that use the integer data format is a more reasonable choice.

Thanks again!

Best,
KC