Modyfying private tags issues

Google Groups archive
1

I have read this bug https://bitbucket.org/sjodogne/orthanc/issues/140/modifying-private-tags-with-rest-api, and I have exactly the same problem.

If I do
curl http://127.0.0.1:8042/instances/8fe8c4f5-ff601003-eca1ab0d-a25e7b9a-da7e7cfc/modify --data ‘{“Replace”:{“JsonITI”:“trues”,“0008-0018”:“9999.7152657385537453357441487784537592753” },“Force”:true}’ > hi.dcm

I get a dicom image but
image.png

and if I try
curl http://127.0.0.1:8042/instances/8fe8c4f5-ff601003-eca1ab0d-a25e7b9a-da7e7cfc/modify --data ‘{“Replace”:{“0019,1900”:“aaabbbccc”}, ”PrivateCreator”:”ITI”}’

I receive
{
“HttpError” : “Bad Request”,
“HttpStatus” : 400,
“Message” : “Bad file format”,
“Method” : “POST”,
“OrthancError” : “Bad file format”,
“OrthancStatus” : 15,
“Uri” : “/instances/8fe8c4f5-ff601003-eca1ab0d-a25e7b9a-da7e7cfc/modify”
}

On the other hand when i edit “0019,0019”
curl http://127.0.0.1:8042/instances/8fe8c4f5-ff601003-eca1ab0d-a25e7b9a-da7e7cfc/modify --data ‘{“Replace”:{“0019,0019”:“laodkasdikda”,“0008-0018”:“9999.7152657385537453357441487784537592753” },“Force”:true}’ > hi.dcm

image.png

but i allways get a trailing space with: “ITI” or “iti” or “iti”
curl http://127.0.0.1:8042/instances/8fe8c4f5-ff601003-eca1ab0d-a25e7b9a-da7e7cfc/modify --data ‘{“Replace”:{“0019,0019”:“iti”,“0008-0018”:“9999.7152657385537453357441487784537592753” },“Force”:true}’ > hi.dcm

image.png

So i do not know if i’m doing something wrong, or bug 140 is still there and i don’t know if this trailing space is because of dciodvfy or because of orthanc.

Thank you very much.

2

Before anything, please provide your complete Orthanc configuration file.

3

Here is my orthanc json, I am using Orthanc inside docker.
I try with versions
jodogne/orthanc-plugins:1.5.6

jodogne/orthanc-plugins:1.5.7

orthanc.json (2.37 KB)

4

Hello,

I can’t reproduce your issue.

Firstly, I launch Orthanc 1.7.1 using Docker:

$ cat < orthanc.json
{
“RemoteAccessAllowed”: true,
“Dictionary”: {
“0019,1900”: [ “LO”, “JsonITI”, 1, 1, “ITI” ]
}
}
EOF
$ docker run -p 4242:4242 -p 8042:8042 --rm -v /tmp/orthanc.json:/etc/orthanc/orthanc.json:ro jodogne/orthanc:1.7.1

Secondly, in another terminal, I run your command:

$ storescu localhost 4242 test.dcm
$ curl http://orthanc:orthanc@127.0.0.1:8042/instances/19816330-cb02e1cf-df3a8fe8-bf510623-ccefe9f5/modify --data ‘{“Replace”:{“0019-1900”:“aaabbbccc”}, “PrivateCreator”:“ITI”}’ > hi.dcm
$ dcm2xml hi.dcm | grep 0019

aaabbbccc

As can be seen, the private tag is correctly created, with the “LO” value representation indicated in the “Dictionary” option.

Sébastien-

5

I do not know what mistakes I have done, but now it works as expected.
Thank you so much for your time.

6

I have a similar - but not identical - issue related to modifying private dicom tags.

I adapted a lua hook (attached) provided in the Orthanc documentation, to insert a couple of private DICOM tags to record the AETs from the origin. (We plan on using these to assist with the routing, once the DICOMs have been transformed.)
When I manually upload a file via the REST interface, the tag is correctly inserted. Similarly, using a pytest test (attached) I can upload a file via the dicom protocol and it is tagged as expected.

However, when I transmit a file using our normal systems (from MIM, to an instance in AWS, via a network load balancer), the logs (attached) appear correct, but when I view the instances I see:

  • 6161,1044 (Unknown Tag & Data): Null

  • 6161,1045 (Unknown Tag & Data): Null

These tags did not previously exist in the DICOM files, so the lua script is certainly running. The script does not appear to generate any errors, just the data is not present. I was previously using AE data types in the dictionary (below) but switched to LO to ensure that was not an issue.

This is using the latest Osimus docker image with the following ORTHANC_JSON:

{
“LuaScripts”: [“/etc/resources/lua/record_origin_in_private_tag.lua”],

“HttpPort”: 8042,
“DicomAet”: “Artemis-UAT”,
“DicomPort”: 4242,
“RemoteAccessAllowed”: true,
“DicomModalities”: {
“TestMIM”: [“MIMDCMQUERY”, “(removed)”, 8177],
“OrthanceRemote”: [“ORTHANC”, “localhost”, 4242]
},
“RegisteredUsers”: {
(removed)
},
“DicomAlwaysAllowEcho”: true,
“DicomAlwaysAllowStore”: true,
“DicomCheckModalityHost”: false,
“DicomScuTimeout”: 60,
“Dictionary”: {
“6161,1044” : [ “LO”, “RemoteAet”, 1, 1, “GenesisCare” ],
“6161,1045” : [ “LO”, “CalledAet”, 1, 1, “GenesisCare” ],
“6161,1046” : [ “LO”, “Username”, 1, 1, “GenesisCare” ]
},
“StableAge”: 30
}

orthanc.log (5.71 KB)

record_origin_in_private_tag.lua (1.12 KB)

test_custom_tags.py (1.01 KB)

7

For the record, a bug has been filed in https://bugs.orthanc-server.com/show_bug.cgi?id=184

8

FYI, this issue has been solved.

Summarizing, the “PrivateCreator” tag “6161,0010” was not created by the Lua script. As a consequence, Orthanc was unable to display the private tags.

Full details can be found in Bugzilla:
https://bugs.orthanc-server.com/show_bug.cgi?id=184#c6