i want to compressed metadata and dicom images so that its less time because its lot of time to load in frontend viewer
1 Like
Hello,
I don’t understand the question.
Regards,
SĂ©bastien-
Use JPEG2000 compression for smaller file size
“DicomWeb”: {
“Root”: “/dicom-web/”,
“EnableWado”: true,
“Enable”: true,
“Ssl”: false,
“MetadataWorkerThreadsCount”: 8,
“StudiesMetadata”: “None”,
“EnableMetadataCache”: true,
“SeriesMetadata”: “None”,
“WadoRoot”: “/wado”,
“LossyImageCompression”: “85”,
“LossyImageFormat”: “jpeg”,
“WadoThumbnailSize”: 128,
“Transcode”: true,
“PreferredTransferSyntax”: “1.2.840.10008.1.2.4.50”
}, “HttpCompressionEnabled”: true,
“Gdcm”: {
“Throttling”: 4,
“RestrictTransferSyntaxes”: [
“1.2.840.10008.1.2.4.50”
]
}, i have set this in my orthanc.json file but still its not compressed i recieve too actual dicom size in frontend which consume too much time
recieve too actual dicom size in frontend which consume too much time
It’s likely that the request doesn’t include a compressed transfer syntax in the presentation context. Have you checked the details of the request to see what transfer syntaxes are being negotiated? Could you share a log of the request so we can take a closer look?
“PreferredTransferSyntax”: “1.2.840.10008.1.2.4.50” instead of this if use Use JPEG2000 compression trnasfersunatx will it help
Use 1.2.840.10008.1.2.4.90 (J2K lossless) for compression.
Caveat: OHIF can decode J2k images on the browser, but the stone viewer can’t. Orthanc will transcode images on-the-fly. if your clients are using stone viewer predominantly, you may have to reconsider.
PS: it may be safer to use 1.2.840.10008.1.2.4.70 (JPEG lossless) instead of .50 which is a lossy compression
more details here:
Actually, the Stone Web viewer should do this decoding server-side, as long as the GDCM plugin is installed.