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

conflicting study identifiers in ABCD data #280

Open
DVSneuro opened this Issue Nov 28, 2018 · 7 comments

Comments

Projects
None yet
3 participants
@DVSneuro
Copy link

DVSneuro commented Nov 28, 2018

Hi, I'm using heudiconv to convert some of the ABCD data into BIDS format, but it seems to only be working on data collected on the Siemens scanner. For the other scanners, I'm getting the error below.

INFO: Running heudiconv version 0.5.2-dev
INFO: Need to process 1 study sessions
INFO: PROCESSING STARTS: {'subject': 'NDARINVE367LYLC', 'outdir': '/output/', 'session': None}
INFO: Processing 49972 dicoms
INFO: Analyzing 49972 dicoms
Traceback (most recent call last):
File "/opt/miniconda-latest/bin/heudiconv", line 11, in
load_entry_point('heudiconv', 'console_scripts', 'heudiconv')()
File "/src/heudiconv/heudiconv/cli/run.py", line 125, in main
process_args(args)
File "/src/heudiconv/heudiconv/cli/run.py", line 338, in process_args
overwrite=args.overwrite,)
File "/src/heudiconv/heudiconv/convert.py", line 159, in prep_conversion
grouping=None)
File "/src/heudiconv/heudiconv/dicoms.py", line 88, in group_dicoms_into_seqinfos
studyUID, file_studyUID
AssertionError: Conflicting study identifiers found [1.2.840.113619.6.374.258119085267376010175966987442804122141, 1.2.840.113619.6.374.54018679043989047307905145274801870417].

I've tried running dcm2niix on these dicoms outside of heudiconv, and that seems to work fine.

Thanks for any advice!
David

@yarikoptic

This comment has been minimized.

Copy link
Member

yarikoptic commented Nov 28, 2018

I guess that study (i.e. sessio)n was interrupted, subject was taken out, put back in and and some sequences reran?

you could try using grouping by accession -- -g accession_number, and eventually we should finish or redo #200

@DVSneuro

This comment has been minimized.

Copy link
Author

DVSneuro commented Nov 28, 2018

I'm not 100% sure if the session was interrupted, but based on the dcm2niix output, that could be the case with the fieldmaps here:

tug87422@cla18994 /data/projects/abcd-mid/raw/fasttrack/sub-NDARINVB11UX0B3 $ dcm2niix -o `pwd` ses-baselineYear1Arm1
Compression will be faster with 'pigz' installed
Chris Rorden's dcm2niiX version v1.0.20180622 GCC5.3.1 (64-bit Linux)
Found 49972 DICOM file(s)
slices not stacked: dimensions or bit-depth varies
Convert 120 DICOM as /data/projects/abcd-mid/raw/fasttrack/sub-NDARINVB11UX0B3/ses-baselineYear1Arm1_ABCD-fMRI-FM_GE_original_(baseline_year_1_arm_1)_20170531152854_2 (128x128x60x2)
slices not stacked: Study Date/Time (0008,0020 / 0008,0030) varies 20170531152854.000000000000 ~= 20170531115538.000000000000
Convert 120 DICOM as /data/projects/abcd-mid/raw/fasttrack/sub-NDARINVB11UX0B3/ses-baselineYear1Arm1_ABCD-fMRI-FM_GE_original_(baseline_year_1_arm_1)_20170531152854_9 (128x128x60x2)
Convert 120 DICOM as /data/projects/abcd-mid/raw/fasttrack/sub-NDARINVB11UX0B3/ses-baselineYear1Arm1_ABCD-fMRI-FM_GE_original_(baseline_year_1_arm_1)_20170531115538_9 (128x128x60x2)
Convert 120 DICOM as /data/projects/abcd-mid/raw/fasttrack/sub-NDARINVB11UX0B3/ses-baselineYear1Arm1_ABCD-fMRI-FM_GE_original_(baseline_year_1_arm_1)_20170531115538_3 (128x128x60x2)
Convert 120 DICOM as /data/projects/abcd-mid/raw/fasttrack/sub-NDARINVB11UX0B3/ses-baselineYear1Arm1_ABCD-fMRI-FM_GE_original_(baseline_year_1_arm_1)_20170531152854_6 (128x128x60x2)
Convert 24480 DICOM as /data/projects/abcd-mid/raw/fasttrack/sub-NDARINVB11UX0B3/ses-baselineYear1Arm1_ABCD-MID-fMRI_GE_original_(baseline_year_1_arm_1)_20170531152854_1100 (90x90x60x408)
Convert 24480 DICOM as /data/projects/abcd-mid/raw/fasttrack/sub-NDARINVB11UX0B3/ses-baselineYear1Arm1_ABCD-MID-fMRI_GE_original_(baseline_year_1_arm_1)_20170531152854_1000 (90x90x60x408)
Convert 204 DICOM as /data/projects/abcd-mid/raw/fasttrack/sub-NDARINVB11UX0B3/ses-baselineYear1Arm1_ABCD-T2_GE_original_(baseline_year_1_arm_1)_20170531115538_8 (256x256x204x1)
Convert 208 DICOM as /data/projects/abcd-mid/raw/fasttrack/sub-NDARINVB11UX0B3/ses-baselineYear1Arm1_ABCD-T1_GE_original_(baseline_year_1_arm_1)_20170531115538_2 (256x256x208x1)
Conversion required 28.473094 seconds (28.289537 for core code).

