4D+ multiframe enhanced dicom tag concatenation causing errors

[Tim Rosenow]

Hi there.

We currently have multidimensional, multiframe enhanced dicom files containing diffusion tensor MRI scans on a preclinical Bruker scanner (X, Y, Z, B vector). The metadata containing B-vectors is handled with a Per-frame Functional Groups Sequence, which has quite a lot of frames (24 slices, 3 shells, 30 directions each).

When uploading these images to XNAT via the compressed folder (or the uncompressed dicom via REST), it seems that XNAT handles these per-frame functional groups by concatenating them together into a single dicom tag? As a result, it creates a long string that exceeds the DICOM 255 character limit (see error message below).

Extraction/Review failed: [bValues -> xs:string, Must Be Less Than 255 Characters : Current Length (1024), xnat:mrSessionData/imageSessionData/scans/scan[0]/parameters/diffusion/bValues, The content of element 'xnat:mrScanData' is not complete. '{"http://nrg.wustl.edu/xnat":parameters/diffusion/bValues}' Must Be Less Than 255 Characters : Current Length (1024)]

We would prefer to not just remove the b-values from the metadata, as it's critical for analysis. I'm assuming that there's no way to preserve the multiframe enhanced dicom structure in XNAT, so does anyone have any suggestions on the best way to handle this without just wiping out the B-value data before upload? If I were to modify the way in which the files were imported, where would this process occur? It doesn't seem to be explicitly stated in any of the import processor instances.

My backup plan is to create a b-matrix text file to upload alongside the DTI scans and just wipe the B matrix metadata from the dicom headers, but that's obviously not ideal.

[Charlie Moore]

Hi there,

Sorry, this is a rather unsatisfying answer, but you're basically running into another instance of this https://groups.google.com/g/xnat_discussion/c/qCL4wV6HyuA/m/pwP9Od67AgAJ / https://issues.xnat.org/browse/XNAT-6064 . It's not concatenating the values into a DICOM tag, but rather failing when attempting to save the value to the database. 

Thanks,

Charlie Moore

[Charlie Moore]

As an update to this issue, XNAT-6064 should hopefully be fixed when XNAT 1.8.9 is released, but this is technically a different issue. Instead of the problem being from generic xnat:field fields having a max length of 255, this is for parameters/diffusion/bValues [in the schema]. I've recreated it and reported it here: https://radiologics.atlassian.net/browse/XNAT-7856 . I can't make any promises, but I'll try to get it prioritized soon :)

Thanks,

Charlie Moore

[Tim Rosenow]

Thank you very much!

[Emma Mantel]

Hello, I just wanted to comment that we have the same issue with some scans, and that any progress on this would be greatly appreciated!

[Tim Rosenow]

I know it's not the ideal fix, but I did throw together a quick plugin that stops XNAT putting the B vectors in its database, based on Charlie's suggestion. It's very quick and dirty but does the job, you can download the .jar here:

https://github.com/WANIF/xnat-custom-plugins/tree/main/mr-bvalue-fix-plugin

[Daniel Drucker]

Is this plugin still needed (I'm on XNAT 1.10.0)?  From my cursory investigation, it looks like xnat.xsd now defines bValues as xs:string with no maxLength.

MRScanAttributes still extracts diffusion b-values, but I think now it should no longer fail validation?

So I THINK we can remove this now?

Daniel

[Tim Rosenow]

I haven't even looked at that, but it can probably go then!

--
You received this message because you are subscribed to a topic in the Google Groups "xnat_discussion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/xnat_discussion/JvWP7ZF2sKM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to xnat_discussi...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/xnat_discussion/3f9f8e03-8a38-4ded-89ac-5b6054c8075bn%40googlegroups.com.