rordenlab / dcm2niix Goto Github PK

I currently use the original dcm2nii in a real-time fMRI workflow using FSL tools. Our Siemens scanner dumps DICOMs into some_folder, so I set a watch on some_folder and call dcm2nii -v n some_folder/image.dcm for each image that appears, which gives me a NIFTI that I can use FSL on.

I'm interested in using dcm2niix because of the speed increase on Siemens DICOMs. However, single image processing does not appear to be available any more.

My current solution is:

• detect path/to/unique_image.dcm appearing
• create path/to/unique_image_folder
• copy path/to/unique_image.dcm to path/to/unique_image_folder
• call dcm2niix -o path/to -f unique_image path/to/unique_image_folder
• remove path/to/unique_image_folder
• resulting in path/to/unique_image.nii and no extra folders in path/to/

I'm wondering if the option to convert single images by calling dcm2nii --some-argument path/to/single/image.dcm still exists in dcm2niix but I'm missing how to pass the argument. If not, is there any future plan to re-implement this feature?

It will make possible to package dcm2niix in Fedora.

Both tools are currently missing a corresponding manpage.

Is there a possibility of adding (or configuring) what information is added to the BIDS sidecar?

The reason I am asking this question is because I have multiple field maps, and I want to be able to distinguish them without depending on their filenames or on the DICOMs from which they came.

Ideally I'd add the acquisition time or date, and then convert that information with another tool into the proper BIDS "IntendedFor" field.

Those fields are required when submitting NIFTI files to NIMH Data Archive.

FlipAngle - DICOM Tag 0018, 1314
ManufacturersModelName - DICOM Tag 0008, 1090

Hi Chris,

I have a DICOM file from a long-axis cardiac scan whose conversion produces different results between dcm2nii and dcm2niix. More specifically, the transformation metadata (both qform and sform) are completely different and leads to inconsistent alignments when loaded or overlayed in a viewer.

I am forwarding 2 screenshots of the images loaded on papaya with a display of the transformation metadata contained in the nifti header:

dcm2nii:

dcm2nii (grid mode):

dcm2niix:

dcm2niix (both WCS and grid mode):

This issue was reported to me by a fellow researcher from my lab who uses a different viewer. So, I am expecting that dcm2niix is doing something wrong with the transformation here, rather than a bug within papaya.

The files are here (original DICOM, plus nifit files resulting from dcm2nii and dcm2niix conversions)
conversion.zip

Let me know whether you need further information.

Ghis

Sorry for a big long report, which evolved while I was digging through the issue:

rerunning the same dcm2niix (0.20160606.1+git22-gf6471c0-1~nd90+1) call results in nifti files with differing headers: e.g.

$> nifti_tool -diff_hdr -infiles out/PHANTOM1_3.nii.gz out1/PHANTOM1_3.nii.gz 
  name                offset  nvals  values
  ------------------- ------  -----  ------
  glmax                140      1    32643
  glmax                140      1    32635
  glmin                144      1    -425050208
  glmin                144      1    -1197384832

so I have built bleeding edge 20160606-50-g236b267 and difference on this particular set of files disappeared across few reruns BUT reappeared while converting other files and this time only in glmax (so I guess glmin issue got somehow addressed) and session_error:

$> niidiff ../outputs-test-reran{9,10}/PHANTOM1_3/run003-0.nii.gz                                               
NIfTI header diff: ../outputs-test-reran9/PHANTOM1_3/run003-0.nii.gz -> ../outputs-test-reran10/PHANTOM1_3/run003-0.nii.gz
  name                offset  nvals  values
  ------------------- ------  -----  ------
  session_error         36      1    32767
  session_error         36      1    32765
....
$> niidiff ../outputs-test-reran{8,10}/PHANTOM1_3/run002-0.nii.gz 
NIfTI header diff: ../outputs-test-reran8/PHANTOM1_3/run002-0.nii.gz -> ../outputs-test-reran10/PHANTOM1_3/run002-0.nii.gz
  name                offset  nvals  values
  ------------------- ------  -----  ------
  glmax                140      1    32766
  glmax                140      1    32765

So I have cooked up a tarball with data/script/output to reproduce: http://www.onerussian.com/tmp/dcm2niix-bug.20160918.tgz

$> ./outputs-test-reran10.sh 
Chris Rorden's dcm2niiX version 28Aug2016 (64-bit Linux)
Found 5 DICOM image(s)
slices not stacked: orientation varies (localizer?) [-0.050626 0.971613 -0.231097 -0.0485989 -0.233516 -0.971138] != [-0.731964 0.669963 -0.124007 -0.056041 -0.240586 -0.969009] ('-m y' to force stacking)
Convert 2 DICOM as out/PHANTOM1_3 (162x162x2x1)
slices not stacked: orientation varies (localizer?) [-0.731964 0.669963 -0.124007 -0.056041 -0.240586 -0.969009] != [-0.0393658 0.998954 -0.0232823 -0.0580964 -0.0255492 -0.997984] ('-m y' to force stacking)
Convert 1 DICOM as out/PHANTOM1_3a (162x162x1x1)
WARNING: check that 2D images are not mirrored.
slices not stacked: orientation varies (localizer?) [-0.0393658 0.998954 -0.0232823 -0.0580964 -0.0255492 -0.997984] != [0.633816 0.741325 -0.220712 -0.056041 -0.240586 -0.969009] ('-m y' to force stacking)
Convert 1 DICOM as out/PHANTOM1_3b (162x162x1x1)
WARNING: check that 2D images are not mirrored.
slices not stacked: orientation varies (localizer?) [0.633816 0.741325 -0.220712 -0.056041 -0.240586 -0.969009] != [-0.050626 0.971613 -0.231097 -0.0485989 -0.233516 -0.971138] ('-m y' to force stacking)
Convert 1 DICOM as out/PHANTOM1_3c (162x162x1x1)
WARNING: check that 2D images are not mirrored.
Conversion required 0.026548 seconds.

