Handling private tags

Hello.

I’ve been reading through various threads on this form / Orthanc docs on the subject of private tags, but I am still unclear on basics… If anyone could answer my questions / point me to the right doc, etc… I’d appreciate it.

Q1)

Does Orthanc store any private tags under “Unknown Tag & Data” exposed via /simplified-tags REST API?

Q2)

My collaborator is planning to send us images to our Orthanc instance that contains various private tags. I need those private tags to pass through Orthanc and receive them via /simplified-tags REST API. Do I need to register those private tags somewhere in the Orthanc configuration files in order for them to appear on the JSON? If so, how can I do that?

Thank you!
Soichi

Hi Soichi,

Q1)

Does Orthanc store any private tags under "Unknown Tag & Data" exposed via /simplified-tags REST API?

Yes.
I.e, if you have 2 private tags in your file, via instances/:id/tags, you'll get somthing like:

   "8889,8887" : {
      "Name" : "Unknown Tag & Data",
      "Type" : "Null",
      "Value" : null
   },
   "8889,8889" : {
      "Name" : "Unknown Tag & Data",
      "Type" : "Null",
      "Value" : null
   }

but, through instances/:id/tags?simplify, you'll just get:
   "Unknown Tag & Data" : null

However, you may access their value through instances/:id/content/8889,8889 and instances/:id/content/8889,8887

Q2)

My collaborator is planning to send us images to our Orthanc instance that contains various private tags. I need those private tags to pass through Orthanc and receive them via /simplified-tags REST API. Do I need to *register* those private tags somewhere in the Orthanc configuration files in order for them to appear on the JSON? If so, how can I do that?

I think you could do this only via a plugin by calling OrthancPluginRegisterDictionaryTag

Br

Alain.

My collaborator is planning to send us images to our Orthanc instance that contains various private tags. I need those private tags to pass through Orthanc and receive them via /simplified-tags REST API. Do I need to register those private tags somewhere in the Orthanc configuration files in order for them to appear on the JSON? If so, how can I do that?

I think you could do this only via a plugin by calling OrthancPluginRegisterDictionaryTag

I confirm, creating a plugin that calls “OrthancPluginRegisterDictionaryTag()” during its initialization is currently the only possibility. This function will be available in forthcoming 0.9.5 release.

Sébastien-

Alain, Sebastien,

Thanks for your replies! I tried to Google “OrthancPluginRegisterDictionaryTag” but I couldn’t find much information. I don’t know how to write an Orthanc plugin, but is there are sample code or such?

Ideally though… it would be nice if I can just add a list of private tags in the Orthanc configuration so that those tags won’t be converted to “Unknown Tag & Data”… Could such a feature added to future releases?

Soichi

Now recorded in the roadmap:
https://trello.com/c/n57j2fWt

Thanks! I’ve subscribed to it.

Do you have any idea when v1.0.0 might be released?

I hope before the end of 2015, maybe in late November.

Sébastien-

This feature is now implemented in the mainline:
https://bitbucket.org/sjodogne/orthanc/commits/57b9e6890482b53bcd4913eaea0082fe4c802fbc

Sebastien,

Thanks! That was fast!

I’d like to help test it, but is there a git repo URL? (I see hg url though). If there is a tar ball for the src, I can plug that right into my Docker build file also…

Soichi

:slight_smile:

Orthanc uses mercurial, not git. The public repository is hosted by BitBucket at the following location:
https://bitbucket.org/sjodogne/orthanc/src

You can clone the repository using the following command:

hg clone https://bitbucket.org/sjodogne/orthanc/

Regarding Docker, you can find an official Dockerfile that compiles from the latest version of the mainline at the following location (we use GitHub in this context, for the integration with DockerHub):
https://github.com/jodogne/OrthancDocker/tree/master/orthanc

HTH,
Sébastien-

Sebastien,

I was finally able to test the new Dictionary privatetag configuration option.

I’ve added following configuration.

“Dictionary” : {
“0019,1009” : [ “CS”, “Header Type”, 1, 1 ],
“0051,1009” : [ “CS”, “Header Type”, 1, 1 ]
}

And uploaded an image that contains these private tags.

When I looked at the headers via Orthanc, I saw following.

  • 0018,1318 (dBdt): 0

  • 0018,5100 (PatientPosition): HFS

  • 0019,0010 (PrivateCreator): SIEMENS MR HEADER

  • 0019,1008 (Unknown Tag & Data): IMAGE NUM 4

  • 0019,1009 (Unknown Tag & Data): 1.0

  • 0019,100b (Unknown Tag & Data): 35

Hello,

I confirm the issue. It should now be fixed in the mainline of Orthanc:
https://bitbucket.org/sjodogne/orthanc/commits/4a151d26c98a10b1eac497cbb045f289894975e8

Do not forget to remove, then re-import the DICOM files, otherwise the precomputed headers won’t be regenerated.

Regards,
Sébastien-

Thanks Sebastien!

Do you know when this fix will be released to the docker hub?

Soichi

Following your question, I have just triggered a new build of Docker Hub, it should be available in the next few minutes:
https://hub.docker.com/r/jodogne/orthanc/builds/

Make sure to run “docker update” once the build is available.

Sébastien-

It’s fixed! I just re-tested it with the latest container and I am now seeing all configured private tags.

Thank you for fixing this problem so quickly!

Sebastien,

We were just hit by an issue that I believe Orthanc could handle - regarding private tags.

We had following configuration on orthanc.json under “Dictionary”

“0051,100B” : [ “SH”, “AcquisitionMatrix”, 1, 1 ],

We weren’t aware first that AcquisitionMatrix already existed in as a standard dicom dictionary that Orthanc was handling by default. Above configuration basically caused Orthanc to overwrite (when it’s exported via /simplified-tags API) the standard AcqusitionMatrix field with “null” value since the image didn’t contain value for “0051,100B” but was set to the same name. The fix was simple… we just had to rename our private tag to something like

“0051,100B” : [ “SH”, “q_AcquisitionMatrix”, 1, 1 ],

Now, I think it will be nice if Orthanc would display some kind of a warning (or even an error) during the boot process to make sure that the Dictionary name doesn’t collide with already known field name.

Thanks!
Soichi

Hi Soichi,

Nice catch! The fix is now implemented in the mainline (it will be part of Orthanc 1.2.0):
https://bitbucket.org/sjodogne/orthanc/commits/2fabd10737287774fe2bdeaad2dc37c8a0e4050a

Sébastien-

Perfect! Thanks!