The ABCD Study includes data from three scanners, but only the Siemens data seems to be cooperating with heudiconv at the moment. I've tried a different subject and I'm getting the same error, with and without the -g accession_number flag included. This particular task includes two runs of functional data, and the ABCD team does have those functionals stored in separate folders.

@yarikoptic

This comment has been minimized.

Copy link
Member

yarikoptic commented Nov 28, 2018

by any chance -- do you have phantom runs on all the scanners using ABCD protocols/sequences which could potentially be shared publicly? would make it easier to implement all needed/desired support

@DVSneuro

This comment has been minimized.

Copy link
Author

DVSneuro commented Nov 28, 2018

I don't, but I'll look into that. In theory, all of their data should be released in BIDS format, but that is not currently the case, at least from what I've seen.
https://www.biorxiv.org/content/early/2018/11/04/457739

@sjburwell

This comment has been minimized.

Copy link

sjburwell commented Nov 29, 2018

Greetings,

I have a related issue to the above whereby heudiconv (docker implementation, 0.5.dev1) throws a conflicting study error (see below). For this participant/session, there was a system error and the console needed to be rebooted midway through the session. Thus, the scanning took place on the same day (and proximal in time, i.e., the same "session"), but the dicoms have different study identifiers. The accession_number for all dicoms is blank (i.e., ''), and when I tried using the above suggestion ("-g accession_number") it still seemed to be looking for "StudyInstanceUID." Does the accession number need to be a non-blank value? Any thoughts on whether I can 'trick' heudiconv into thinking this data comes from the same session?

Best,
Scott

Error::
Conflicting study identifiers found [1.3.12.2.1107.5.2.43.67010.30000015061717133439900000013, 1.3.12.2.1107.5.2.43.67010.30000015061722134788600000001]

Update (w/ fix): 2018-12-10
For the meantime, I've manually changed the StudyUID for each dicom within a directory for one session. I was never able to make the accession_number option work, even if I forced all dicoms to have the same value in the field AccessionNumber.

#go thru all dicoms and look for inconsistent studyUIDs, if there are any, change them to match the first one.
import pydicom
alldcm = glob.glob(tmpdir + '/*/MRI/DICOM/*.dcm')
for jj in range(0,len(alldcm)):
    ds = pydicom.dcmread(alldcm[jj])
    if jj is 0:
        studyUID = ds.StudyInstanceUID
    ds.StudyInstanceUID= studyUID
    ds.save_as(alldcm[jj])
@DVSneuro

This comment has been minimized.

Copy link
Author

DVSneuro commented Jan 28, 2019

@yarikoptic Sorry for the slow follow up on this. The ABCD team didn't want to share the phantom data (they also didn't think it would be helpful since it apparently doesn't include the same sequences as the human data). Would it be possible for me to privately share some of the problematic data? I'm still still seeing the same issue with the latest version of HeuDiConv (0.5.4.dev1). Thanks again!

@yarikoptic

This comment has been minimized.

Copy link
Member

yarikoptic commented Jan 28, 2019

@DVSneuro, sure, let's continue via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment