Dcm2niix / dcm2bids / bidskit output problem - suggestions?

Hi,

I’m new here and hope I’m posting this correctly. Also hope there is someone out there who can help…

I am running os Catalina, and I have tried to install dcm2bids, dcm2niix and bidskit through git in terminal. I have also tried doing that in anaconda/spyder.
Now, when I run either of them, my dicoms are being converted to niix.gz and I get a json. BUT it seems as if each dcm file is being converted separately, I thus end up with almost as many nii’s and json as I have dcm’s. Does anybody have an idea why this could be? I tried with MRIcroGL, that produced the same results (except when I put ‘always merge regardless of difference’, but that doesn’t sound like a long term solution…or any real solution…).

edit: when looking at the multiple jsons, it looks all the same except the TriggerDelayTime, which seems to be added to the outputs files name as well, and each one produces a separate niix/json.

Thank you in advance,
BW,
Aleks

@Dugmic, you did not report the scanner you are using or the version of dcm2niix you are using. I am going to guess that your data is from a Philips scanner. Specifically, I think you are experiencing issue 408 where Philips fMRI sequences erroneously report a cardiac trigger time 0018,1060. This is a limitation of your images, not of my software. Philips is aware of this, and so presumably future software updates will fix this. If you want to fix your data, you can use a command like gdcmanon --dumb --remove 0018,1060 img.dcm.

You could also try the development branch of dcm2niix, that provides a kludge that attempts to handle this situation:

git clone --branch development https://github.com/rordenlab/dcm2niix.git
cd dcm2niix/console
make
./dcm2niix

Hi Chris,
Thank you for your time and effort to help. I hope I didn’t give the impression your software was the problem. It’s indeed a Philips. I actually see more than one trigger time that seems to be a problem =/ I also tried the ‘git clone…’ and now dcm2niix doesn’t work anymore it seems, so also not sure which version it was, but I got it from here https://github.com/rordenlab/dcm2niix

Is there any way to prevent this problem from happening when extracting the data from the scanner?

Thank you!

You can have multiple copies of dcm2niix on your computer. The commands I provided should build a copy in the folder “?/dcm2niix/console” with ? being the path where you ran the git clone command. You can always determine the version of dcm2niix you are using - it is in the first line reported. So just running “./dcm2niix” will report the version in the current working directory:

 >./dcm2niix
Chris Rorden's dcm2niiX version v1.0.20200904  Clang11.0.0 x86-64 (64-bit MacOS)

We do not have Philips hardware at my site. However, in issue 408, @drmclem suggests this is only seen with Classic DICOM export, so the simple solution is to just export your data from the MR console as enhanced DICOM.

Hi Chris,
I just got the development clone to work, and it solved the issue!
I will just continue using that version, thanks so much for sharing!

Couple small questions:

  • is there a way to get the bids folder structure with ./dcm2niix or would I have to make that myself?
  • do you have any idea why dcm2niix would work on windows but produce a different output on my Mac, even though the dicoms used are the same?

Thank you =)

  1. dcm2niix converts DICOM images to NIfTI with a BIDS sidecar. To develop the BIDS naming and folder structure you will want to one of the tools listed in the links section of the dcm2niix page. For future acquisitions, you might consider setting up your sequences to use reproin conventions to aid conversion.
  2. I suspect you are running different versions on your different computers. The single source code compiles to Windows, Linux and macOS, so they should perform identically. Specifically, I suspect your Windows build pre-cedes issue 384. More recent versions have added detection of cardiac triggers which is useful for some images. However, an unintended consequence of this new feature is that it segmented invalid DICOM images that populated the cardiac trigger tag for sequences without cardiac recording. Again, this reflects an error in your DICOM data. The free tools gdcmdump and dcmdump can allow you to view the DICOM headers directly. For macOS users, I recommend the free Horos which will display DICOM headers as well as images.
  1. I have bidskit installed, but it doesn’t recognise the dcm2niix as installed from the clone you posted above and command now being ./dcm2niix.
  2. I’m waiting to hear which version he uses. But we both downloaded them from “https://github.com/rordenlab/dcm2niix” using the git install for the latest release as described under install.
  3. If I were to try gdcmanon --dumb --remove 0018,1060 img.dcm, how would I use that?
  1. You will want to make sure that the version of dcm2niix used by bidskit is the developmental release. I suspect you do this by modifying your system path.
  2. As noted, old versions ignored the cardiac trigger time, so do not show errors for bogus values in this field.
  3. The problem is with your images reporting the wrong value, not my software. Therefore, you have three solutions:
    a. use new versions of my software that detect that the values are bogus.
    b. use old versions of my software that ignore this tag.
    c. Fix your images to remove the bogus values. This will ensure any tool will provide the correct result, and will yield archival quality DICOM images. A simple script could use gdcmanon to fix each and every DICOM image.

The FSL and AFNI groups have some nice UNIX tutorials that could provide a good foundation for learning about shell scripting, paths and other details.

1 Like

MANAGED BY INCF