Slow Performance in Lower Bandwidth

[Chirag Patel]

Hi Orthanc Users,

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.

Thanks.

[Sébastien Jodogne]

Hello,

I guess this question about the OHIF viewer should rather be asked to the OHIF team:

https://groups.google.com/g/cornerstone-platform

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.

Regards,

Sébastien-

[Chirag Patel]

Thanks for the reply,

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?

Regards
Chirag

[Sébastien Jodogne]

Hello,

The following FAQ explains the different possibilities offered by Orthanc to transcode DICOM images:

https://book.orthanc-server.com/faq/transcoding.html

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.

Sébastien-

[BR]

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?

Thank you.

[Alain Mazy]

The Housekeeper plugin should be your friend.  It is able to recompress an existing storage: https://book.orthanc-server.com/plugins/housekeeper.html

Note: you'll be one of the first users so feel free to suggest any documentation improvements ...

HTH

Alain

--
You received this message because you are subscribed to the Google Groups "Orthanc Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to orthanc-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/orthanc-users/c3e6817a-a1f1-4cda-8df8-f6381c1e4a51n%40googlegroups.com.

[Sébastien Jodogne]

Hello,

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.

That being said, it would be possible to add a "KeepSource" option to "/modify" so as to delete the source DICOM after modification, akin to split/merge:

https://book.orthanc-server.com/users/anonymization.html#split-merge-of-dicom-studies

I've just added a TODO:

https://hg.orthanc-server.com/orthanc/rev/bedc27c0da5b

Sébastien-

[BR]

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.

Thank you.

BR

[Alain Mazy]

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.

HTH

Alain.

--

You received this message because you are subscribed to the Google Groups "Orthanc Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to orthanc-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/orthanc-users/502b540a-e1af-49dd-945e-96ba88845afcn%40googlegroups.com.

[BR]

Alain,

Orthanc 1.11.0

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:

      "RestrictTransferSyntaxes" : [
      "1.2.840.10008.1.2.4.90",   // JPEG 2000 Image Compression (Lossless Only)
      "1.2.840.10008.1.2.4.91",   // JPEG 2000 Image Compression
      "1.2.840.10008.1.2.4.92",   // JPEG 2000 Part 2 Multicomponent Image Compression (Lossless Only)
      "1.2.840.10008.1.2.4.93"    // JPEG 2000 Part 2 Multicomponent Image Compression
      ],

GDCM 3.0.10 - 02/04/2022 

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?

A future thread could be dedicated to additional GDCM troubleshooting.  I see a few priors, including: https://groups.google.com/g/orthanc-users/c/xIwrkFRceuE/m/_D953ohEAgAJ

Thank you.

BR

[Alain Mazy]

Hi Ben,

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...

HTH

Alain

To view this discussion on the web visit https://groups.google.com/d/msgid/orthanc-users/ebcb497b-70d8-40d6-81af-975a7a4d620dn%40googlegroups.com.