Greetings,
I currently use the lua script to convert all incoming instances to jpeg2000. Is that no longer required if the new GDMC plugin is enabled?
The script I’m using is a modfied version of the transcodeAndForward.lua script. My modified script is below:
function OnStoredInstance(instanceId, tags, metadata, origin)
– Do not compress twice the same file
if origin[‘RequestOrigin’] ~= ‘Lua’ then
– Retrieve the incoming DICOM instance from Orthanc
local dicom = RestApiGet(‘/instances/’ … instanceId … ‘/file’)
– Write the DICOM content to some temporary file
local uncompressed = instanceId … ‘-uncompressed.dcm’
local target = assert(io.open(uncompressed, ‘wb’))
target:write(dicom)
target:close()
– Compress to JPEG2000 using gdcm
local compressed = instanceId … ‘-compressed.dcm’
os.execute('gdcmconv -U --j2k ’ … uncompressed … ’ ’ … compressed)
– Generate a new SOPInstanceUID for the JPEG2000 file, as
– gdcmconv does not do this by itself
os.execute(‘C:\PACSIMAGEDATA\SCRIPTS\dcmtk\bin\dcmodify.exe --no-backup -m "SOPInstanceUID=’ … tags[‘SOPInstanceUID’] … '" ’ … compressed)
– Read the JPEG2000 file
local source = assert(io.open(compressed, ‘rb’))
local jpeg2k = source:read(“*all”)
source:close()
– Upload the JPEG2000 file and remove the uncompressed file
RestApiDelete(‘/instances/’ … instanceId)
RestApiPost(‘/instances’, jpeg2k)
– Remove the temporary DICOM files
os.remove(uncompressed)
os.remove(compressed)
end
end
Please check out the Orthanc Book:
https://book.orthanc-server.com/faq/transcoding.html#transcoding-in-orthanc
Summarizing, you can most probably replace your script by installing the new GDCM plugin, and by setting configuration option “IngestTranscoding” to “1.2.840.10008.1.2.4.90”. However, this requires careful validation on your side.
Thank you for your reply Sebastian. Is there anything in particular that I should be validating? Also the "IngestTranscoding" setting will be added as follows? Please confirm.
"IngestTranscoding" : "1.2.840.10008.1.2.4.90"
I confirm.
thank you.
Hi,
I tried the above approach but couldn’t succeed.
kept “IngestTranscoding”: “1.2.840.10008.1.2.4.90” in orthanc.json file but file became double size than uploaded in file storage … am I missing anything?
My target is to compress all the uploaded Dicom files via explorer.
Hi Ramesh,
Could you share:- the file you upload
- the same file once you download it from Orthanc
- your configuration file
- Orthanc logs in verbose mode
Please, before sharing that, check by yourself the transfer-syntax of both files (e.g. with dcmdump from dcmtk) and Orthanc logs.
Please find the attached request and uploaded the file.
Issue: I uploaded 2 MB files with the below configuration to Orthanc but it’s stored as 4 MB file in orthanc_db.My target is to compress the uploaded file.
am I missing anything?
requestImage.dcm (2.09 MB)
configuration.txt (495 Bytes)
Please, answer all questions from original email. I need 10-15 minutes to configure a setup and reproduce your issue while you have it running on your side.
Could you share:
- the file you upload
- the same file once you download it from Orthanc
- your configuration file
- Orthanc logs in verbose mode
Please, before sharing that, check by yourself the transfer-syntax of both files (e.g. with dcmdump from dcmtk) and Orthanc logs.
why this ?
This works fine.
My configuration file:
{
“Plugins” : [ “/home/jodogne/Mercurial/orthanc-gdcm/Build” ],
“IngestTranscoding” : “1.2.840.10008.1.2.4.90”
}
The command lines I used:
$ curl -H ‘Expect:’ http://localhost:8042/instances --data-binary @/home/jodogne/Downloads/requestImage.dcm
$ curl http://localhost:8042/instances/04f04a58-2079cf2b-41d07780-f71a54ca-1ae4241e/metadata?expand
{
“HttpUsername” : “”,
“IndexInSeries” : “256”,
“Origin” : “RestApi”,
“ReceptionDate” : “20201026T114743”,
“RemoteAET” : “”,
“RemoteIP” : “127.0.0.1”,
“SopClassUid” : “1.2.840.10008.5.1.4.1.1.6.2”,
“TransferSyntax” : “1.2.840.10008.1.2.4.90”
}
=> The line in bold shows that transcoding was successfully done from “1.2.840.10008.1.2.4.50” (of “requestImage.dcm”) to “1.2.840.10008.1.2.4.90”.
seems the above plugin is for jodogne , is it the same for osimis as well?
This works too with the Osimis Docker images:
https://book.orthanc-server.com/users/docker-osimis.html
Launch Orthanc in the first terminal:
$ docker run -e ORTHANC__INGEST_TRANSCODING=1.2.840.10008.1.2.4.90 -p 8042:8042 --rm -t -i osimis/orthanc:20.10.2
Import the image in the second terminal:
$ curl -u orthanc:orthanc -H ‘Expect:’ http://localhost:8042/instances --data-binary @/home/jodogne/Downloads/requestImage.dcm
$ curl -u orthanc:orthanc http://localhost:8042/instances/04f04a58-2079cf2b-41d07780-f71a54ca-1ae4241e/metadata?expand
{
“HttpUsername” : “orthanc”,
“IndexInSeries” : “256”,
“Origin” : “RestApi”,
“ReceptionDate” : “20201027T063051”,
“RemoteAET” : “”,
“RemoteIP” : “172.17.0.1”,
“SopClassUid” : “1.2.840.10008.5.1.4.1.1.6.2”,
“TransferSyntax” : “1.2.840.10008.1.2.4.90”
}
Complement of information:
Your input image uses JPEG destructive (lossy) compression (transfer syntax: 1.2.840.10008.1.2.4.50)
Orthanc is instructed to transcode the image to JPEG2k non-destructive (lossless) compression (transfer syntax: 1.2.840.10008.1.2.4.90)
It is thus normal that the JPEG image is smaller than the JPEG2k image, as the latter must reproduce all the compression artifacts from JPEG, and as lossless compression always requires more space than lossy compression.
Thanks for the quick response,
This is the response in my local with the API https://localhost:8042/instances/04f04a58-2079cf2b-41d07780-f71a54ca-1ae4241e/metadata?expand
{
“HttpUsername”: “demo”,
“IndexInSeries”: “256”,
“Origin”: “RestApi”,
“ReceptionDate”: “20201027T122330”,
“RemoteAET”: “”,
“RemoteIP”: “192.168.160.3”,
“SopClassUid”: “1.2.840.10008.5.1.4.1.1.6.2”,
“TransferSyntax”: “1.2.840.10008.1.2.4.90”
}
the requested file is 2MB But the uploaded one is 3.8 MB. am I missing anything?
Here attaching my orthanc.json for reference.
orthanc.json (24.7 KB)
Please carefully read my previous answer:
"Your input image uses JPEG destructive (lossy) compression (transfer syntax: 1.2.840.10008.1.2.4.50)
Orthanc is instructed to transcode the image to JPEG2k non-destructive (lossless) compression (transfer syntax: 1.2.840.10008.1.2.4.90)
It is thus normal that the JPEG image is smaller than the JPEG2k image, as the latter must reproduce all the compression artifacts from JPEG, and as lossless compression always requires more space than lossy compression."
For future reference, note that Orthanc 1.8.2 comes with the configuration option “IngestTranscodingOfCompressed” that allows to avoid re-compressing compressed transfer syntaxes using another compression algorithm:
// Whether ingest transcoding is applied to incoming DICOM instances
// that have a compressed transfer syntax (new in Orthanc 1.8.2).
“IngestTranscodingOfCompressed” : true,
In the scenario described by the original poster, setting this option to “false” would prevent JPEG images to be transcoded to JPEG2k.