Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Philips DCE-MRI DICOM #463

Closed
ghost opened this issue Dec 11, 2020 · 17 comments
Closed

Philips DCE-MRI DICOM #463

ghost opened this issue Dec 11, 2020 · 17 comments
Labels
wontfix

Comments

@ghost
Copy link

ghost commented Dec 11, 2020

Hi,

I would like to report an issue about the conversion of DCE-MRI enhanced dicom data (multiple acquired volumes over time) to nifti with the latest version of dcm2niix. This scan was acquired at a Philips scanner. Instead of providing one 4D nifti as output (x,y,z,60 timepoints), it gives two 4D niftis: 1) 4D nifti with 27 volumes over time and 2) 4D nifti with 33 volumes over time. The files seem to be randomly divided over these 2 niftis and are not sorted.
However, I noticed that this conversion goes well for an older version of dcm2niix (e.g. 2018).
@neurolabusc
Copy link
Collaborator

Does the software warn you why the Slices not stacked. For example, Slices not stacked: coil varies. A feature of recent releases of dcm2niix is that it is able to detect corrupted or damaged DICOM datasets. The warnings should alert you to situations that need human intervention.

@neurolabusc
Copy link
Collaborator

Does forcing images to be merged -m y regardless of echo time, exposure time, etc. resolve your issue?

dcm2niix -m y -f %s_%p /path/to/DICOMs

If this stacks all your images, you may want to determine if the reasons they were not combined impacts your subsequent analyses. For example, if running the command

dcm2niix -m n -f %s_%p /path/to/DICOMs

Reports Slices not stacked: echo varies (TE 3.6, 4.7; echo 1, 2) you may choose to ignore this variation, or you may want to model this in your analysis.

@ghost
Copy link
Author

ghost commented Dec 14, 2020 via email

@ghost
Copy link
Author

ghost commented Dec 14, 2020 via email

@neurolabusc
Copy link
Collaborator

Is it possible that these images do not share a series or study instance UID? You can check by putting %j in the filename argument:

  • %j=series instance UID (from 0020,000E)
  • %k=study instance UID (from 0020,000D)

for example

dcm2niix -f %t_%s_%j_%k /path/to/DICOMs

Feel free to send me a link to these images via Box/GoogleDrive veto the email listed in my avatar.

@ghost
Copy link
Author

ghost commented Dec 16, 2020 via email

neurolabusc added a commit that referenced this issue Dec 16, 2020
@neurolabusc
Increase details for series stacking, enhance merge override mode (#463)
8b99a98
@neurolabusc
Copy link
Collaborator

Can you test the latest commit to the development branch (it will report v1.0.20201216). It can provide more details regarding why slices from a single series are not combined, and also provides additional overrides for these options.

If you can provide the output from this command, it should provide richer details regarding why series 901 has been split:

dcm2niix -v 1 -f %t_%s_%j_%k /path/to/DICOMs

The merge override option will combine scans despite many variations (such as changes in the coil).

dcm2niix -m o -f %t_%s_%j_%k /path/to/DICOMs

@drmclem I realize this is a WIP (Work-In-Progress) not a product sequence, so you may not have any details. However, can you think of any reasons different slices in this sequence may vary from each other (coil, UIDS, protocol name, series time, etc)?

@ghost
Copy link
Author

ghost commented Dec 16, 2020 via email

@neurolabusc
Copy link
Collaborator

neurolabusc commented Dec 16, 2020 •
edited
Loading

  1. Are you sure you are running the latest commit (v1.0.20201216)? The text you pasted does not include the first few lines of output that report the version, and the formatting is lost, making it hard to understand what is going on. My guess is that this output is from v1.0.20200331. You want to test the latest stable version v1.0.20201102 and if that fails, try the latest developmental commit (v1.0.20201216). Can I suggest you redirect the entire output to a text file and then drag-and-drop the entire text file onto your GitHub response:
dcm2niix -v 1 -f %t_%s_%j_%k /path/to/DICOMs > out.txt
  1. Unix users can test the latest developmental commit:
git clone --branch development https://github.com/rordenlab/dcm2niix.git
cd dcm2niix/console
make
./dcm2niix

Windows users should be able to get a compiled version from AppVeyor (click on the Artifacts button).

@ghost
Copy link
Author

ghost commented Dec 17, 2020 via email

@neurolabusc
Copy link
Collaborator

So the latest stable release (v1.0.20201102) resolves your issue?

@ghost
Copy link
Author

ghost commented Dec 18, 2020

No, I still have the same problem with the latest version. I have attached the output in a txt file

out.txt

@neurolabusc
Copy link
Collaborator

What is the output from the developmental commit (v1.0.20201216)?

@ghost
Copy link
Author

ghost commented Dec 18, 2020

Where can I download this developmental commit?

@neurolabusc
Copy link
Collaborator

(if neither of these options work, email me at address in my avatar and I can send you a recompiled copy):

Unix users can test the latest developmental commit:

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

Windows users should be able to get a compiled version from AppVeyor (click on the Artifacts button).

@ghost
Copy link
Author

ghost commented Dec 18, 2020

Thank you!
Unfortunately, this version doesn't solve the problem. I have attached the output text.

out1216.txt

@neurolabusc
Copy link
Collaborator

I do not have sufficient information to resolve this problem. I do not have access to an exemplar. This data is from a WIP (work in progress) sequence rather than a product sequence. Without seeing an example, it is unclear if the issue is with dcm2niix or the DICOM, and whether dealing with this will cause unintended consequences as seen with previous single customer solutions. Since this is a WIP, you will have access to a Philips Research Collaboration manager. I would work with them to resolve this. I would discourage you from using this nascent sequence with any version of my software, even if it appears to work on older versions. Philips research customers also have access to the Philips proprietary NIfTI export and PAR/REC export. This may be a better choice for this data. Feel free to submit a pull request if you have a solution you wish to share with the rest of the community.

@neurolabusc neurolabusc mentioned this issue Dec 24, 2020
Closed
yarikoptic added a commit to neurodebian/dcm2niix that referenced this issue Apr 6, 2021
@yarikoptic
Merge commit 'v1.0.20200427-97-g0587941' into debian
825cec6 
* commit 'v1.0.20200427-97-g0587941': (22 commits)
  Overflow for Siemens data [missing protocol name] (rordenlab#466)
  MacOS notarization, minor tweaks
  Increase details for series stacking, enhance merge override mode (rordenlab#463)
  Bump version date
  Retain Philips Scaling Values for images where scaling does not vary but volumes must be separated (rordenlab#461)
  Support huge PAR/REC files (rordenlab#460)
  Prevent dti4D overflow
  Fix PAR/REC ADC detection (rordenlab#462)
  DICOM field map calibrated in Hz given name _fieldmaphz (rordenlab#455)
  PAR/REC field map calibrated in Hz given name _fieldmaphz (rordenlab#455)
  Ignore LocationsInAcquisition (0020,1002) if number of slices is not evenly divisible with this value (rordenlab#459)
  Convert DICOM series where bit allocated (0028,0100) varies across slices (rordenlab#458)
  Clear RepetitionTimeExcitation (rordenlab#457)
  leak (rordenlab#454)
  Single file mode memory allocation (rordenlab#454)
  When -n is specified, only save BIDS for requested series (rordenlab#453)
  Use 1st study time if multiple times provided.
  Apple. M1. use C++ not. C
  Fix CMake for Apple Silicon (note similar change required for CloudFlare zlib)
  Only report b-value for GE data with 0043,1039 if EPI (0018,9018) (rordenlab#449)
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
wontfix
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@neurolabusc