Osimis WebViewer, stored key images are incomplete and cannot be loaded by 3rd party DIOCM viewer

Hi,

we are playing around with the new Osimis WebViewer on MacOS (we use Orthanc 1.3.1 and the currently offered plugin version 1.0.0.146-2022ccd.

Taking a key image works, i.e. it creates a new Series with one Instance but most of the tags of the original Instance are missing.
I understand that the modality tag is overwritten with KO (key object) but I don’t understand why other tags are not taken over.

This is problematic if one wants to load such a key image with another DICOM viewer.
I have tested with Osirix 8 MD and it fails on Move-SCU of these key images (non key instances work)
Error message: “Failed, unable to process”.

Orthanc Log file says:

W0905 19:47:17.646110 OrthancMoveRequestHandler.cpp:179] Move-SCU request received for AET “OsirixTS”
E0905 19:47:17.654486 MoveScp.cpp:221] IMoveRequestHandler Failed: DicomUserConnection: Unable to find the SOP class and instance

For me it looks like a bug in the key image function of Osimis WebViewer.

regards
Torsten

btw, I cannot see how to activate the “synchonized browsing” feature.
Should there be an icon/control to activate that or does it become automatically active if two or more corresponding Series are loaded and visualized side-by-side?

Hello,

You are using an outdated version of Orthanc (current release is 1.4.1, soon 1.4.2 will be released), as well an outdated version of the Osimis Web viewer (currently at version 1.1.2). Should you first upgrade.

Your question is unclear to me: Are you sending images from OsiriX to Orthanc, or are you sending images from Orthanc to OsiriX? In either case, from what I understand, it looks like an issue with the DICOM protocol, which has nothing to do with the Osimis Web viewer.

You should give a try by setting “UnknownSopClassAccepted” to “true” in the configuration file of Orthanc:
http://book.orthanc-server.com/users/configuration.html

Regarding “synchronized browsing”, the Osimis Web viewer will by default synchronize series whose slices are parallel to each other. This topic is currently being discussed in another thread on this forum:

https://groups.google.com/d/msg/orthanc-users/kHyS3JbORYs/FTd0s582FAAJ

Regards,
Sébastien-

I have installed the latest stable version MacOS from here http://www.osimis.io/en/download.html (seems to be outdated then)
For 1.1.2 I have to build from source or is there another place to download 1.1.2 binaries?

I have created with the KeyImage function of the Osimis WebViewer - it stores in Orthanc.
Then I use Osirix to retrieve from Orthanc via C-MOVE

Some more information after further tests:

I have now upgraded to Osimis WebViewer 1.1.2.0-e036960e
Orthanc is still 1.3.2 because MongoDB storage plug-in is not completed yet for 1.4.1
UnknownSopClassAccepted was set to true as recommended

The error is still the same:

It is possible to show the key image via Orthanc Explorer and Osimis WebViewer.
Osirix can load normal DICOM files from the same Study but not the Series with key images made via Osimis WebViewer.
Error message in Osirix when I try to C-MOVE (Failed: UnableToProcess)

Orthanc Log says

Sep 10 10:53:17 CIPRCS orthanc: W0910 10:53:17.069402 OrthancMoveRequestHandler.cpp:179] Move-SCU request received for AET “OsirixTS”
Sep 10 10:53:17 CIPRCS orthanc: E0910 10:53:17.203977 MoveScp.cpp:221] IMoveRequestHandler Failed: DicomUserConnection: Unable to find the SOP class and instance

If I check the tags of the key image (all tags listed below as shown by Orthanc Explorer) I see that most of the tags of the original instance are missing here.
The comment that one can enter on making the key image is also not set in the tag 7331,1000 (OsimisNote): Null

  • 0002,0003 (MediaStorageSOPInstanceUID): 1.2.276.0.7230010.3.1.4.8323328.2426.1536568846.76460

  • 0008,0005 (SpecificCharacterSet): ISO_IR 100

  • 0008,0012 (InstanceCreationDate): 20180910

  • 0008,0013 (InstanceCreationTime): 084046.000000

  • 0008,0018 (SOPInstanceUID): 1.2.276.0.7230010.3.1.4.8323328.2426.1536568846.76460

  • 0008,0020 (StudyDate): 20170405

  • 0008,0021 (SeriesDate): 20180910

  • 0008,0022 (AcquisitionDate): 20180910

  • 0008,0023 (ContentDate): 20180910

  • 0008,0030 (StudyTime): 121506

  • 0008,0031 (SeriesTime): 084046.000000

  • 0008,0032 (AcquisitionTime): 084046.000000

  • 0008,0033 (ContentTime): 084046.000000

  • 0008,0050 (AccessionNumber): U-ID6867499

  • 0008,0060 (Modality): KO

Hi Torsten,

Indeed, I confirm that there’s a bug in the generation of the secondary captures and they can not be move to another DICOM destination.
I’m writing it down in our issue list and will try to fix it in a next release.

Concerning the OsimisNote that is not displayed, this is actually the case with all “private” tags. The only way to get the value is through this url: http://localhost:8042/instances/…/content/7331,1000

Br

Alain

Thanks Alain for confirmation.

Would be good if this gets solved because one of these corrupt files within Orthanc makes the whole system more or less unusable if queried from a 3rd party DICOM Viewer.
We will disable the secondary capture feature until it is fixed (so that such files cannot be accidentally produced by users).

br
Torsten

Hi Alain,

just a quick question in this context:

When the user creates key image of an instance via Osiris WebViewer the modality tag is set to “KO” and we get a new tag MediaStorageSOPInstanceUID and

MediaStorageSOPInstanceUID === SOPInstanceUID

So, we have a clear indication, that this instance is the result of a secondary capture.

When we then modify the same instance using Orthanc REST API POST /instances/${instance.ID}/modify and POST the output of this to URL POST to create a new instance we do not get “MediaStorageSOPInstanceUID”, i.e. the tag is “magically” removed by Orthanc.

This behavior is good for us as it allows to have a clear indication in the tags that the new instance is the immediate result of the secondary capture and not the result of a modified instance (as described above).

My question is, whether this behavior will remain the same after you have fixed the tag handling? If yes, we can work with this.

thanks in advance

Torsten