Is this an optimal orthanc setup?

version: “3.3”

services:
orthanc:
image: osimis/orthanc:22.5.2
ports: [ 8042:8042 ]
environment:

  • ORTHANC__AWS_S3_STORAGE__BUCKET_NAME=
  • ORTHANC__AWS_S3_STORAGE__REGION=ap-south-1
  • ORTHANC__AWS_S3_STORAGE__ACCESS_KEY=

- STONE_WEB_VIEWER_PLUGIN_ENABLED=true

  • DICOM_WEB_PLUGIN_ENABLED=true

- ORTHANC__DICOM_WEB__STUDIES_METADATA=Extrapolate

- ORTHANC__DICOM_WEB__SERIES_METADATA=Extrapolate

- ORTHANC__DICOM_WEB__STUDIES_METADATA_EXTRAPOLATED_TAGS=[“AcquisitionDate”]

- ORTHANC__DICOM_WEB__SERIES_METADATA_EXTRAPOLATED_TAGS=[“BitsAllocated”,“BitsStored”,“Columns”,“HighBit”,“PhotometricInterpretation”, “PixelSpacing”, “PlanarConfiguration”, “RescaleIntercept”, “RescaleSlope”, “Rows”, “SOPClassUID”, “SamplesPerPixel”, “SliceThickness” ]

  • ORTHANC__EXTRA_MAIN_DICOM_TAGS__INSTANCE=[“Rows”, “Columns”, “ImageType”, “SOPClassUID”, “ContentDate”, “ContentTime”, “FrameOfReferenceUID”, “PixelSpacing”, “SpecificCharacterSet”, “BitsAllocated”, “BitsStored”]
  • ORTHANC__EXTRA_MAIN_DICOM_TAGS__SERIES=[“TimezoneOffsetFromUTC”, “PerformedProcedureStepStartDate”, “PerformedProcedureStepStartTime”, “00400275”]
  • ORTHANC__EXTRA_MAIN_DICOM_TAGS__STUDY=[“TimezoneOffsetFromUTC”]
  • ORTHANC__EXTRA_MAIN_DICOM_TAGS__PATIENT=[]
  • ORTHANC__DICOM_SERVER_ENABLED=false
  • ORTHANC__AUTHENTICATION_ENABLED=true

volumes:

  • ./config/orthanc.json:/etc/orthanc/orthanc.json:ro
  • ./volumes/orthanc-db/:/var/lib/orthanc/db/
    secrets:
  • ORTHANC__AWS_S3_STORAGE__SECRET_KEY
  • ORTHANC__DICOM_WEB__SERVERS
  • ORTHANC__REGISTERED_USERS

secrets:
ORTHANC__AWS_S3_STORAGE__SECRET_KEY:
file: config/aws-s3-secret-key.txt
ORTHANC__DICOM_WEB__SERVERS:
file: config/dicom-web.txt
ORTHANC__REGISTERED_USERS:
file: config/users.txt

This is my docker-compose setup for orthanc and I have just now tried out the newest extraMainDicomTags option, which by the way, has been extremely good. Kudos, to the orthanc team on a job very well done. I was wondering if this is an optimal setup because for some reason even after specifiying tag 00400275, Orthanc is showing me this as an error :
Accessing Dicom tags from storage when accessing series : 0040,0275.
I am using object storage and it has been slow to fetch from dicomweb this has definitely helped a lot but there still seems to be some problem with the speed, Is it maybe something I have done that’s wrong?

Your setup looks quite good !

Note that you should write 0040,0275 instead of 00400275.
But right now, Orthanc is unable to store a tag that is a sequence so you’ll get a warning anyway:
0040,0275 can not be added in the Extra Main Dicom Tags since it is a sequence

Note that this tag is requested at series level by your dicom-web client so Orthanc will need to open a single file per series to extract it (and not a file for each instance) so the impact on the speed should not be that big.

HTH

Alain

Hi Alain,
Thanks for the quick reply, I did come to understand that its trying to extract per series and not per instance thanks to you. I was wondering if anything in this setup might have caused it? Which doesn’t seem likely, because i just tried the same setup without persistent storage yesterday and it worked quite fast. However, this is still a great improvement for object storage retrieval, I’ve been waiting for this for a while now so once again I really appreciate everything you guys do. If you think I can do more to improve speed I would love suggesions.
Thank you

Hi Shravan,

Not much you can do I think. I’ve added a TODO to support Sequences storage in DB but I can’t commit on when it will be implemented.

Best regards,

Alain

Hi,

