We try to compare Orthanc WSI viewer and 3DHISTECH SlideViewer that support WSI DICOM.
The Orthanc version is docker jodogne/orthanc-plugins:latest
We download WSI DICOM from Orthanc and upload to the SlideViewer.
Use the /wsi/tiles/{id}/{z}/{x}/{y} URI to retrieve the individual tiles images.
(0002,0010)TransferSyntaxUID is 1.2.840.10008.1.2.4.50
Enclosed you could find the zip file for the test result.
The SlideViewer showed the contour was more clearly then retrieving the titles from the Orthanc via URI.
The retrieved tiled from /wsi/tiles/{id}/{z}/{x}/{y} URI is compressed or not?
How to make retrieved tiled quality better?
How to get the uncompressed or JPEG2k lossless via URI?
We are not sure the course of quality issue, any suggestion?
You will find the file: blob_https… to the browser and show the image.
Any advice will be sincerely appreciated.
Thank you.
How to set up configuration file that Orthanc WSI plugin will re-encode the tile to PNG or JPEG2k?
If we modify DICOM tag (0002,0010)TransferSyntaxUID to 1.2.840.10008.1.2 or 1.2.840.10008.1.2.4.90 is correct solution?
// Whether Orthanc transcodes DICOM files to an uncompressed
// transfer syntax over the DICOM protocol, if the remote modality
// does not support compressed transfer syntaxes (new in Orthanc 1.7.0).
We retrieved tiled from /wsi/tiles/{id}/{z}/{x}/{y} URI is JPEG image that might affect WSI image quality.
Is there any configuration we can set up and retrieve uncompressed or JPEG2k lossless WSI image?
And is there any API or URI we can use?
What do you think if we modify metadata 0002,0010 (TransferSyntaxUID) to 1.2.840.10008.1.2 or 1.2.840.10008.1.2.4.90 ?
Would you mind sharing suggestion or reference?
Any help would be sincerely appreciated.
Thank you very much.
Stephen Douglas Scotti 在 2023年3月27日 星期一凌晨12:30:55 [UTC+8] 的信中寫道：
If you receive a file with Lossy Transfer Syntax eg 1.2.840.10008.1.2.4.50, it means that your device has sent it in this format and Orthanc won’t be able to improve the image quality. The transfer syntax must be configured to lossless on the device itself before sending the image to Orthanc.
On Orthanc side, you can however check that you have not set IngestTranscoding to “1.2.840.10008.1.2.4.50”
[](https://hg.orthanc-server.com/orthanc/file/tip/OrthancServer/Resources/Configuration.json#l796)
// If this option is set, Orthanc will transparently transcode any[](https://hg.orthanc-server.com/orthanc/file/tip/OrthancServer/Resources/Configuration.json#l797)
// incoming DICOM instance to the given transfer syntax before[](https://hg.orthanc-server.com/orthanc/file/tip/OrthancServer/Resources/Configuration.json#l798)
// storing it into its database. Beware that this might result in[](https://hg.orthanc-server.com/orthanc/file/tip/OrthancServer/Resources/Configuration.json#l799)
// high CPU usage (if transcoding to some compressed transfer[](https://hg.orthanc-server.com/orthanc/file/tip/OrthancServer/Resources/Configuration.json#l800)
// syntax), or in higher disk consumption (if transcoding to an[](https://hg.orthanc-server.com/orthanc/file/tip/OrthancServer/Resources/Configuration.json#l801)
// uncompressed syntax). Also, beware that transcoding to a transfer[](https://hg.orthanc-server.com/orthanc/file/tip/OrthancServer/Resources/Configuration.json#l802)
// syntax with lossy compression (notably JPEG) will change the[](https://hg.orthanc-server.com/orthanc/file/tip/OrthancServer/Resources/Configuration.json#l803)
// "SOPInstanceUID" DICOM tag, and thus the Orthanc identifier at[](https://hg.orthanc-server.com/orthanc/file/tip/OrthancServer/Resources/Configuration.json#l804)
// the instance level, which might break external workflow.[](https://hg.orthanc-server.com/orthanc/file/tip/OrthancServer/Resources/Configuration.json#l805)
/**[](https://hg.orthanc-server.com/orthanc/file/tip/OrthancServer/Resources/Configuration.json#l806)
"IngestTranscoding" : "1.2.840.10008.1.2",[](https://hg.orthanc-server.com/orthanc/file/tip/OrthancServer/Resources/Configuration.json#l807)
**/
Note that starting with forthcoming release 2.0 of the WSI plugin, it will be possible to explicitly ask the image format to be used if decoding the individual tiles.
Information about this topic has just been added to the Orthanc Book:
NB: Starting with version 2.0 of the WSI plugin, the /wsi/tiles/{id}/{z}/{x}/{y} route accepts the Accept HTTP header, which can be used to force the compression of the tile. The allowed values for Accept are: image/png , image/jpeg , and image/jp2 (which corresponds to JPEG2k).
I hereby add some precision about the following message:
If your original file is encoded using the JPEG transfer syntax, the WSI plugin will return the raw JPEG tile, as stored inside the DICOM instance. This has no impact on quality, as the tiles of your image are already stored as JPEG inside the DICOM instance.
If your original file is either uncompressed or using the lossless JPEG2k transfer syntax, the WSI plugin will generate a PNG file. Again, this has no impact on quality, as the PNG compression is lossless.
Summarizing, the WSI plugin never impacts the quality of the stored tiles, except if the Accept header is explicitly set to image/jpeg (which only applies to releases >= 2.0 of the WSI plugin).
