Issue with segmentation visualization in XNAT Viewer

[JHOAN SEBASTIAN MORA COLORADO]

Hello everyone,

I hope you are all doing well. I wanted to share an issue I have been facing recently with XNAT Viewer and I'm hoping someone might be able to offer some guidance on it.

The problem is as follows: When I perform a segmentation in XNAT Viewer, the result is saved as a DICOM format ROI mask. Recently, I have been trying to visualize a segmentation that I initially had done in NIfTI format, so I converted this file to DICOM format in order to view it in XNAT Viewer.

However, when I enter the viewer, I can only see the initial segmentation I made, i.e., the ROI mask. The segmentation converted to DICOM format does not appear in the viewer.

Has anyone encountered a similar issue before or has any ideas on how I might be able to resolve this? Any guidance or advice would be greatly appreciated.

Thank you in advance for your help

"La información aquí contenida es para uso exclusivo de la persona o entidad de destino. Está estrictamente prohibida su utilización, copia, descarga, distribución, modificación y/o reproducción total o parcial, sin el permiso expreso de Universidad de Antioquia, pues su contenido puede ser de carácter confidencial y/o contener material privilegiado. Si usted recibió esta información por error, por favor contacte en forma inmediata a quien la envió y borre este material de su computador. Universidad de Antioquia no es responsable por la información contenida en esta comunicación, el directo responsable es quien la firma o el autor de la misma."

UdeA

[akluiber]

How are you converting from nifti to dicom-seg? I use the guide and tools from here: https://qiicr.gitbook.io/dcmqi-guide/opening/cmd_tools/seg/itkimage2segimage, or the pydicom-seg python library, which fundamentally is using the same tools from qiicr (https://razorx89.github.io/pydicom-seg/guides/write.html). I do find that the conversion process is sometimes finicky with respect to requiring certain headers that are often removed from anonymized files (like ReferringPhysicianName, AccessionNumber, PatientBirthDate, etc.) having a good FrameOfReferenceUID and PositionReferenceIndicator set, etc.

Finally, how are you sending that file back into XNAT? It needs to be uploaded as an ROI to the session. i.e. the curl statement below:

curl -b JSESSIONID=${JSESSIONID} -X PUT -T "/path/to/my-segmentation.dcm" "https://my.xnathost.com/xapi/roi/projects/SOMEPROJECT/sessions/XNAT_E123456/collections/my-segmentation?type=SEG"

Hope this is helpful.

[Simon Doran]

Hi Jhoan,

  Thanks to akluiber for getting in first with the reply here. Given that this question pops up quite regularly, it's probably worthwhile flagging up the previous posts that the viewer development team have previously written.

  Here's the thread that discusses the method above described by akluiber.

  This thread from 2021 discusses the reasons why direct support for NIfTI is not yet provided in the XNAT OHIF viewer. Some of arguments might have shifted a little and there have been a few developments, but our core position remains the same, namely that the risk of overlaying ROIs incorrectly (either on the wrong base image, or inverted spatially) is increased when using NIfTI compared with DICOM. Looking, for example, at the way IDC stores annotations (e.g., for the image segmentations produced by BAMF under the AIMI Annotations initiative), it appears that other repository platforms also advocate staying DICOM-focused. Requiring users to create the DICOM files as above forces the data creators explicitly to insert the relevant linkage information into their images the form of matching DICOM UIDs and thus devolves responsibility for this task back to where it should be, rather than having XNAT "guess" which images should be overlaid on what.

  That said, we are very open to more widespread discussion about these issues. If there is a groundswell of opinion to support direct display of NIfTI both for base images and overlays/segmentations, then we would like to hear your views on how best to import the data - potentially, we could create a specific REST-API that incorporated a formal specification of how to associate files and then perform appropriate validation of incoming data.

  Best wishes,

Simon

[JHOAN SEBASTIAN MORA COLORADO]

Thanks so much akluiber and Simon for the information

[Simon Doran]

On a related note, the proposed DICOM Supplement 243 introduces a new label map IOD for label map segmentations that should alleviate other concerns re the use of a fully DICOM workflow and reduce the need for NIfTI. See https://www.dicomstandard.org/comment for more details at to register any comments.