Note that I have implemented support of sequences in ExtraMainDicomTags which should then solve your issue. (https://hg.orthanc-server.com/orthanc/rev/877bc3b96476).

This will “soon” be released in Orthanc 1.11.1

Best regards,

Alain.

Hi Alain,
I just tried out the new update and it is incredible. Kudos to the entire team of orthanc for this, this has been a major update and its worked wonders for me. I also just wanted to clarify if there is a way i can group the uploads in S3 inside folders which are named after the study instance uid?
Thank you for such quick replies,
Shravan,

Hi Shravan,

No, it is currently not possible to control the naming of files in any of the Storage plugins. I hope to be able to provide that option in the mid-term future.

Best regards,

Alain.

I started to implement some of this stuff on my development setup.

I have this, I am using a .env file,.

ORTHANC__DICOM_WEB__STUDIES_METADATA=“MainDicomTags”

ORTHANC__DICOM_WEB__SERIES_METADATA=“Full”

and it seems to work, but if i set the ORTHANC__DICOM_WEB__STUDIES_METADATA to MainDicomTags or Extrapolate it causes an error:

Exception on “callable:” Not implemented yet, in the Exception in the Dev Tools Console ?

I am using the osimis/orthanc:22.6.4 Docker image as a base.

The solution was to implement the changes mentioned here:

https://book.orthanc-server.com/plugins/housekeeper.html#housekeeper-plugin

and here:

https://book.orthanc-server.com/plugins/dicomweb.html?highlight=dicomweb#fine-tuning-server-for-wado-rs-retrieve-metadata

The Housekeeper apparently automatically updated the DB, but I have very studies on my dev server. Any idea how long that will take with a few thousand studies ?

This is a very nice addition now that I’ve checked it out !

Also, I asked a question eariler about making some tags available to the StoneViewer, see https://groups.google.com/g/orthanc-users/c/yfCqYetQSJM, mostly because I’d like to be able to add more annotations on the view panes in the Stone Viewer. e.g. Most viewers show Ant, Posterior, Left, Right and quite a few other annotations on the viewer, like the OperatorsName, ImageComments, ImageOrientationPatient, ImagePositionPatient. It seems that all of the metadata is returned in the:

https://localhost:8042/dicom-web/studies/StudyInstanceUID/series/1.3.76.2.1.1.4.1.3.5388.699961756/metadata call.

It just isn’t clear to my how to gain access to them view the Stone Viewer front-end, or if there needs to be some back-end modification made to allow that, or maybe somewhere in the StoneViewer configuration file ?

“DicomWeb”: {
“Enable”: true,
“EnableWado”: true,
“QidoCaseSensitive”: true,
“Root”: “/dicom-web”,
“SeriesMetadata”: “Extrapolate”,
“SeriesMetadataExtrapolatedTags”: [
“BitsAllocated”,
“BitsStored”,
“Columns”,
“HighBit”,
“PhotometricInterpretation”,
“PixelSpacing”,
“PlanarConfiguration”,
“RescaleIntercept”,
“RescaleSlope”,
“Rows”,
“SOPClassUID”,
“SamplesPerPixel”,
“SliceThickness”
],
“Ssl”: false,
“StudiesMetadata”: “MainDicomTags”,
“StudiesMetadataExtrapolatedTags”: [
“AcquisitionDate”
],
“WadoRoot”: “/wado”
},
“ExtraMainDicomTags”: {
“Instance”: [
“Rows”,
“Columns”,
“ImageType”,
“SOPClassUID”,
“ContentDate”,
“ContentTime”,
“FrameOfReferenceUID”,
“PixelSpacing”,
“SpecificCharacterSet”,
“BitsAllocated”,
“BitsStored”,
“RescaleSlope”,
“RescaleIntercept”,
“SliceThickness”,
“WindowCenter”,
“WindowWidth”,
“PhotometricInterpretation”,
“PixelRepresentation”
],
“Patient”: [],
“Series”: [
“TimezoneOffsetFromUTC”,
“PerformedProcedureStepStartDate”,
“PerformedProcedureStepStartTime”,
“RequestAttributesSequence”
],
“Study”: [
“TimezoneOffsetFromUTC”
]
},
“Gdcm”: {
“RestrictTransferSyntaxes”: [
“1.2.840.10008.1.2.4.90”,
“1.2.840.10008.1.2.4.91”,
“1.2.840.10008.1.2.4.92”,
“1.2.840.10008.1.2.4.93”
],
“Throttling”: 4
},
“Housekeeper”: {
“Enable”: true
},