Siemens XA30 Software Differences #58
Comments
|
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. |
|
I collected some example phantom data. There is a zip of the dicoms, and a protocol pdf for download here: In case anything is unclear, here is a brief overview of the scans. 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. |
is it ok to reshare it openly from http://datasets.datalad.org/?dir=/dicoms ? I am giving it |
|
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. |
|
thanks! finally shared at http://datasets.datalad.org/?dir=/dicoms/jmatthews-rotman/siemens-VA30A-1 ! |
|
Hi, I want to convert to BIDS using The following DICOM structure
results in the latter BIDS structure
3 directories, 43 files |
|
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. For the proper solution we need to decide where to stick them -- nearby with some |
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.
The text was updated successfully, but these errors were encountered: