Future plans regarding DCM field length bug

[Tim Rosenow]

Hi there.

I was wondering, what are the plans regarding the bug outlined here:

https://groups.google.com/g/xnat_discussion/c/JvWP7ZF2sKM/m/zP1QKds5CAAJ

and here:

https://issues.xnat.org/browse/XNAT-6064

whereby multi-frame DICOM fields are concatenated and exceed the database field storage size (despite being within the DICOM specified size)?

The bug tracker implies this is deferred until after 'DICOM WEB' is ready but I'm not entirely sure what that refers to.

I haven't found a good way to deal with this problem, seeing as how some fields (such as the B-vectors for DTI) are essential information and thus deleting/truncating with site-wide anonymisation makes the scans unusable.

[Charlie Moore]

Hi there,

For your use case, do you actually need the b-values extracted to the session XML? I agree the bug should be fixed, but in the short term, it may be possible to override the default session builders in a plugin to not extract the field at all.

Thanks,

Charlie Moore

[Tim Rosenow]

Firstly, sorry if my message came across as complaining - I know we get a huge amount of benefit from XNAT with probably very little thanks from you guys!

Secondly, no we do not and that sounds like a very good solution to our problem that I hadn't considered. Thank you for the advice!

[Kate Alpert]

Hi, Tim,

Just to elaborate on Charlie's suggested workaround: you should be able to create a DICOMImageScanAttributes-extending class that is essentially identical to MRScanAttributes (but excludes the b-values or whichever fields are causing you issues - see attached for example), put that into an org.nrg.dcm.xnat package in a plugin, and avoid having to fork and customize core XNAT. Please test in a development environment before deploying to production. 

Best,

Kate

[Tim Rosenow]

Thank you that is perfect.

--
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/Qn-rroBtDzE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to xnat_discussi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/9cd0c686-be8c-4f6c-bc2b-fbff38ef3565n%40googlegroups.com.

[Tim Rosenow]

Thanks again for your help - this has solved the problem for this use case! Sorry to keep asking questions, but although this works perfectly, I don't actually understand XNAT knows to use the custom class I created over the default MRScanAttributes? I'm surprised I don't have to tell the import handler which class to use?

On Thu, 1 Jun 2023 at 22:45, Kate Alpert <katea...@flywheel.io> wrote:

--

[Rick Herrick]

The path for XNAT’s plugins folder is configured in a <PreResources> block in its context definition, which means the resources defined in there are searched before other standard resource paths for web applications:

<Resources>

    <PreResources className="org.apache.catalina.webresources.DirResourceSet" base="${xnat.home}/plugins" webAppMount="/WEB-INF/lib” />

</Resources>

This means that, if you create a class with the same package and name as an existing class in XNAT–such as, for example, org.nrg.dcm.xnat.MRScanAttributes–and put it in a jar in XNAT's plugins folder, that class definition essentially hides the original class definition.

In case you’re curious as to how MRScanAttributes gets associated with MR scan objects, that’s configured in the DICOMScanBuilder class.

Rick Herrick

Senior Software Developer

rickh...@flywheel.io

------ Original Message ------

From "Tim Rosenow" <tim.r...@gmail.com>

To xnat_di...@googlegroups.com

Date 6/2/23, 3:11:01 AM

Subject Re: [XNAT Discussion] Re: Future plans regarding DCM field length bug

You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xnat_discussi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/CAH0%3DAD%2BcP%2BMA8TSprdzS9PcZTyU6Ya4D%3Dst%3DOv_uhzRz8d%3Dodw%40mail.gmail.com.

[Rick Herrick]

Never mind, none of what I said is true 😂

This actually works by another mechanism for customizing behavior. The CustomMRScanAttributes class Kate included has the @Component annotation on it. XNAT scans that package–org.nrg.dcm.xnat–for components (which is why customizations need to be in that package) and creates instances of those components on start-up. The class DICOMSessionBuilder finds all of those instances and maps them to the appropriate session and scan types. That's how your customization is getting injected without any extra configuration.

[Tim Rosenow]

Haha!

But that makes sense, thank you for the clarification!

To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/075ebcf7-0dad-40bf-ad6e-ee223bece680n%40googlegroups.com.