$> mv out out1

$> ./outputs-test-reran10.sh; md5sum out{,1}/PHANTOM1_3.nii.gz
Chris Rorden's dcm2niiX version 28Aug2016 (64-bit Linux)
Found 5 DICOM image(s)
slices not stacked: orientation varies (localizer?) [-0.050626 0.971613 -0.231097 -0.0485989 -0.233516 -0.971138] != [-0.731964 0.669963 -0.124007 -0.056041 -0.240586 -0.969009] ('-m y' to force stacking)
Convert 2 DICOM as out/PHANTOM1_3 (162x162x2x1)
slices not stacked: orientation varies (localizer?) [-0.731964 0.669963 -0.124007 -0.056041 -0.240586 -0.969009] != [-0.0393658 0.998954 -0.0232823 -0.0580964 -0.0255492 -0.997984] ('-m y' to force stacking)
Convert 1 DICOM as out/PHANTOM1_3a (162x162x1x1)
WARNING: check that 2D images are not mirrored.
slices not stacked: orientation varies (localizer?) [-0.0393658 0.998954 -0.0232823 -0.0580964 -0.0255492 -0.997984] != [0.633816 0.741325 -0.220712 -0.056041 -0.240586 -0.969009] ('-m y' to force stacking)
Convert 1 DICOM as out/PHANTOM1_3b (162x162x1x1)
WARNING: check that 2D images are not mirrored.
slices not stacked: orientation varies (localizer?) [0.633816 0.741325 -0.220712 -0.056041 -0.240586 -0.969009] != [-0.050626 0.971613 -0.231097 -0.0485989 -0.233516 -0.971138] ('-m y' to force stacking)
Convert 1 DICOM as out/PHANTOM1_3c (162x162x1x1)
WARNING: check that 2D images are not mirrored.
Conversion required 0.023688 seconds.
1e3816b92567159bbc5cd900bc5ce068  out/PHANTOM1_3.nii.gz
697b0b296b84803d51c35035591bb5bc  out1/PHANTOM1_3.nii.gz

$> niidiff out{,1}/PHANTOM1_3.nii.gz                          
NIfTI header diff: out/PHANTOM1_3.nii.gz -> out1/PHANTOM1_3.nii.gz
  name                offset  nvals  values
  ------------------- ------  -----  ------
  glmax                140      1    32765
  glmax                140      1    32767

even if input is problematic, output imho should be deterministic ;)
If I run that call through valgrind, it screams at me with lots of uses or jumps based on uninitialized values... worrisome: http://www.onerussian.com/tmp/dcm2niix-20160918-valgrind.txt

related: I wondered -- is there any kind of automated testing established for dcm2niix?

Chris,

I am working to convert data into the BIDS format, but using the dcm2niix tool is resulting in the following warnings:

/scratch/johnsonhj/local/bin/dcm2niix -f sub-aaa_ses-001_dwi -b -z -o $(pwd)/output ${DICOM_DIR}

Chris Rorden's dcm2niiX version 15Aug2016 (64-bit)
WARNING: CSA 'ProtocolSliceNumber' SUGGESTS REVERSED SLICE ORDER: SPATIAL AND DTI COORDINATES UNTESTED

The generated json file is:
{
"Manufacturer": "Siemens",
"ManufacturersModelName": "TrioTim",
"MagneticFieldStrength": 3,
"FlipAngle": 90,
"EchoTime": 0.088,
"RepetitionTime": 9.1,
"EffectiveEchoSpacing": 0.000400005,
"SliceTiming": [
4.4375,
9.0075,
4.3075,
8.875,
4.1775,
8.745,
4.0475,
8.615,
3.9175,
8.485,
3.785,
8.355,
3.655,
8.2225,
3.525,
8.0925,
3.395,
7.9625,
3.265,
7.8325,
3.1325,
7.7,
3.0025,
7.57,
2.8725,
7.44,
2.7425,
7.31,
2.6125,
7.18,
2.48,
7.0475,
2.35,
6.9175,
2.22,
6.7875,
2.09,
6.6575,
1.9575,
6.5275,
1.8275,
6.395,
1.6975,
6.265,
1.5675,
6.135,
1.4375,
6.005,
1.305,
5.875,
1.175,
5.7425,
1.045,
5.6125,
0.915,
5.4825,
0.785,
5.3525,
0.6525,
5.2225,
0.5225,
5.09,
0.3925,
4.96,
0.2625,
4.83,
0.1325,
4.7,
0,
4.57 ],
"PhaseEncodingDirection": "j-"
}

Is this something that I should be worried about?

Additionally, when I load this into the Slicer application, the images always are incorrectly oriented.

Any advice would be greatly appreciated.

Thanks,
Hans

We are test-driving dcm2niix on sample files from soon-to-come Siemens Prisma 3T. On some of them we get an 'error':

$> apt-cache policy dcm2niix
dcm2niix:
  Installed: 0.20160606.1+git1-gf6ba376-1~nd80+1
  Candidate: 0.20160606.1+git1-gf6ba376-1~nd80+1
  Version table:
 *** 0.20160606.1+git1-gf6ba376-1~nd80+1 0
        500 http://neuro.debian.net/debian/ jessie/main amd64 Packages
        100 /var/lib/dpkg/status

$> dcm2niix -b y -o NIfTIs2/ DICOMS/ABCD_DMRI_TENSOR_0017
Chris Rorden's dcm2niiX version 6June2016 (64-bit)
Found 1 DICOM image(s)
Serious error: spatial orientation ambiguous (tag 0020,0037 not found): DICOMS/ABCD_DMRI_TENSOR_0017/DARTMOUTH_PRISMA.MR.HEAD_ADVANCED_APPLICATIONS_LIBRARIES.0017.0001.2016.02.19.15.50.35.978090.98524631.IMA
No valid DICOM files were found
Conversion required 0.042988 seconds.

Here is 0020 fields and some nearby from dcmdump:

(0018,1020) LO [syngo MR E11]                           #  12, 1 SoftwareVersions
(0018,1030) LO [ABCD_dMRI]                              #  10, 1 ProtocolName
(0018,5100) CS [HFS]                                    #   4, 1 PatientPosition
(0020,000d) UI [1.3.12.2.1107.5.2.43.67026.30000016020614024824900000137] #  56, 1 StudyInstanceUID
(0020,000e) UI [1.3.12.2.1107.5.2.43.67026.2016021915224967228716830.0.0.0] #  58, 1 SeriesInstanceUID
(0020,0010) SH [1]                                      #   2, 1 StudyID
(0020,0011) IS [17]                                     #   2, 1 SeriesNumber
(0020,0012) IS [1]                                      #   2, 1 AcquisitionNumber
(0020,0013) IS [1]                                      #   2, 1 InstanceNumber
(0020,0052) UI [1.3.12.2.1107.5.2.43.67026.1.20160219145142005.0.0.0] #  52, 1 FrameOfReferenceUID
(0020,4000) LT [DTI Tensor]                             #  10, 1 ImageComments
(0029,0010) LO [SIEMENS CSA NON-IMAGE]                  #  22, 1 PrivateCreator
(0029,0011) LO [SIEMENS CSA HEADER]                     #  18, 1 PrivateCreator
(0029,0012) LO [SIEMENS MEDCOM HEADER2]                 #  22, 1 PrivateCreator
(0029,1008) CS [DTI NUM 4]                              #  10, 1 CSADataType
(0029,1009) LO [syngo MR E11]                           #  12, 1 CSADataVersion
(0029,1108) CS [DTI NUM 4]                              #  10, 1 CSAImageHeaderType
(0029,1109) LO [20160219]                               #   8, 1 CSAImageHeaderVersion

just for the record: another similar sequence which lead to similar error was DICOMS/ABCD_DMRI_COLFA_0016

dcm2nii had option to output text with t please add it to dcm2niix

Dear neurolabusc,

I lack the necessary permissions to sudo apt-get install libyaml-cpp-dev libyaml-cpp0.5 on the server I'm using. Therefore I'd like to build yaml-cpp somewhere on my home directory (from sources here) and then manually tell CMake where to find the libraries.

After googling around I tried adding these three lines to CMakeLists.txt, but that didn't work.

set(CMAKE_MODULE_PATH "/home/mrphys/dangom/clones/yaml-cpp/build;${CMAKE_MODULE_PATH}") set(CMAKE_LIBRARY_PATH "/home/mrphys/dangom/clones/yaml-cpp/build;${CMAKE_LIBRARY_PATH}") set(CMAKE_INCLUDE_PATH "/home/mrphys/dangom/clones/yaml-cpp/build;${CMAKE_INCLUDE_PATH}")

Cmake complains that it can't find the yaml-cpp package.

Creating batch version
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.27.1")
-- checking for module 'yaml-cpp'
-- package 'yaml-cpp' not found

Would you have any suggestions on how I can solve this issue?

Thanks!

The gantry tilt correction works very well, but the tilt correction can push areas of the image/brain "outside" the image or field of view. For example, see below.

Can't release data right now, but it may be possible to pad the image or recenter it? I think you'd want to do something that's not based on intensity values as if you had 2 DICOMS from same scan, would want the same padding.

I converted .par files with different PhaseEncodingDirection and saw that both BIDS sidecar files show "PhaseEncodingDirection": "i"
To my knowledge, .par files don't list PhaseEncodingDirection. Could you please remove the PhaseEncodingDirection entry from the .json file for conversion from .par files. Thanks

We have a DICOM dataset that is 16-bit with 256x256 resolution and 176 slices in coronal orientation and comes out of conversion as a NIFTI dataset that is 16-bit with 176x256 resolution and 256 slices in axial orientation. Is there a way to stop the reorientation from occurring?

In dcm2nii there seems to have been a MinReorientMatrix defined in the .dcm2nii.ini file where matrices over the size given (the default was 255) were reoriented and ones below that threshold were not, and the threshold could be changed as necessary, but I do not see a similar parameter anywhere in dcm2niix.

Hi,
I'm working on adding dcm2niix to nipype's interfaces, and was hoping there is way to implement a feature similar to dcm2nii's -b flag that allowed loading settings from specified config files.

Could you tag and push the following commit as v1.0.20161125 please?

Is there a way to get slice timing into the bids sidecar files when converting par/rec files? Thanks

I'm curious to how dicoms are split up during conversion.
Here is an output of a conversion I ran.

Is there a difference between outputs such as:
Convert 70 DICOM as ./S032_DIFFUSION_HighRes_AP (128x128x64x70)
Convert 64 DICOM as ./S032_DIFFUSION_HighRes_APa (128x128x64x1)
where an a is just added to the filename, compared to:
Convert 64 DICOM as ./S032_field_mapping_diffusion (128x128x64x1)
Convert 64 DICOM as ./S032_field_mapping_diffusion_c0_2 (128x128x64x1)
Convert 64 DICOM as ./S032_field_mapping_diffusion_c0_2a (128x128x64x1)
where _c0_2 is added, and then a is added as well?

Steps to replicate:

1. Install emscripten
2. Compile dcm2niix to JavaScript: emcc -DmyDisableOpenJPEG -I. main_console.cpp nii_dicom.cpp nifti1_io_core.cpp nii_ortho.cpp nii_dicom_batch.cpp jpg_0XC3.cpp ujpeg.cpp -o dcm2niix.js
3. Run dcm2niix: node dcm2niix.js ~/Downloads/2475376/anat/

Expected results:

Compression will be faster with /usr/local/bin/pigz
Chris Rorden's dcm2niiX version 20May2016 (64-bit)
Version 20May2016 (64-bit)
Found 192 DICOM image(s)
Convert 192 DICOM as /Users/filo/Downloads/2475376/anat/_MPRAGE_20200505000011_9 (256x256x192x1)
Conversion required 0.194481 seconds.

Instead got:

Compression will be faster with /usr/local/bin/pigz
Chris Rorden's dcm2niiX version 20May2016 (32-bit)
Version 20May2016 (32-bit)
Warning: output folder invalid /Users/filo/Downloads/2475376/anat/ will try /Users/filo/Downloads/2475376/anat/
Error: unable to find any DICOM images in /Users/filo/Downloads/2475376/anat/
Conversion required 0.006000 seconds.

It seems that the folder with dicom files needs to be explicitly mounted for this to work in emscripten (see https://kripken.github.io/emscripten-site/docs/api_reference/Filesystem-API.html#filesystem-api-nodefs and the included example).

Being able to provide JS version of dcm2niix would open a whole new world of possibilities!

Here's the dcm2niix.js
dcm2niix.zip

Hello,

we're trying to run the precompiled dcm2niix version on our centos7 installation, but it fails and returns the following error:

sh: ./pigz_mricron: cannot execute binary file

any pointers?
Thanks,
Maarten

to amuse users I guess, regular 'git tag' command without -m creates just a pointer, not a fully fledged "git tag". It is recommended to use annotated (created by using -m) tags for releases so e.g. describe works nicely

$> git describe upstream/master
20160606-68-gf7b898b

$> git describe --tags upstream/master 
20160921-15-gf7b898b

cont to #51

$> dcm2niix -f '%s-%d' -o niis ../../bids_* 
Chris Rorden's dcm2niiX version 29Sept2016 (64-bit Linux)
Error: output folder invalid: niis
Error: output folder invalid: niis
Error: output folder invalid: niis
Error: output folder invalid: niis
Error: output folder invalid: niis
Error: output folder invalid: niis
Error: output folder invalid: niis
Error: output folder invalid: niis
Error: output folder invalid: niis
Error: output folder invalid: niis
Error: output folder invalid: niis
Conversion required 0.000052 seconds.

$> echo $?
0

IMHO now I would need to capture/parse output to figure out if conversion succeeded or not. In spirit of "least surprise" and other tools behavior, imho it would be better if dcm2niix exited with non-0 exit in case of any such grave error. You can even allocate a few different exit codes for different abnormal operations, e.g.

3 -- output folder is invalid
4 -- ...

;)
Also not sure why to drag further if that output folder was invalid, it will stay invalid for other sequences -- why not to exit right away?

Hi guys,
thanks for providing the tool.
I converted par/rec files to nifti and encountered the following problem:
our files have a lower case ext: data.rec / data.par
If I pass data.par to dcm2niix (1Nov2016) it creates an empty nii file. It seems to be looking for data.PAR. Linking or renaming the .par file to a .PAR file and passing the .PAR correctly converts the file.

This only occurs on linux systems, not on Mac.

What options are available to preserve the DICOM orientation when converting to NIFTI?

Hi,

I've created a fork of dcm2niix to allow batch processing of dicoms using a yaml config file.

https://github.com/benjaminirving/dcm2niix-batch

I'm assuming you don't want this in the core code otherwise I would be happy to create a pull request. The code is a quick modification but gets the job done.

Best wishes,
Ben

In one of the experiments with consistently the same sequence at the scanner, in some scanning sessions dcm2niix produces 2 magnitude files and some times a single one. Looking in detail -- here is two acquisitions from the same date, different subjects (thus FOV adjusted between the two):

(venv)mvdoc@smaug /tmp $ for A in 1 2; do echo $A;  dcm2niix -b y -z i -x n -t n -m n -f fmap -o /tmp/A00012$A/ -s n -v n /mnt/btrfs/dbic/inbox/DICOM/2016/12/04/A00012$A/006*fmap*/000001.dcm; done    
1
Chris Rorden's dcm2niiX version 1Jan2017 (64-bit Linux)
Found 64 DICOM image(s)
slices not stacked: echo varies (TE 7.38, 4.92; echo 2, 1)
Dims 90 90 61 1 1
Warning: Interslice distance varies in this volume (incompatible with NIfTI format).
 Distance from first slice:
dx=[0 2.4 4.8 7.2 9.59999 12 14.4 16.8 19.2 21.6 24 26.4 28.8 31.2 33.6 36 38.4 40.8 43.2 45.6 48 50.4 52.8 55.2 57.6 60 62.4 64.8 67.2 72 74.4 76.8 79.2 81.6 84 86.4 88.8 91.2 93.6 96 98.4 100.8 105.6 110.4 112.8 115.2 117.6 120 122.4 124.8 127.2 129.6 132 134.4 136.8 139.2 141.6 144 146.4 148.8 151.2]
Convert 61 DICOM as /tmp/_e2fmap (90x90x61x1)
slices not stacked: echo varies (TE 4.92, 7.38; echo 1, 2)
Dims 90 90 3 1 1
Warning: Interslice distance varies in this volume (incompatible with NIfTI format).
 Distance from first slice:
dx=[0 33.6 38.4]
Warning: Weird CSA 'ProtocolSliceNumber' (29): SPATIAL, SLICE-ORDER AND DTI TRANSFORMS UNTESTED
Convert 3 DICOM as /tmp/fmap (90x90x3x1)
Conversion required 0.172428 seconds.
2
Chris Rorden's dcm2niiX version 1Jan2017 (64-bit Linux)
Found 64 DICOM image(s)
Convert 64 DICOM as /tmp/fmapa (90x90x64x1)
Conversion required 0.105576 seconds.

So -- you can see dcm2niix deciding on first file having inconsistent interslice distance. Any clues why? (rounding error during comparison or may be some fancy scanner-side motion correction offsetting the target location for the slice)

For some subjects it split into 63+1, for others 62+2, and here it was 61+3 .

Originally found with dcm2niix 20160921+git16-g0339407 and now verified with current master 20160921+git59-gbd1b713

Thank you in advance for looking into it

edit1: output from running with -v y: http://www.onerussian.com/tmp/dcm2niix-v.log

Hi,
When trying to run dcm2niix's conversion on dicom data, I am running into the following error:

Compression will be faster with /usr/local/bin/pigz Chris Rorden's dcm2niiX version 29Feb2016 (64-bit) Version 29Feb2016 (64-bit) Error: unable to find any DICOM images in /mindhive/xnat/dicom_storage/autoxy/mathias/ASD_01/dicom Conversion required 2.130000 seconds.

The command I'm using is
dcm2niix -o path/to/output path/to/dicoms

The data is compatible with dcm2nii. I've put a small subset of dicoms from a resting state in a dropbox folder, if that could help.

Thanks!
Mathias

Hi Chris,

More of a question than an issue here.

I have used your tool to convert a stack of DICOM files for a short-axis cardiac scan, consisting of consecutive 2D+t slices with fixed slice gap, to the nifti format. So far, the tool outputs one nifti file per slice (2D+t), and the slice gap information appears to be lost. I am wondering where and how this information could and should be stored.

From a quick look at the nifti format specifications, it cannot find a field dedicated to this information unless I misread it. Or perhaps it can be calculated from other fields in the nifti header somehow. Do you have any clue regarding how people usually handles fixed slice gaps with nifti?

In my case, people would prefer to have these data to be stored as one fat 3D+t nifti file for convenience (easier to deserialize), but perhaps it is more sensible to keep them as separate 2D+t. In either cases, I reckon the slice gap information needs to stored somewhere to allow users to stitch the data the way they desire prior to performing volumetric and/or temporal analysis.

Thanks for your help,

$> dcm2niix -b y -o NIfTIs2/ DICOMS/ABCD_DMRI_0012 
Chris Rorden's dcm2niiX version 6June2016 (64-bit)
Found 108 DICOM image(s)
WARNING: DTI gradient directions only tested for axial (transverse) acquisitions. Please validate bvec files.
Convert 108 DICOM as NIfTIs2/ABCD_DMRI_0012_ABCD_dMRI_20160219145142_12 (140x140x81x108)
Conversion required 1.369538 seconds.

are there any DICOM fields we should look after to share after we 'validate' bvec files to be correct or not?
P.S. We guess that easiest way to validate is to compare with the information on the console/protocol files, is that correct or there is a better "validation" strategy?

I suppose this has to do with MacOS Sierra, because I had no problems building dcm2niibatch before updating the OS. No matter what version of Cmake I use, I get the following linker error:

ld: library not found for -lyaml-cpp

To get things working I have to manually add -L/usr/local/lib to the console/CMakeFiles/dcm2niibatch.dir/link.txt file.

I was wondering if this can be reproduced, or if anyone has had the same issues?

I'm linking against the latest yaml-cpp as installed per homebrew.

Using Visual Studio 2008 and 2013 in native WIN64 mode, program stop within function

int saveDcm2Nii(int nConvert, struct TDCMsort dcmSort[],struct TDICOMdata dcmList[], struct TSearchList *nameList, struct TDCMopts opts)

and the debugger reports similar message like:

Unhandled exception at 0x000000013F5DAD97 in dcm2niix.exe: 0xC00000FD: Stack overflow (parameters: 0x0000000000000001, 0x0000000000103000).

full stack is

dcm2niix.exe!__chkstk() Line 109    Unknown
dcm2niix.exe!saveDcm2Nii(int nConvert, TDCMsort * dcmSort, TDICOMdata * dcmList, TSearchList * nameList, TDCMopts opts) Line 1181   C++
dcm2niix.exe!nii_loadDir(TDCMopts * opts) Line 1824 C++
dcm2niix.exe!main(int argc, const char * * argv) Line 151   C++
[External Code] 

Note: no such report is raised when compiling the code for WIN32.

anything -- creating that target directory or just crashing would be better IMHO:

(venv)mvdoc@smaug /tmp $ for A in 1 2; do echo $A;  dcm2niix -b y -z i -x n -t n -m n -f fmap -o /tmp/A00012$A/ -s n -v n /mnt/btrfs/dbic/inbox/DICOM/2016/12/04/A00012$A/006*fmap*/000001.dcm; done    
1
Chris Rorden's dcm2niiX version 1Jan2017 (64-bit Linux)
Found 64 DICOM image(s)
slices not stacked: echo varies (TE 7.38, 4.92; echo 2, 1)
Dims 90 90 61 1 1
Warning: Interslice distance varies in this volume (incompatible with NIfTI format).
 Distance from first slice:
dx=[0 2.4 4.8 7.2 9.59999 12 14.4 16.8 19.2 21.6 24 26.4 28.8 31.2 33.6 36 38.4 40.8 43.2 45.6 48 50.4 52.8 55.2 57.6 60 62.4 64.8 67.2 72 74.4 76.8 79.2 81.6 84 86.4 88.8 91.2 93.6 96 98.4 100.8 105.6 110.4 112.8 115.2 117.6 120 122.4 124.8 127.2 129.6 132 134.4 136.8 139.2 141.6 144 146.4 148.8 151.2]
Convert 61 DICOM as /tmp/_e2fmap (90x90x61x1)
slices not stacked: echo varies (TE 4.92, 7.38; echo 1, 2)
Dims 90 90 3 1 1
Warning: Interslice distance varies in this volume (incompatible with NIfTI format).
 Distance from first slice:
dx=[0 33.6 38.4]
Warning: Weird CSA 'ProtocolSliceNumber' (29): SPATIAL, SLICE-ORDER AND DTI TRANSFORMS UNTESTED
Convert 3 DICOM as /tmp/fmap (90x90x3x1)
Conversion required 0.172428 seconds.
2
Chris Rorden's dcm2niiX version 1Jan2017 (64-bit Linux)
Found 64 DICOM image(s)
Convert 64 DICOM as /tmp/fmapa (90x90x64x1)
Conversion required 0.105576 seconds.
(venv)mvdoc@smaug /tmp $ ls -l A00012{1,2}
ls: cannot access A000121: No such file or directory
ls: cannot access A000122: No such file or directory
(venv)mvdoc@smaug /tmp $ ls -l A00012{1,2}/
ls: cannot access A000121/: No such file or directory
ls: cannot access A000122/: No such file or directory
(venv)mvdoc@smaug /tmp $ ls -lta | head
total 122456
drwxrwxrwt 41 root        root           12288 Jan 11 10:52 .
-rw-r--r--  1 mvdoc       mvdoc         628504 Jan 11 10:52 fmapa.nii.gz
-rw-r--r--  1 mvdoc       mvdoc            378 Jan 11 10:52 fmapa.json
-rw-r--r--  1 mvdoc       mvdoc          56220 Jan 11 10:52 fmap_Eq_1.nii.gz
-rw-r--r--  1 mvdoc       mvdoc          29408 Jan 11 10:52 fmap.nii.gz
-rw-r--r--  1 mvdoc       mvdoc         593533 Jan 11 10:52 _e2fmap_Eq_1.nii.gz
-rw-r--r--  1 mvdoc       mvdoc            378 Jan 11 10:52 fmap.json
-rw-r--r--  1 mvdoc       mvdoc         570981 Jan 11 10:52 _e2fmap.nii.gz
-rw-r--r--  1 mvdoc       mvdoc            378 Jan 11 10:52 _e2fmap.json

as you can see -- files were dumped into current (/tmp) directory

Brain Imaging Data Structure (BIDS) is a new specification describing how a neuroimaging dataset should be organized and described. Part of the standard are JSON sidecar files with acquisition parameters essential for performing data analysis that are not present (or reliably reported) in the NIFTI header (see here for details). Such fields include but are not limited to:

• EffectiveEchoSpacing
• RepetitionTime
• PhaseEncodingDirection
• SliceTiming
• SliceEncodingDirection
• EchoTime

Some of those fields are part of DICOM Ontology and are directly accessible from standard DICOM headers (such as RepetitionTime and EchoTime) and some are not part of standard DICOM nomenclature and require extraction using vendor and sequence specific heuristics (for example PhaseEncodingDirection or EffectiveEchoSpacing). We aded them to the BIDS standard because they are necessary for data processing.

This is how an example BIDS compatible JSON file looks like (more examples here):

{
    "EchoTime": 0.017,
    "EffectiveEchoSpacing": 0.0003333262223739227,
    "PhaseEncodingDirection": "y-",
    "RepetitionTime": 3.0,
    "SliceEncodingDirection": "z",
    "SliceTiming": [
        1.508,
        0.0,
        1.55,
        0.043,
        1.592,
        0.087,
        1.635,
        0.13,
        1.677,
        0.173,
        1.722,
        0.215,
        1.765,
        0.26,
        1.808,
        0.302,
        1.85,
        0.345,
        1.893,
        0.388,
        1.938,
        0.43,
        1.98,
        0.475,
        2.022,
        0.518,
        2.065,
        0.56,
        2.11,
        0.603,
        2.152,
        0.645,
        2.195,
        0.69,
        2.238,
        0.733,
        2.28,
        0.775,
        2.325,
        0.818,
        2.367,
        0.86,
        2.41,
        0.905,
        2.453,
        0.948,
        2.495,
        0.99,
        2.54,
        1.032,
        2.583,
        1.075,
        2.625,
        1.12,
        2.668,
        1.163,
        2.71,
        1.205,
        2.755,
        1.248,
        2.798,
        1.293,
        2.84,
        1.335,
        2.883,
        1.378,
        2.925,
        1.42,
        2.97,
        1.462
    ]
}

dcm2nii has for year been the benchmark of efficient and precise DICOM to NIFTI converters. It would be great if the future release supported saving BIDS style JSON files along the converted NIFTI files. In addition you can consider embedding this JSON inside the header (similar to what dcmstack does). From looking at your code base I see that you already calculate many of the required parameters. I'm more than happy to provide any help in implementing this feature.

Thank you very much in advance

not sure what is happening besides being Friday -- I think I have ran conversion on those before and didn't observe such behavior...

$> /tmp/dcm2niix -b y -z i -x n -t n -m n -f fmap -o  /tmp/out -s n -v n /mnt/btrfs/dbic/inbox/DICOM/2016/12/04/A000121/006*fmap*
Chris Rorden's dcm2niiX version 1Jan2017 (64-bit Linux)
customOutDir set to /tmp/out
inDir /mnt/btrfs/dbic/inbox/DICOM/2016/12/04/A000121/006-fmap_acq-2.4mm
outDir /tmp/out
outDir(again) set to /tmp/out
Warning: Checking existence of output folder '/tmp/out'
Found 64 DICOM image(s)
slices not stacked: echo varies (TE 7.38, 4.92; echo 2, 1)
Dims 90 90 61 1 1
Warning: Interslice distance varies in this volume (incompatible with NIfTI format).
 Distance from first slice:
dx=[0 2.4 4.8 7.2 9.59999 12 14.4 16.8 19.2 21.6 24 26.4 28.8 31.2 33.6 36 38.4 40.8 43.2 45.6 48 50.4 52.8 55.2 57.6 60 62.4 64.8 67.2 72 74.4 76.8 79.2 81.6 84 86.4 88.8 91.2 93.6 96 98.4 100.8 105.6 110.4 112.8 115.2 117.6 120 122.4 124.8 127.2 129.6 132 134.4 136.8 139.2 141.6 144 146.4 148.8 151.2]
Convert 61 DICOM as /tmp/out/_e2fmap (90x90x61x1)
slices not stacked: echo varies (TE 4.92, 7.38; echo 1, 2)
Dims 90 90 3 1 1
Warning: Interslice distance varies in this volume (incompatible with NIfTI format).
 Distance from first slice:
dx=[0 33.6 38.4]
Warning: Weird CSA 'ProtocolSliceNumber' (29): SPATIAL, SLICE-ORDER AND DTI TRANSFORMS UNTESTED
Convert 3 DICOM as /tmp/out/fmap (90x90x3x1)
Conversion required 0.172284 seconds.

$> cat /tmp/out/*json
{
	"Manufacturer": "Siemens",
	"ManufacturersModelName": "Prisma",
	"ProcedureStepDescription": "XXX",
	"ProtocolName": "fmap_acq-2.4mm",
	"ImageType": ["ORIGINAL", "PRIMARY", "M", "ND", "NORM"],
	"AcquisitionDateTime": "2016-12-04T13:49:17.015625",
	"MagneticFieldStrength": 3,
	"FlipAngle": 60,
	"EchoTime": 0.00738,
	"RepetitionTime": 0.675,
-"
}
{
	"Manufacturer": "Siemens",
	"ManufacturersModelName": "Prisma",
	"ProcedureStepDescription": "XXX",
	"ProtocolName": "fmap_acq-2.4mm",
	"ImageType": ["ORIGINAL", "PRIMARY", "M", "ND", "NORM"],
	"AcquisitionDateTime": "2016-12-04T13:49:16.156250",
	"MagneticFieldStrength": 3,
	"FlipAngle": 60,
	"EchoTime": 0.00492,
	"RepetitionTime": 0.675,
-"
}

happens similar to non problematic ones :-/

Somewhere between the 1-Nov-2016 release and the current master the following issue with BIDS .json export sneaked in: The last entry is followed by a ",":

{
	[...]
	"RepetitionTime": 0.00818,
}

At least python's .json import does not like that, but can deal with the format exported by the 1-Nov-2016 release:

{
	[...]
	"RepetitionTime": 0.00818
}

Could you please take a look at that? Thanks.

When I convert a DTI dataset, I end up with two NIfTI files, one with "_ADC" and one without. The one without removes the added mean diffusion image at the end of the original dataset, but the one with "_ADC" contains all original directions and the final mean image. Is this the intended result? My original though was that this extra file should just have the removed volume.

Pardon me if this question is answered elsewhere, but is the "isCreateBIDS" option in the configuration YAML sensitive to whether or not there are JSONS in the top-level directory of a BIDS dataset directory that should be inherited by NifTIs? I.e., is it able to open up JSONS at the top-level directory, compare the parameters in those JSONS to the JSON files that would potentially be written out at the participant level, and then not write out JSONS at the participant level if the top-level and participant-level JSONs are the same?

Hi
I am noticing that the output directory switch -o is not working, and output is always written to the input directory.
I think it has to do with the

strcpy(opts.outdir,opts.indir);

line at the end of main_console.cpp

If I have my DICOM files in a folder named 'mr_0013-e02', and run the following command from inside that folder, dcm2niix -z y -b y -f test ., the output filenames come out as _e2_phtest.json and _e2_phtest.nii.gz rather than just test.json and test.nii.gz.

This does not happen if the folder does not have the "-e02" part.

Is this a parsing bug somewhere or is there a way to get around this?

In trying to compile dcm2niix on Mac OS 10.11, I was repeated stymied with this error
"-- Checking for module 'yams-cpp'
-- No package 'yaml-cpp' found"

I found a fix to patch the CMakeLists.txt file from this website (https://github.com/dapicester/image-search/blob/master/cmake/Modules/FindYamlCpp.cmake).

I'm just learning to use Git. Would someone else mind updating the dcm2niix-master CMakeLists.txt file?
Thanks,
Carl

I sent you 2 datasets: clean_test_success and clean_test_failure. These are 2 different studies.

The "success" produces 2 nii.gz files (one for the converted and one for the equalized pixel spacing converted). The "fail" identifies inconsistent spacing, but only produces 1 nii.gz. Tried both on OS X and Linux (Red Hat). Bolded below is where you see 2 vs. 1 nii produced.

MacBook-Pro-3:clean_test_success johnmuschelli$ dcm2niix .
Chris Rorden's dcm2niiX version 5May2016 (64-bit)
Version 5May2016 (64-bit)
Found 44 DICOM image(s)
Dims 512 512 44 1 1
Warning: interslice distance varies in this volume (incompatible with NIfTI format).
Distance from first slice:
dx=[0 2.5 5 7.5 10 12.5 15 17.5 20 22.5 25 27.5 30 32.5 35 37.5 40 42.5 45 47.5 50 52.5 55 57.5 60 62.5 65 67.5 70 72.5 75 77.5 77.75 85.25 92.75 100.25 107.75 115.25 122.75 130.25 137.75 145.25 152.75 160.25]
Convert 44 DICOM as ./1.1_Head_UPDATED_2_3_09_19000101133622_2 (512x512x44x1)
compress: "/usr/local/bin/pigz" -n -f "./1.1_Head_UPDATED_2_3_09_19000101133622_2.nii"
compress: "/usr/local/bin/pigz" -n -f "./1.1_Head_UPDATED_2_3_09_19000101133622_2_Eq_1.nii"
Conversion required 0.441054 seconds.
MacBook-Pro-3:clean_test_success johnmuschelli$ cd ../clean_test_fail/
MacBook-Pro-3:clean_test_fail johnmuschelli$ dcm2niix ./
Chris Rorden's dcm2niiX version 5May2016 (64-bit)
Version 5May2016 (64-bit)
Found 44 DICOM image(s)
Dims 512 512 44 1 1
Warning: interslice distance varies in this volume (incompatible with NIfTI format).
Distance from first slice:
dx=[0 2.5 5 7.5 10 12.5 15 17.5 20 22.5 25 27.5 30 32.5 35 37.5 40 42.5 45 47.5 50 52.5 55 57.5 60 62.5 65 67.5 70 72.5 75 77.5 77.25 84.75 92.25 99.75 107.25 114.75 122.25 129.75 137.25 144.75 152.25 159.75]
Convert 44 DICOM as ./1.1_Head_UPDATED_2_3_09_19000101172043_2 (512x512x44x1)
compress: "/usr/local/bin/pigz" -n -f "./1.1_Head_UPDATED_2_3_09_19000101172043_2.nii"
Conversion required 0.065939 seconds.

Hi Chris,
When are you planning on cutting a new release? We want to have a stable version available on our cluster.

Dear guys,

As the old dcm2nii can do the auto crop (i.e. dcm2nii -x ) on the brain images to have a proper FOV, which is especially useful when the image contains a big part of the neck tissue. Could I ask if the new dcm2niix has a similar function? The flag "-x" seems not working any more.

Thanks,
Kaiming

Hi,

Firstly, thanks, dcm2niix looks like it's going to be very useful.

I've come across an issue when converting 4D DCE-MRI scans.

When converted, the nifti's zaxis dimensions have been halved and the temporal slices have been doubled. So slices from the axial volume have been added to the temporal dimension instead.

E.g. a volume of dimensions 512x512x56x25 becomes 512x512x28x50 when converted using dcm2niix. Converted using the older dcm2nii tool works fine for this volume.

The dimensions are correctly captured in the header:

Alternatively, if you point me in the right direction, I can try and fix the bug myself.

I've also included a few screenshots as examples. There also appears to be some flipping of the dimensions.

Time point 14 (left converted using dcm2nii and right converted using dcm2niix)

Time point 15 (left converted using dcm2nii and right converted using dcm2niix)

Hi I am getting some warnings during make, some appear to be for use of printf, not sure about the others. I compiled with batch_mode turned on which was not the default. One example:

/home/ericbarnhill/Documents/code/dcm2niix/console/nii_dicom.cpp: In function ‘TJPEG* 
decode_JPEG_SOF_0XC3_stack(const char*, int, bool, int, bool)’:
/home/ericbarnhill/Documents/code/dcm2niix/console/nii_dicom.cpp:2301:37: warning: ignoring return
value of ‘size_t fread(void*, size_t, size_t, FILE*)’, declared with attribute warn_unused_result     

Target was built. Do I need to worry about this?

I can see the fieldStrength is being defined here: https://github.com/neurolabusc/dcm2niix/blob/5bb057e8d6903d08a5ad7bb21d627d5de8f8f110/console/nii_dicom.h#L57

read here: https://github.com/neurolabusc/dcm2niix/blob/5bb057e8d6903d08a5ad7bb21d627d5de8f8f110/console/nii_dicom_batch.cpp#L336

but it is never set. Thus it's always 0 for all input files.

ATM:

head1:/mnt/dbic-mrinbox/DICOM_PHILIPS/2016/10/03/4
$> rm -rf /tmp/out1/; dcm2niix  -f '%q-%s-%z.nii.gz' -o /tmp/out1 bids_fmap 
Chris Rorden's dcm2niiX version 21Sept2016 (64-bit Linux)
Warning: output folder invalid /tmp/out1 will try bids_fmap
Found 72 DICOM image(s)
Error: you do not have write permissions for the directory bids_fmap
Error: you do not have write permissions for the directory bids_fmap
Conversion required 0.037614 seconds.

and that warning is kinda buried among other messages so not immediately observable. If I had intension to save somewhere else, it is better to fail than to save to some other location.

with text of license.