Just an observation re: Osimis Viewer vs. Stone Viewer and then a question about the Stone Viewer

I have development and production versions of Orthanc / RIS pairs that I’m using for development, and I’ve occasionally noticed something peculiar about the behavior of the Osimis Viewer vs. the Stone Viewer on the development server. I think this might be explained by the way that they fetch study data. Osimis uses the “ID” that orthanc uses for the study: e.g. 5ccfcee7-c4e1f3cd-375c9087-e096dcb8-7b635b0c, whereas Stone uses Dicom Web and the StudyInstanceUID.

What I’ve noticed is that in some instances the Osimis viewer suddenly breaks when I’m developing code to modify studies and otherwise manipulate dicom tags while writing Python Plug-in scripts. Pretty sure that might be related to having 2 or more studies with the same StudyInstanceUID on the development Orthanc Instance. I know you should never do that, but I do sometimes in development just to see what happens. In fact, if I delete all but 1, then I think the Osimis viewer works again. Stone does not exhibit the same behavior, but I never really checked or noticed if Stone actually displayed all of the images for both studies when there are 2 or more with the same StudyInstanceUID, i.e. sort of like a merge in the viewer.

I know that the Osimis viewer is deprecated, but it is actually kind of useful now in a dev environment because if it breaks, you probably have some issues with Dicom Tags.

Just an observation. We have our own root ID’s, so it is not hard to generate a new one, and could / should probably make one that has a number in one of the dot sequences indicating it was modified by PACS for some reason.

There was a previous post indicating that in a future release there would be a config option to allow the use of one’s own root ID’s, which would be nice, so wondering how that is coming along.

Finally, I’ve heard that it may be a regulatory requirement in some jurisdictions to display, or least tag a study, with some identifying information for the technician who operated the equipment that acquired a study, either in the OperatorsName tag or in the ImageComments Tag, not sure which one. I don’t think the Stone Viewer supports doing that yet, and probably on the RoadMap ? The ability put something in the stone.json config to specify a set of annotations to display and where in the viewer ?

Thanks.

I have development and production versions of Orthanc / RIS pairs that I’m using for development, and I’ve occasionally noticed something peculiar about the behavior of the Osimis Viewer vs. the Stone Viewer on the development server. I think this might be explained by the way that they fetch study data. Osimis uses the “ID” that orthanc uses for the study: e.g. 5ccfcee7-c4e1f3cd-375c9087-e096dcb8-7b635b0c, whereas Stone uses Dicom Web and the StudyInstanceUID.

What I’ve noticed is that in some instances the Osimis viewer suddenly breaks when I’m developing code to modify studies and otherwise manipulate dicom tags while writing Python Plug-in scripts. Pretty sure that might be related to having 2 or more studies with the same StudyInstanceUID on the development Orthanc Instance. I know you should never do that, but I do sometimes in development just to see what happens. In fact, if I delete all but 1, then I think the Osimis viewer works again. Stone does not exhibit the same behavior, but I never really checked or noticed if Stone actually displayed all of the images for both studies when there are 2 or more with the same StudyInstanceUID, i.e. sort of like a merge in the viewer.

I know that the Osimis viewer is deprecated, but it is actually kind of useful now in a dev environment because if it breaks, you probably have some issues with Dicom Tags.

As you indicated, Osimis Web viewer is now deprecated and essentially unmaintained, so you should move to Stone Web viewer. Here are the explanations for this migration:
https://hg.orthanc-server.com/orthanc-stone/file/StoneWebViewer-2.1/Applications/StoneWebViewer/NOTES.txt

Anyway, you should provide a full minimal working example (sample DICOM images + instructions to open the Osimis Web viewer) for other people to be able to reproduce your problems:
https://book.orthanc-server.com/users/support.html#discussing-a-minimal-working-example

Just an observation. We have our own root ID’s, so it is not hard to generate a new one, and could / should probably make one that has a number in one of the dot sequences indicating it was modified by PACS for some reason.

There was a previous post indicating that in a future release there would be a config option to allow the use of one’s own root ID’s, which would be nice, so wondering how that is coming along.

This is clearly an enterprise feature, for which we are looking for financial funding from the industry in order to develop it.

Finally, I’ve heard that it may be a regulatory requirement in some jurisdictions to display, or least tag a study, with some identifying information for the technician who operated the equipment that acquired a study, either in the OperatorsName tag or in the ImageComments Tag, not sure which one. I don’t think the Stone Viewer supports doing that yet, and probably on the RoadMap ? The ability put something in the stone.json config to specify a set of annotations to display and where in the viewer ?

Again, regulatory requirements are not universal. The Orthanc free and open-source project doesn’t have access to the required legal advice, neither to the funding from the industry that is necessary to comply with all the local regulations. The Osimis Web viewer was once “CE class I” certified by Osimis, but Osimis didn’t gather enough people willing to pay to support such a certification in the long-term, to our great disappointment.

Regarding annotations, OsiriX annotations can be displayed in the Stone Web viewer (cf. the “NOTES.txt” file above). Line/angle/circle annotations are also already implemented in the Stone Web viewer, but not in a persistent way, for which we are once again looking for financial contributions from the industry:
Contributing to Orthanc — Orthanc Book documentation (cf. “Save/load annotations” item)

Sébastien-