OHIF v3.7 NIFTI support and Resource folder support

[Ajay Kurani]

Hi XNAT Experts,

   I had 2 questions regarding the OHIF v3.7 plugin.

1) From what I read I see in the general OHIF software there is NIFTI support.  I wanted to see if this is also in the XNAT version and if so is it solely masks or opening up any NIFTI image such as T1 images, output results etc?

2) Right now we can only see the scan folder when opening up the viewer.  However, If results are stored in resources section as a folder (e.g. Freesurfer or MRIQC), is there a way to traverse the folder structure from the viewer to resources?  If not, is there an optional way to get to this folder from the GUI?  Finally, if no, is this a feature that is on the roadmap?

Thanks,

Ajay

[Simon Doran]

Dear Ajay,

  There have been several queries around NIFTI support in the XNAT viewer (most recently here), and it's worth reposting why we don't currently provide this support out-of-the-box.

  I discussed the problem in some detail back in 2021 and commented again on the dangers of non-mandatory NIFTI metadata here. I ended my 2021 post with a request for feedback on how we should best take this question forward as a community. I'd be more than happy to discuss ideas for the future, but we need the debate to be deeper than simply "the XNAT-OHIF viewer should display NIFTI".

  If the research need is simply "I want to be able to view a NIFTI file", then the straightforward answer is: "download the file and use ITK-Snap". On the other hand, if the research need is to view the NIFTI file in the context of the rest of the images acquired in this session, then we need to be concerned with metadata and proper archival. There are also valuable questions to discuss related to the way XNAT itself is being used. If XNAT is being employed as a convenience tool to help gather together images in an ad hoc way for managing a small project for an individual or small group of users, this is very different from the situation of running a major imaging archive where images may be shared between multiple research groups from different institutions. Arguably, we should support both paradigms. One possibility is a separate pane for displaying NIFTI images or a separate viewport type that makes it very clear that the spatial relationships between these data and the DICOM data are not guaranteed.

  The lowest hanging fruit is probably how to support BIDS-compliant NIFTI and this might be a starting point for future work.

  With regard to how to store segmentation masks, a very common workflow is the following:

1. Store original DICOM data in XNAT.

2. Manipulate those data (e.g., downsample for machine learning; "stitch together" data from multiple MR imaging stations into a whole-body volume; register multiple datasets into a common coordinate system) and create NIFTI output in the form of a new "base image".

3. Create some segmentations, either manually or automatically.

  When you finish point 3, you have a couple of NIFTI files that have lost all relationship (in terms of provenance or metadata in the NIFTI files) with the original data from which they were derived. What then? How do you share them with colleagues in a way that makes sense, without having to write additional "sidecar" descriptions.

  We have a had a lot of success in turning the NIFTI files back into DICOM for archival purposes. (Note that there are many good reasons not to use DICOM for intermediate processing steps.) If you know where the original DICOM sources are, you can build all the important metadata and linkages back into the DICOM metadata. A suitable starting point for this was discussed here.

  Please do comment, everybody, I'd really like to know people's views on this subject.

  Best wishes,

Simon

[Simon Doran]

P.S. Mo Al S'ad (the main coder for the OHIF viewer plugin) and I discussed this issue yesterday. We have a plausible strategy for how to introduce the necessary changes, but this is not a funded item on our viewer development roadmap at the current time. If any user or group would like to see this issue prioritised and has appropriate funding to allocate to this task for the code to be released open-source, then please do reach out to me by email.

[Ajay Kurani]

Hi Simon,

   I wanted to give you more context in order to facilitate this conversation.  The segmentation was just an example with PET data if we use the contour/mask function, but really that isn't the main usecase.

Right now we have a fully functional XNAT instance that is integrated into an HPC environment.  This XNAT instance is being used for both raw dicom storage (which works perfect with OHIF) and storage of processed data which is stored as a RESOURCE instead of under SCAN and currently does not work with OHIF.  All pipelines we are running are BIDS compatible and outputs are stored as follows for examples of mriqc and freesurfer:

sub001 (subject label), sub001MRI1 (session label) on XNAT

SCANS

...

RESOURCES

-->mriqc    (This is a main folder for all mriqc pipeline runs for a given subject/session in XNAT)

  --->mriqc_run1 (This folder is what is considered derivatives in full BIDS structure)

    ---->sub-001

      ------>figures

        -------->files

      ------>ses-001MR1

        -------->anat

           -------->files

  --->mriqc_run2 (This folder is what is considered derivatives in full BIDS structure)

    ---->sub-001

      ------>figures

        -------->files

      ------>ses-001MR1

        -------->anat

           -------->files

-->freesurfer    (This is a main folder for all mriqc pipeline runs for a given subject/session in XNAT)

  --->fs_run1 (This folder is what is considered derivatives in full BIDS structure)

    ---->sub-001

      ------>ses-001MR1

          ------>mri

            -------->files

          ------>label

            -------->files

          ------>touch

            -------->files

          ------>stats

            -------->files

          ------>surf

            -------->files

          ------>scripts

            -------->files

  --->fs_run2 (This folder is what is considered derivatives in full BIDS structure)

      ------>ses-001MR1

          ------>mri

            -------->files

          ------>label

            -------->files

          ------>touch

            -------->files

          ------>stats

            -------->files

          ------>surf

            -------->files

          ------>scripts

            -------->files

As you can see for each pipeline like mriqc we have 1 to several results (mriqc_run1 and mriqc_run2) if pipeline was run on the same session with different options and not overwritten.  We are running pipelines on datasets ranging from small studies to large opensource datasets such as ADNI.  We would like to be able to view these individual pipeline outputs (e.g. mriqc_run1) that are mostly in NIFTI format without downloading files as the goal is to minimize downloading of datasets and try to have as many QC workflows within XNAT using OHIF.  We would not want to get these registered to the original dicoms as they have been transformed etc,, just viewing in the context of each output folders (e.g. mriqc_run1, mriqc_run2, fs_run1, fs_run2).

The goal is to view outputs of pipelines without the need to download if there is native NIFTI support incorporated OHIF and the ability to traverse to the Resource folder section (as currently I think only scans are updated).  I appreciate your feedback if such a set up would avoid the issues you previously mentioned since we use BIDS formatting on outputs of pipelines. 

Best,

Ajay

--
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/k5GkibWdDKc/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/29710ae9-e3ac-4c71-8e9a-1ba6d9b69333n%40googlegroups.com.

[Simon Doran]

Hi Ajay,

  Thanks for the clarification. Please could you provide details/examples showing how to determine which NIFTI file should be displayed on top of each of the MRI "base" images. At the moment, it's not obvious from your hierarchy how the viewer would discover this in a way that generalises across different applications (i.e., Freesurfer is not the only software out there producing NIFTI output).

  Best wishes,

Simon 

[Simon Doran]

Sorry, I should have said "i.e., MRIQC is not the only software producing NIFTI output", given that this was what featured in Ajay's previous post, and noted that Freesurfer had also been mentioned above. These are just two examples and it is by no means clear that all will have the same file structure for the resources folder. As ever, it is not the task of displaying the NIFTI that is difficult, but rather the challenge of determining which NIFTIs are appropriate to display together that works in the general case, without creating complex additional UI to make the user choose each time. The linkages present in DICOM files (but lacking in NIFTI) make this straighforward, but there is no mandatory mechanism for including this in NIFTI. 

[Tim Rosenow]

I would be interested in this feature should it exist, although it's not a huge priority for me.

As a starting point, you could just have a UI similar to the ones present in the Contours, Masks, and Measurements - you are presented with a list of niftis in the resource folder and you just click on them to add them, or drag them to the designated box in the layout, or whatever (not sure if people are wanting an overlay or just a side-by-side comparison). There is the risk that the processing in some way alters the image such that the metadata embedded in the DICOM is no longer appropriate to the new nifti image, which could make viewing awkward (stretching/zooming in one or more axes, loss/corruption of qform transformation, wrong orientations, etc), but I also think that it is the responsibility of the person creating and running these analyses to be aware of. 

An alternative way to look at this problem is to consider making a new datatype and call it something like "viewable NIFTI" or something. Make the minimum metadata requirements part of the datatype specification (and mandatory), and have the OHIF viewer load all DICOMS and also any of these viewable NIFTIs in its list of things to open.

[Simon Doran]

Thanks, Tim. That's very useful feedback.

Best wishes,

Simon

[Ajay Kurani]

Hi Simon and Tim,

    Apologies for the delay in getting back to you.  I do agree with Tim I think we are interested in letting the user pick which NIFTI to load from the pointed resource folder.  Sometimes we want to see if the alignment is better with cost functions A, B, or C when developing pipelines, sometimes it is viewing MNI warp as it compares to the template or loading our ROI against the subject level brain.  When dealing with so many use cases I think we need the flexibility to pick any two images and display.  I do think we need to be aware that different pipelines write to the sform and qform when processing data so maybe also having a button that pulls the affine matrix from one or the other.  We should have this button independent for overlay/underlay or if multiple boxes are being utilized then each window has its own button, which will allow for most flexibility.  Happy to discuss more in detail if you would like.

Best,

Ajay   

[Ajay Kurani]

Hi Simon,

    In looking at the Legacy viewer it only lets you navigate the Scan directory and subfolders.  I think being able to navigate both the SCAN folder/subfolders (as it may be a nifti at this level) as well as the RESOURCE folder/Subfolders (regardless of nesting level) gives the most flexibility.  As seen in MRIQC example and some of these other pipelines even though the top level in resources is the MRIQC folder (what is found in the database), the image you want to display may be in a subfolder that isn't "cataloged" in the traditional sense when stored under RESOURCE.  I am not sure if it is feasible or not to traverse in order to display correctly.  If not, we could potentially symlink all nested images to a NIFTI_VIEW folder at the top level of MRIQC folder when creating outputs to consolidate where to traverse (or something along these lines).  Just food for thought but happy to discuss further.

Best,

Ajay

[Simon Doran]

Hi Ajay,

  Thanks for getting back to me. There have been some very good ideas on this thread so far. I think that the way to take this forward now should be to create a proper survey and canvass the opinions of the widest possible range of XNAT users. If we can:

(a) demonstrate community demand;

(b) find out what features the majority of people want;

(c) develop some user stories

(d) ascertain whether anyone has the appetite to contribute to funding such a development

then we will a clear mandate to apply for grant funding for all or part of the work needed.

  Best wishes,

Simon