I am using Orthanc since last two years and it’s working fine in all major scenarios. One issue I am facing is with the viewer, that is when I load the study in OHIF viewer, the performance (i.e. downloading of images to the viewer) is slow in the lower bandwidth, Though I am transcoding images to “1.2.840.10008.1.2.4.70” and also sending Extrapolated Study metadata in dicom-web but it doesn’t making any difference. is there any way I can improve the performance in the lower internet speed scenario? I am okay if I have to compromise the image quality in viewer.
I personally don’t know the internals of OHIF, and how to optimize the interactions between OHIF and the DICOMweb plugin of Orthanc. If there is something that can be done on our side, please let us know on this thread.
Is there any way that we can send the lower quality images from the Orthanc, so that it doesn’t require higher bandwidth to load the image response from orthanc?
In particular, you are most probably interested in the “IngestTranscoding” and “TranscodeDicomProtocol” configuration options, or in the “Transcode” argument to “/studies/{…}/modify” in the REST API.
After ingesting several terabytes of data, I would like to modify existing studies to a new transfer syntax (JPEG lossless 1.2.840.10008.1.2.4.70 per prior recommendation) to save disk space.
[Moving forward, I will use the IngestTranscoding variable]
I performed a test on several studies using REST API /studies/{…}/modify syntax. Unexpectedly, the StorageDirectory continues to grow in size. I would expect the old instances to be deleted / modified once the new Transcode argument applied (and thereby the StorageDirectory decrease in size). Instead, it appears Orthanc creates new instances.
Please help clarify my misunderstanding. Is it my obligation to determine all instances associated with a study prior to “modify” and then go back and delete all the no longer needed instances after “modify” is completed?
I don’t think BR is referring to the Housekeeper plugin.
If you use the “/modify” route in the REST API to transcode a set of source DICOM resources, the source DICOM are NOT deleted to ensure medical traceability. You must “DELETE” the source DICOM by yourself if they are not needed anymore.
Will the housekeeper plugin delete the source DICOM if IngestTranscoding option changes or is different than the source? Or will it also create a duplicate? It is not clear from the documentation.
Great idea for /modify to add “KeepSource” true/false.
The Housekeeper plugin does not use the /modify route so it will not create duplicates (and therefore does not need to care about the “source” DICOM). It will just replace the existing instance by the same instance transcoded with the new IngestTranscoding configuration.
Thank you. I am migrating a large volume of studies (long process) into Orthanc and have noted multiple times that GDCM errors result in Orthanc crashing. I have not been able to spend time to determine which of the syntax(es) is at fault:
I reverted to migrating all studies with GDCM disabled, which unfortunately means I cannot apply IngestTranscoding to JPEG 2000 syntaxes.
Will have to turn GDCM on later to enable viewing of studies stored in one of the JPEG 2000 syntaxes (majority are .90).
As an aside, I remain stuck in limbo between avoiding Orthanc crashing (GDCM disabled) and unable to view JPEG 2000 studies on Stone Viewer (GDCM enabled).
My question is whether Housekeeper could potentially corrupt a study mid-transcoding when GDCM crashes. Or does it wait for success before deleting the old transcoding? Or does it transcode one instance at a time and a potential crash might result in a single instance corruption?
Please share one instance that makes GDCM crash. We can certainly tell the GDCM plugin to avoid them.
If GDCM crashes while transcoding an instance, the old instance shall remain as is.
For your other issue: need GDCM for the viewer and not GDCM for Housekeeper:
If you are using PostgresQL or MySQL, you may:
keep your main Orthanc configured as before (with GDCM and StoneViewer, no Housekeeper)
have a second Orthanc running next to the first one with GDCM disabled and the Housekeeper plugin running.
If you are using SQLite: I’m afraid I don’t have any option to offer right now…