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.

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

Slices not stacked #667

Closed
RikvdElshout opened this issue Jan 12, 2023 · 4 comments
Closed

Slices not stacked #667

RikvdElshout opened this issue Jan 12, 2023 · 4 comments

Comments

@RikvdElshout
Copy link

I'm trying to convert DTI DICOM to niftii with bvec and bval files, but i keep getting the error

Found 192 DICOM file(s)
Slices not stacked: Study Date/Time (0008,0020;0008,0030) varies 20220602102946.445312500000 ~= 20220602102946.503906250000
Convert 1 DICOM as [file location]
Convert 1 DICOM as [file location]

It does this for 192 separate images, not combining them and not generating the bvec and bval files.
I'd be happy to share a few datasets to see if anyone knows what the problem is and how to counter it.

Running on Chris Rorden's dcm2niiX version v1.0.20220720 (JP2:OpenJPEG) (JP-LS:CharLS) MSC1900 (64-bit Windows) using MRIcroGL GUI.

Thanks in advance,
Rik

@neurolabusc
Copy link
Collaborator

The Study Date/Time is used to disambiguate different datasets from each other. A single session saved with different time stamps is not of archival quality and you really need to carefully examine the provenance of these images to identify where they were corrupted. A first step would be to acquire data directly from the scanner rather than from a PACS system to see if the issue occurs at creation or was corrupted by a subsequent tool that handled the data.

If you upload the BIDS json text file that dcm2niix creates it may also include some clues. In particular, I wonder if this data came from an early XA10 Siemens instrument that created problematic DICOMs. If this is case, you should work with your Siemens Research Collaboration Manager to ensure that the system is upgraded to XA20 and have their help with mitigating data loss.

@RikvdElshout
Copy link
Author

Hi,
Thanks for your quick reply,

I've added three JSON files from the same scan converted to txt files due to the inability to upload JSON files. I see these particular scans were performed on a philips ingenia model. I hope these make sense to you. I will also reach out to the supplier of the data to see whether they can supply data directly from the scanner and/or troubleshoot their PACS system.
dtitestb.txt
dtitest.txt
dtitesta.txt

Thanks again!
Rik

@neurolabusc
Copy link
Collaborator

I note you are using v1.0.20211006. DICOM implementations are evolving rapidly, so make sure you use the latest version. It is unclear if the error is due to the scanner, the PACS or the anonymization. You should check the provenance of these images to work out at what stage they were corrupted. Since this is from a Philips scanner, you should contact the Philips Clinical Scientist who works with the institution that owns the instrument. It is their role to help you resolve this issue.

If you want to salvage your data, you could use gdcmanon to --replace the timestamps. If you have numerous series, you may want to rename your DICOMs first (dcm2niix -r y /path/to/DICOMs) and only fix the corrupted series.

I would suggest we close this issue. dcm2niix is working as intended: it assumes series timestamps are internally consistent and that the data is truthful.

@neurolabusc
Copy link
Collaborator

Limitation is with DICOM images, not dcm2niix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants