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

Siemens XA30 Software Differences #58

Open
jmatthews-rotman opened this issue Nov 11, 2022 · 7 comments
Open

Siemens XA30 Software Differences #58

jmatthews-rotman opened this issue Nov 11, 2022 · 7 comments

Comments

@jmatthews-rotman
Copy link

I've been setting up protocols with the ReproIn conventions on our Siemens Prisma Fit running XA30 software. I have successfully converted a handful of different protocols now with heudiconv, and am noticing a few consistent issues that I believe are XA30 specific. Of note, XA30 is using enhanced dicoms (doesn't seem to be an issue other than possibly changing the name of some dicom fields) and has changed some built in suffix conventions on the scanner. I'm happy to provide additional details, or upload test datasets depending on what is most helpful. 

Distortion Correction
-Siemens is now forcing distortion correction to be enabled on many sequences. Functional and Diffusion are thankfully exceptions. For most other sequences it is forced on. For a select few sequences (SWI, 3D pcasl) you can't request the unfiltered images at all (seems like only a single in-line recon branch is allowed, as SWI and pcasl have inherent in-line processing, and you also can't request multiple unfiltered variants like distortion correction and prescan normalize). For most (T1, T2, fmap) you can't turn it off but can additionally request the unfiltered images. The additional unfiltered images are tagged with an "_ND" suffix.
-It remains to be seen how most sites/researchers will deal with this. We are choosing to provide the ND images to all legacy protocols to match the old data more closely. We discuss it with new projects, but are defaulting to always providing the ND images for now. With the generally research unfriendly black-box nature of this correction, I might expect ND images to become increasingly popular as research sites upgrade to XA.
- Currently, the ND scans are consistently being converted and labelled with "__dup-xxx" tags.  I'm not sure if this sort of intentionally collected image variation should be labelled dup or recognized as its own image (perhaps there is precedent for protocols where the unfiltered prescan normalize images are also requested). Alternatively, it might be assumed that if the uncorrected images are being requested, they might be the primary interest, and the dup labelling could be reversed. Or the ND suffix could be automatically added to an acq name-pair and treated as a unique scan (I don't know if this might cause issues with e.g. IntendedFor pairing).

MPR's
In-line reconstructions into alternate imaging planes are now able to be automated. I'm not a fan, but some techs and projects are inclined to have them set up in the protocols. For an example, a sagittal scan and its two reconstructed derivatives have SeriesNumber, SeriesDescription, and resulting nii file tags:
"27" - "anat-T1w" - "__dup-01"
"28" - "anat-T1w_MPR_cor" - "__dup-02"
"29" - "anat-T1w_MPR_tra" - no dup tag
The dup tags are out of sequence, and most importantly the base scan is being labelled a dup. It would also seem safe to me to discard MPR's the same way the scouts are discarded. They really only seem to have relevance as dicom files, not as nifties.

Date/Time
During conversion, I see the following error repeatedly:
"WARNING: Failed to get date/time for the content: 'FileDataset' object has no attribute 'AcquisitionDate'"
At a quick glance through the dicom fields of a test scan, I don't see an 'AcquisitionDate' field, although there are a variety of fields specifying date and time at different levels (Study, Series, Content) and a single "Acquisition DateTime" field.

@yarikoptic
Copy link
Member

Thanks for sharing all the details. Do you may be have some samples of such data, ideally on phantom (so no problem with resharing)? For _ND ideally we should add _rec or _proc entity for processed images, and leave _nd as is, but that might be tricky.

@jmatthews-rotman
Copy link
Author

I collected some example phantom data. There is a zip of the dicoms, and a protocol pdf for download here:
https://drive.google.com/drive/folders/1s9P8CfZM0k8fnxo88RE3Gm9SGPmSrqcb
Let me know when you have it downloaded, and I will remove it, unless you think additional folks on this thread will need it.

In case anything is unclear, here is a brief overview of the scans.
1 - scout
2-4 - scout, sequence built-in MPR's
5 - T1, without distortion correction (ND)
6 - T1, with distortion correction
7-8 - T1, "MPR planning" generated MPR's
11 - functional AP
13 - functional PA
15 - field map, magnitude (two echoes), without distortion correction (ND)
16 - field map, magnitude (two echoes), with distortion correction
17 - field map, phase, without distortion correction (ND)
18 - field map, phase, with distortion correction
19 - diffusion AP
21-26 - diffusion AP derivatives
27 - diffusion PA
29-34 - diffusion PA derivatives
35 - asl
36 - asl perfusion derivative
37 - asl m0
38 - asl m0 perfusion derivative

5-6 should demonstrate the ND issue. 15-18 will demonstrate the same in the maybe more complicated field map context.

5-8 should demonstrate the MPR issue, perhaps mixed in with the ND issue. I just realized I haven't actually tried converting a dataset with both the ND and the MPR's.

I included a set of diffusion images, because I noticed that if the built-in derivatives (which we typically turn off, but not always) are included in a set of dicoms, HeuDiConv crashes outright. I suspect this is because of the "ColFA" derivative. The scanner also fails to send those to our XNAT server. I suspect the RGB image breaks dicom expectations. Would be good for HeuDiConv to be able to ignore those.

I also included a set of ASL images. ASL finally made it into the BIDS spec, so it would be great to see ReproIn support it. Seems like a complicated spec though. Let me know if alternate sample data would assist this endeavor. For reference, the above data was collected with the Siemens product 3D ASL sequence. We also have the 2D ASL package and some early XA C2P's from Danny Wang.

@yarikoptic
Copy link
Member

Let me know when you have it downloaded, and I will remove it, unless you think additional folks on this thread will need it.

is it ok to reshare it openly from http://datasets.datalad.org/?dir=/dicoms ? I am giving it siemens-VA30A-1 name but may be it is off and better one is due?

@jmatthews-rotman
Copy link
Author

This is fine to share openly.

We just had our NXA30A-SP02 service pack update if you'd like to be specific. Nothing Siemens shared with us about the update seems like it would impact ReproIn or HeuDiConv. No one has ever explained to me why the scanner and dicoms label it XA30, and the protocol sheet labels it VA30A.

@yarikoptic
Copy link
Member

@celprov
Copy link

celprov commented Mar 2, 2023

Hi,
I would like to back up the problem @jmatthews-rotman reported.

I want to convert to BIDS using heudiconv -f reproin data that we acquired at a Siemens scanner following the reproin sequence naming convention. The scanner generates automatically derivatives of the sequences encoded as extension (e.g _ADC or _ND or _FA) which are understood by heudiconv as duplicate of the scan.
To be very concrete, let me paste here an example.

The following DICOM structure

00001-AAhead_scout_64ch_head_coil
00002-AAhead_scout_64ch_head_coil_MPR_sag
00003-AAhead_scout_64ch_head_coil_MPR_cor
00004-AAhead_scout_64ch_head_coil_MPR_tra
00005-anat_T1w_mprage_ND
00006-anat_T1w_mprage
00007-dwi_dwi_acq_highres_dir_PA_137dir_monopolar00008-dwi_dwi_acq_highres_dir_PA_137dir_monopolar_ADC
00009-dwi_dwi_acq_highres_dir_PA_137dir_monopolar_TRACEW
00010-dwi_dwi_acq_highres_dir_PA_137dir_monopolar_FA
00011-dwi_dwi_acq_highres_dir_PA_137dir_monopolar_ColFA
00012-dwi_dwi_acq_highres_dir_PA_137dir_monopolar_TENSOR
00013-dwi_dwi_acq_highres_dir_PA_137dir_monopolar_TENSOR_B0
00014-fmap_epi_acq_highres_dir_AP_137dir_monopolar
00015-dwi_dwi_acq_lowres_dir_PA_137dir_monopolar
00016-dwi_dwi_acq_lowres_dir_PA_137dir_monopolar_ADC
00017-dwi_dwi_acq_lowres_dir_PA_137dir_monopolar_TRACEW
00018-dwi_dwi_acq_lowres_dir_PA_137dir_monopolar_FA
00019-dwi_dwi_acq_lowres_dir_PA_137dir_monopolar_ColFA
00020-dwi_dwi_acq_lowres_dir_PA_137dir_monopolar_TENSOR
00021-dwi_dwi_acq_lowres_dir_PA_137dir_monopolar_TENSOR_B0
00022-fmap_phasediff_gre
00023-anat_T2w_flair
00099-PhoenixZIPReport

results in the latter BIDS structure

.
├── anat
│   ├── sub-pilot_ses-6_T1w__dup-01.json
│   ├── sub-pilot_ses-6_T1w__dup-01.nii.gz
│   ├── sub-pilot_ses-6_T1w.json
│   ├── sub-pilot_ses-6_T1w.nii.gz
│   ├── sub-pilot_ses-6_T2w.json
│   └── sub-pilot_ses-6_T2w.nii.gz
├── dwi
│   ├── sub-pilot_ses-6_acq-highres_dir-PA_dwi__dup-01.bval
│   ├── sub-pilot_ses-6_acq-highres_dir-PA_dwi__dup-01.bvec
│   ├── sub-pilot_ses-6_acq-highres_dir-PA_dwi__dup-01.json
│   ├── sub-pilot_ses-6_acq-highres_dir-PA_dwi__dup-01.nii.gz
│   ├── sub-pilot_ses-6_acq-highres_dir-PA_dwi__dup-02.json
│   ├── sub-pilot_ses-6_acq-highres_dir-PA_dwi__dup-02.nii.gz
│   ├── sub-pilot_ses-6_acq-highres_dir-PA_dwi__dup-03.bval
│   ├── sub-pilot_ses-6_acq-highres_dir-PA_dwi__dup-03.bvec
│   ├── sub-pilot_ses-6_acq-highres_dir-PA_dwi__dup-03.json
│   ├── sub-pilot_ses-6_acq-highres_dir-PA_dwi__dup-03.nii.gz
│   ├── sub-pilot_ses-6_acq-highres_dir-PA_dwi__dup-04.json
│   ├── sub-pilot_ses-6_acq-highres_dir-PA_dwi__dup-04.nii.gz
│   ├── sub-pilot_ses-6_acq-highres_dir-PA_dwi__dup-05.json
│   ├── sub-pilot_ses-6_acq-highres_dir-PA_dwi__dup-05.nii.gz
│   ├── sub-pilot_ses-6_acq-highres_dir-PA_dwi.json
│   ├── sub-pilot_ses-6_acq-highres_dir-PA_dwi.nii.gz
│   ├── sub-pilot_ses-6_acq-lowres_dir-PA_dwi__dup-01.bval
│   ├── sub-pilot_ses-6_acq-lowres_dir-PA_dwi__dup-01.bvec
│   ├── sub-pilot_ses-6_acq-lowres_dir-PA_dwi__dup-01.json
│   ├── sub-pilot_ses-6_acq-lowres_dir-PA_dwi__dup-01.nii.gz
│   ├── sub-pilot_ses-6_acq-lowres_dir-PA_dwi__dup-02.json
│   ├── sub-pilot_ses-6_acq-lowres_dir-PA_dwi__dup-02.nii.gz
│   ├── sub-pilot_ses-6_acq-lowres_dir-PA_dwi__dup-03.bval
│   ├── sub-pilot_ses-6_acq-lowres_dir-PA_dwi__dup-03.bvec
│   ├── sub-pilot_ses-6_acq-lowres_dir-PA_dwi__dup-03.json
│   ├── sub-pilot_ses-6_acq-lowres_dir-PA_dwi__dup-03.nii.gz
│   ├── sub-pilot_ses-6_acq-lowres_dir-PA_dwi__dup-04.json
│   ├── sub-pilot_ses-6_acq-lowres_dir-PA_dwi__dup-04.nii.gz
│   ├── sub-pilot_ses-6_acq-lowres_dir-PA_dwi__dup-05.json
│   ├── sub-pilot_ses-6_acq-lowres_dir-PA_dwi__dup-05.nii.gz
│   ├── sub-pilot_ses-6_acq-lowres_dir-PA_dwi.json
│   └── sub-pilot_ses-6_acq-lowres_dir-PA_dwi.nii.gz
├── fmap
│   ├── sub-pilot_ses-6_acq-highres_dir-AP_epi.json
│   ├── sub-pilot_ses-6_acq-highres_dir-AP_epi.nii.gz
│   ├── sub-pilot_ses-6_phasediff.json
│   └── sub-pilot_ses-6_phasediff.nii.gz
└── sub-pilot_ses-6_scans.tsv

3 directories, 43 files

@yarikoptic
Copy link
Member

if you just want to get rid of all derived data in conversion, make a local copy of https://github.com/nipy/heudiconv/blob/master/heudiconv/heuristics/reproin.py file as e.g. reproin-noderiv.py with changed line https://github.com/nipy/heudiconv/blob/master/heudiconv/heuristics/reproin.py#L393 to be skip_derived = True and then point your heudiconv -f ./reproin-noderiv.py and all derived sequences should be simply skipped.

For the proper solution we need to decide where to stick them -- nearby with some _rec-???? or IMHO better _proc-???? (how to autodeduce?) or even under derivatives/from-scanner/ or alike, as was somewhat envisioned possibly needing to be done at https://github.com/nipy/heudiconv/blob/master/heudiconv/heuristics/reproin.py#L464 .

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

3 participants