NITRC dcm2nii Forum: questions

RE: find DICOM

Chris Rorden — Sat, 27 Sep 2025 19:44:11 GMT

<p>This forum is for dcm2niix which converts DICOM images to NIfTI, not the reverse. I suggest you contact the teams that share the ABIDE II dataset to see if they share the DICOM images.</p>

find DICOM

marjan safari — Sat, 27 Sep 2025 17:43:56 GMT

<p>How can I find DICOM for ABIDE II ? </p>

RE: Option to convert only single series does not work

Chris Rorden — Thu, 04 Sep 2025 11:56:34 GMT

<p>The -n option is an advanced feature that is used by MRIcroGL and FSLeyes to provide a user with a list of all of the DICOMs in a folder and allow them to select just one to load. Since a folder might have many repeats of a particular series, you need to know how dcm2niix encodes the details as a CRC code. Therefore, to use the -n option you run it twice, once with the value -1 to list CRCs and their corresponding series, and subsequently with the CRC of the series you wish to convert. To provide a concrete example with Siemens XA60, consider the validation dataset dcm_qa_xa60 where we only want to convert the series that used the CMRR research sequences and with iPAT=3 and multi-band = 1. We first query the folder to identify the CRC (which turns out to be 257128538) and then convert just that series:<br><br></p>
<div>$ git clone https://github.com/neurolabusc/dcm_qa_xa60</div>
<div>$ dcm2niix -n -1 ./dcm_qa_xa60</div>
<div>Chris Rorden's dcm2niiX version v1.0.20250626  Clang17.0.0 ARM (64-bit MacOS)</div>
<div>257128538 ./dcm_qa_xa60/dcm_qa_xa60_C2P_cmrr_mbep2d_bold_p3_mb1_20241004141746_8</div>
<div> ./dcm_qa_xa60/In/XA60/DICOM/24100413/39280000/75739574</div>
<div> ..</div>
<div>  3832686387 ./dcm_qa_xa60/dcm_qa_xa60_C2P_cmrr_mbep2d_bold_p2_mb5_20241003104115_12</div>
<div> ./dcm_qa_xa60/In/XA61/DICOM/24100310/14440000/88972664</div>
<div>$ dcm2niix -n 257128538 ./dcm_qa_xa60</div>
<div>Chris Rorden's dcm2niiX version v1.0.20250626  Clang17.0.0 ARM (64-bit MacOS)</div>
<div>Convert 3 DICOM as ./dcm_qa_xa60/dcm_qa_xa60_C2P_cmrr_mbep2d_bold_p3_mb1_20241004141746_8 (64x64x10x3)</div>
<div>Conversion required 0.269020 seconds (0.268941 for core code).<br><br>Note that when you query dcm2niix, it reports the following details for each series: CRC; filename; (image_dimensions). You can use the `-f` option to choose what details should be shown in the filename, which can help you parse what image you will convert, for example `-f %t_%s_%p` will provide the datetime_seriesNumber_protocolName.</div>
<div> </div>
<p> </p>

Option to convert only single series does not work

Christian Paret — Thu, 04 Sep 2025 11:12:35 GMT

<p>Hey there,</p>
<p>first of all: great software!</p>
<p>dcm2niix works fine, as long as I do not use option -n (e.g., -n 4) to convert single series. From the output written to the terminal, everything seems to run quite fine. I also get the message "Conversion required 6.709000 seconds", but no nifti-images are written to the output folder. As said, as long as I do not add option -n to command line, everything works as expected and nifti-output is received.</p>
<p>I am using dcm2niiX version v1.0.20250505 with dicoms acquired with Siemens syngo XA60. I should say that I use to operate dcm2niix via matlab (system('PathTo/dicm2niix.exe')</p>
<p>Hope, there is a solution?</p>

RE: Not all metadata converts for .json (dcm2niix)

Chris Rorden — Mon, 25 Aug 2025 18:36:44 GMT

<p>I would recommend using the current stable release <a class="Link--primary Link" href="https://github.com/rordenlab/dcm2niix/releases/tag/v1.0.20250506" data-view-component="true" data-turbo-frame="repo-content-turbo-frame">(v1.0.20250506)</a><br>  https://github.com/rordenlab/dcm2niix/releases</p>
<p> </p>
<p>I am unsure what the question is - it seems like you are converting the images two different ways and getting diferent JSONs, but I do not know what the difference between the "direct" and "indirect" mode. I would convert the files like this:<br> dcm2niix /path/to/DICOMs</p>
<p>Is there some other tool you are using? If so does the tool use the same version of dcm2niix (the JSON should report the version `"ConversionSoftwareVersion": "v1.0.20250505"`). <br><br>dcm2niix should populate the fields of the DICOM, those these vary from a system running V<em> (e.g. VE11) versus XA</em> (e.g. after upgrade to XA30).  Note that the CSA headers are crucial for many sequence details, so enure that your PACS or anonymization scripts do not remove these from the DICOMs before dcm2niix converts them.<br><br>https://github.com/rordenlab/dcm2niix/tree/master/BIDS</p>

Not all metadata converts for .json (dcm2niix)

Kylie Isenburg — Mon, 25 Aug 2025 18:15:33 GMT

<p>Hi, </p>
<p>I'm using dcm2niix v1.0.20241211 to convert my DICOMs to BIDS format. The scanner is a Siemens MAGNETOM Skyra. </p>
<p>The data properly converts but the metadata in the .json file is much more bare than the .json I get if I just use dcm2niix directly on the DICOMS. Any reason as to why this might be?</p>
<p> </p>
<p>Thanks in advance!</p>
<p>Kylie </p>

RE: v20241211 - Philips diffusion enhanced scans

Chris Rorden — Thu, 12 Jun 2025 17:10:32 GMT

<p>Your images look fine. The issue is that Siemens DWI scans ALWAYS start with a b=0 volume, while this is not the case for Philips. Therefore, old versions of dcm2niix would reorder Philips volumes to make the first volume the b=0, which allows you to neglect the final parameter for FSL’s eddy_correct: <br>   eddy_correct <4dinput> <4doutput> <reference_no><br><br>However, modern versions of FSL’s eddy/topup assume that data is provided in the order temporarlly acquired, modelling motion for artifacts. Due to this, modern versions of dcm2niix do not reorder data. Regardless of which verion of dcm2niix you use, the bval and bvec orders correspond to the image order, so things should process fine, albeit the new FSL tools might give a slightly more precise answer for newer data.<br><br>Note that with the old dcm2niix, the first volume is bright (as b=0 has higher SNR), while the subsequent volumes are dark. With the new version, the reverse is true, which you can see with the intensity timeline below.</p>

RE: v20241211 - Philips diffusion enhanced scans

Chris Rorden — Wed, 11 Jun 2025 11:29:36 GMT

<ol>
<li>I would ensure you use the latest stable release (v1.0.20250506)</li>
<li>I do not have access to Philips hardware - if issues persist, feel free to share a sample dataset with my institutional email<br>  https://sc.edu/study/colleges_schools/artsandsciences/psychology/our_people/directory/rorden_chris.php</li>
</ol>

v20241211 - Philips diffusion enhanced scans

csee — Wed, 11 Jun 2025 11:12:08 GMT

<p>Dear Chris,</p>
<p>We have recently updated our scripts to run the dcm2niix v20241211 version, and it does not seem to be working for our DTI scans anymore (Philips scanner, enhanced DICOMs). The output NIFTI is very dark and does not look as expected.</p>
<p>We were previously converting using v1.0.20170624, which worked great for the DTI scans (enhanced DICOM), but would like to be able to move to the latest converter to avoid any other issues cropping up (I am not an expert here so unsure if using a legacy version could cause other unforseen issues).</p>
<p>I have attached the output log from running dcm2niix v20241211 where you can see the warning messages about the DTI and the fieldmaps.</p>
<p>There are also warning messages for our SWI sequences so again, I'm not sure if these are problematic. Visually the NIFTIs look fine for SWIs...</p>
<p>On the upside, the v2024 seems to be converting our functional MRI sequences (where it seemed a bit problematic on the older version).</p>
<p>If you have any advice on what we could try or if we're missing something obvious, that would be much appreciated.</p>
<p>Thank you!</p>
<p>Best wishes</p>
<p>Cheryl</p>

RE: dcm2niix - Warning: Slice timing appears corrupted

Chris Rorden — Tue, 15 Apr 2025 13:53:14 GMT

<p>Great. The validation datasets demonstrate that the latest stable release extracts slice times from a CimaX running XA61 for both the product and CMRR research sequences:<br>  https://github.com/neurolabusc/dcm_qa_xa60/tree/main/Ref<br>Therefore, if you do not have slice times, my first guess is that critical DICOM tags were stripped from your dataset prior to dcm2niix (persumably from an anonymization stage). You can test this by downloading images directly from the scanner console to a USB device, without having a PACS manipulate the images. If you still have an error, upload the JSON that dcm2niix creates. This is also a great opportunity to work with the Siemens Research Collaboration Manager associated with your center.</p>