Modyfying private tags issues

I have read this bug, and I have exactly the same problem.

If I do
curl --data ‘{“Replace”:{“JsonITI”:“trues”,“0008-0018”:“9999.7152657385537453357441487784537592753” },“Force”:true}’ > hi.dcm

I get a dicom image but

and if I try
curl --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 --data ‘{“Replace”:{“0019,0019”:“laodkasdikda”,“0008-0018”:“9999.7152657385537453357441487784537592753” },“Force”:true}’ > hi.dcm


but i allways get a trailing space with: “ITI” or “iti” or “iti
curl --data ‘{“Replace”:{“0019,0019”:“iti”,“0008-0018”:“9999.7152657385537453357441487784537592753” },“Force”:true}’ > hi.dcm


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.

Before anything, please provide your complete Orthanc configuration file.

Here is my orthanc json, I am using Orthanc inside docker.
I try with versions


orthanc.json (2.37 KB)


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” ]
$ 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@ --data ‘{“Replace”:{“0019-1900”:“aaabbbccc”}, “PrivateCreator”:“ITI”}’ > hi.dcm
$ dcm2xml hi.dcm | grep 0019


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


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

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”: {
“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) (1.01 KB)

For the record, a bug has been filed in

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: