OHIF viewer : Problems reading outputs of facemasking container

Chidi Ugonna

unread,

Sep 7, 2022, 5:23:17 PM9/7/22

to xnat_discussion

Hi,

I am running the facemasking container (mohanar/facemasking:v1.12) in XNAT 1.8.5 with the XNAT OHIF Viewer Plugin (3.3.0) and the containers plugin (3.2.0).

It appears to successfully deface the Dicoms creating a new DICOM folder in the resources folder.

However when I try to view these dicoms in the OHIF Viewer I get an error when I try to view the image involved:

The original Dicoms in DICOM_ORIG have an extension of .IMA and the new defaced Dicoms in DICOM have an extension of .dcm

I am not seeing much in the log files - it seems as if access.log, file_access.log and ohifviewer.log have changed. The only thing that looks interesting to my untrained eye is that in access.log it looks like a GET is being processed on the original IMA file.

Any help on this would be much appreciated

Thank you

Chidi

Simon Doran

unread,

Sep 8, 2022, 3:49:47 AM9/8/22

to xnat_discussion

Hi Chidi,

The OHIF viewer is a JavaScript app that runs on the client side, so the easiest way to check for errors is to open the Developer Tools console in your web browser. This should give you more of an idea of what is happening. Please let us know what you find.

That said, I already have my suspicions about what is going wrong. It's looking to me as if the defacing plugin has replaced the DICOM files in XNAT's session resource folder but forgotten to let the viewer know that it has done this! It needs to update the metadata needed by the viewer. I may be wrong, but from your access.log extracts, I'm guessing that the viewer is still looking for files in the old location and not finding them (because they are now in the parallel DICOM_ORIG directory).

If you have admin privileges, then as a first step, could you try the following.

1. Navigate to Administer -> Site Administration -> Miscellaneous -> View the Swagger Page

2. Scroll down to the ohif-viewer-api and expand the section and you should see something like this:

3. Click on the POST button next to /viewer/projects/{projectId} and then on the Try It Out button that appears. This will lead to a display like the following:
Screenshot 2022-09-08 at 08.43.35.png

Enter the experiment ID and project ID, then click on the Execute bar below. If all goes well, this should refresh the metadata and the viewer should perform correctly.

I'll get in touch with the people involved in the development of both the defacing tool and the OHIF plugin and hope that we can resolve this.

Best wishes,

Simon

Chidi Ugonna

unread,

Sep 8, 2022, 8:13:34 PM9/8/22

to xnat_discussion

Hi Simon,

Thank you for the quick response and the very helpful suggestions. I looked at the Developer tools console and the errors there seem to reflect the observations in the log i.e. that the original .IMA files are being sourced from the DICOM directory which now instead contains the defaced .dcm files.

I went ahead and refreshed the session metadata using the swagger link as you suggested but this did not seem to help. I looked in ohifviewer.log and noticed that it was generating session data for both the .IMA and .dcm file (Scan 7 was defaced) but it also generated a warning about the .dcm file having a "null or empty scan ID" - see below.

...

icr.etherj.dicom.impl.DefaultSeries
* Number: 7
* Modality: MR
* Description: Accelerated Sagittal MPRAGE (MSV21)
* Date: 20220426
* Time: 081026.677000
* Uid: 1.2.276.0.7230010.3.1.4.296485376.785.1662657387.11
* StudyUid: 1.3.12.2.1107.5.2.19.45424.30000022042022562057800000075
* InstanceList: 208 SOP instances
icr.etherj.dicom.impl.DefaultSeries
* Number: 7
* Modality: MR
* Description: Accelerated Sagittal MPRAGE (MSV21)
* Date: 20220426
* Time: 081026.677000
* Uid: 1.3.12.2.1107.5.2.19.45424.2022042608050814166713970.0.0.0
* StudyUid: 1.3.12.2.1107.5.2.19.45424.30000022042022562057800000075
* InstanceList: 208 SOP instances
icr.etherj.dicom.impl.DefaultSeries
* Number: 8
* Modality: MR
* Description: Sagittal 3D T2 SPACE (MSV21)
* Date: 20220426
* Time: 081524.453000
* Uid: 1.3.12.2.1107.5.2.19.45424.2022042608152326303316722.0.0.0
* StudyUid: 1.3.12.2.1107.5.2.19.45424.30000022042022562057800000075
* InstanceList: 208 SOP instances
icr.etherj.dicom.impl.DefaultSeries

...

2022-09-08 23:30:40,447 [http-nio-8080-exec-2] WARN org.nrg.xnatx.ohifviewer.inputcreator.CreateOhifViewerMetadata - Series UID 1.2.276.0.7230010.3.1.4.296485376.785.1662657387.11 has a null or empty scan ID
2022-09-08 23:30:41,273 [http-nio-8080-exec-2] INFO org.nrg.xnatx.ohifviewer.inputcreator.JsonMetadataHandler - Session XNAT_E00007 metadata created and stored
2022-09-08 23:30:41,273 [http-nio-8080-exec-2] INFO org.nrg.xnatx.ohifviewer.xapi.OhifViewerApi - Session XNAT_E00007 metadata creation complete

I also deleted the DICOM_ORIG folder and generated the metadata again just to see what would happen and I still got the warning message above.

Let me know if there is anything else I can look at to help with this.

Thanks again for your help

Chidi

roman....@gmail.com

unread,

Jun 1, 2023, 11:13:42 AM6/1/23

to xnat_discussion

Hi

I have used the same container and obviously I am running into the same issue. Were you able to find a solution to this problem?

Best regards,

Sandro

Chidi Ugonna

unread,

Jun 1, 2023, 1:48:36 PM6/1/23

to xnat_discussion

Hi Sandro,

I think I found out what was causing the issue but didn't get round to implementing a solution yet as I was still wondering what an ideal approach would be and in the meantime other things took priority. This might bubble up the priority list later on this year. If so and I get this working I will share here. In the meantime, the problem seems to be the UID values in the following DICOM tags

(0008,0018) SOP Instance UID - unique for each dicom file
(0020,000D) Study Instance UID - unique for each session/study
(0020,000E) Series Instance UID - unique for each scan

I think that 0008,0018 and 0020, 000E are fine but that the issue is 0020,000D ; this latter DICOM tag should be equal to the UID that is stored in the MR Session which if you are using the XNATPy API will be retrieved something like "connection,project[PROJ].experiments[EXP].uid" but in the defaced DICOMS this value is different.

One would need to change this UID which could be a little involved and entail downloading the dicoms, changing the UIDS and reuploading them to the XNAT.. The pydicom library is a good one for this. Another worfkflow to consider is to run the defacing on another XNAT and possibly use XSYNC to push to the production XNAT.

Cheers

Chidi

Charlie Moore

unread,

Jun 1, 2023, 2:21:01 PM6/1/23

to xnat_discussion

Hi there,

It sounds like the facemasking container is changing the UIDs of the DICOM it's modifying. I would argue that's actually appropriate, although it's probably also changing both the SOP Instance UIDs and Series Instance UIDs as well. This leads to a weird scenario where one XNAT session is going to have 2 DICOM Study Instance UIDs with the original UIDs in the instances in DICOM_ORIG, which is a bit of a nonstandard scenario. This is going to cause all sorts of issues where:

1. As you've noted, the Study Instance UID stored in XNAT no longer matches the files, which the OHIF viewer depends on. But even beyond that...

2. I'm pretty sure the OHIF viewer is going to depend on the Series Instance UIDs and SOP Instance UIDs being the original values as well as the viewer caches its metadata and this will be out of date.

I would think the solution wouldn't be to try to reinsert the original UIDs, but rather:

1. Update the UID parameter in XNAT with REST. The Series Instance UIDs are likewise stored at the scan level in XNAT and would presumably need to be updated as well.

2. Purge the cached metadata for the study for the OHIF viewer.

IMO all of that is something that could be done by the facemasking container, but I'm not sure to what degree that container is maintained or supported.

Thanks,

Charlie Moore

Simon Doran

unread,

Jun 2, 2023, 4:23:49 AM6/2/23

to xnat_discussion

Hi Chidi and Sandro,

Apologies if I sound opinionated below, but I think that there are some serious issues raised here.

To be honest, the whole scenario here seems like an accident waiting to happen. Mucking around with DICOM UIDs is not a good idea generally and vastly increases the complexity of auditing studies. Golden rule: one XNAT session = one DICOM StudyInstanceUID. XNAT's prearchive rightly flags up issues when this is not the case if one imports data into XNAT via the DICOM receiver. Just because the images are created "within" XNAT via a container and placed directly in the archive, doesn't mean we should be treating them differently. Whenever we have locally attempted to violate this and merge more than one StudyInstanceUID into a single session, it has not ended well.

There are two solutions here:

1. I think that the cleanest all round is to have the defacing container create a completely new XNAT session for the same subject. Just name the new session something like <ORIGINAL_SESSION_NAME>_defaced. I can't remember whether adding a session via the container services will automatically trigger a call to the JSON generation for the viewer, but if it doesn't then you may need to use the REST API call I pointed to above.

Once you have it in a different session, the viewer will handle everything just fine. You can display all imaging sessions for a patient. The sidebar will give you expander boxes for each session and you can drag the images you want next to each other in the viewer. Job done.

This has the added advantage that you can share the newly created session with another project where only the defaced images are seen.

2. Have the defacing container create additional defaced images and add them to the original session, but with the same StudyInstanceUID and completely new SOPInstanceUIDs. This leaves the original images intact, which is what you need for auditing purposes. In this scenario, you will definitely need to make a call, as above, to regenerate the session JSON for the viewer. This situation is very close to what happens when an MR scanner performs a "retrospective recon" and sends a set of reconstructed images to XNAT, which may arrive later than the originals, meaning that the original session has already been finalised in XNAT before they reach the prearchive.

In your case, you might need to think carefully about what date you insert into the DICOM files for the defaced images. Personally, I'm not a massive fan of having an XNAT session containing DICOM files with two different dates, but I don't worry about this quite as much as having different SeriesInstanceUIDs.

Best wishes,

Simon

Chidi Ugonna

unread,

Jun 3, 2023, 2:55:45 PM6/3/23

to xnat_discussion

Hi Simon, Charlie

Thank you for the very helpful input. I am not sure I have a use case yet that involves the defacing container but your insightful comments will certainly make a huge difference to the way that this is approached. I completely agree with both your views and concur that any solution has to be well thought through and sustainable.

All the best

Chidi

Simon Doran

unread,

Jun 3, 2023, 8:38:11 PM6/3/23

to xnat_discussion

Correction: The last word in my previous response should read "StudyInstanceUIDs".

Reply all

Reply to author

Forward