This is a relatively obscure issue. So I’m looking for suggestions more than a solution.
Has anyone else run into “Not implemented yet” error messages during calls to modify a DICOM instance?
I have an anonymization script written in Lua that, among other things, recurses the DICOM sequences to find any DICOM UID and replace them with a new set of DICOM UID.
This happens inside of a Lua RestAPIPost call with a carefully assembled Lua table (converted to json for the call) as the replacement body.
Recently, I tried running the code against a multiframe DICOM and the code fails, generating both “Not Implemented Yet” and “Error in RestAPIPost()” error messages.
Mutiframe DICOM are rather messy compared to typical DICOM.
The replacement text JSON body is on the order of 6k+ characters, which shouldn’t necessarily be a problem for an HTTP post in general. I don’t think it’s running up against some upper limit on size. I looked at the JSON and its well formed - no missing braces or brackets.
I don’t have a sense yet whether the “Not implemented yet” or “error” message is the important one or how I would go about figuring out why this is a problem.
I am running the current Osimis image. I’m going to try to up the verbosity of the logging to see if I can get a clue as to what’s going on.
Please provide a full minimal working example (in this case, DICOM sample files + Lua script), without which nobody can reproduce your issue and help you:
https://book.orthanc-server.com/users/support.html#discussing-a-minimal-working-example
Thanks, Sebastien. I appreciate that you and the rest of the team are so quick to respond to issues brought up here in the forums.
However, I think my use case is too rare to justify the team taking their time to track down a problem that might very well be of my own making. I suspect my Lua is complicated enough that you would spend as much time getting the environment working necessary to run it (I have a whole docker-compose framework with addendum scripts for setting up iptables and an apache proxy) as you would tracking down whether the issue was an Orthanc specific problem.
I thought perhaps some other users or the team might have encountered similar errors and could provide some intuition where I could focus my efforts. For example, if anyone was aware of any explicit limitations to RestAPIPost + modify calls from Lua.
By the way, I tried the “out of the box” Orthanc “instances/xxxxx/anonymize” on one of the multiframes and it successfully anonymized the file, where “anonymized” means Orthanc’s brand of anonymization.
I believe we’ve discussed in earlier posts that Orthanc’s anonymization is not recursive. So, as a result, while the top level of DICOM tags are cleared of proprietary odd-numbered Group/Element entries, sequences which contain them are not. That’s what I observed here with the new multiframe DICOM. The standard Orthanc anonymize removed proprietary Group/Element entries from the top level but not from sequences.
One of the things my Lua script does is add recursive remove/replace to the anonymization.
In any case, I’ve been anticipating a rewrite for a while and may finally take the time to do that. I think the Python framework now available with the plugin should be easier to work with than the embedded Lua.
I switched to using the RestAPI from the command line with curl in an attempt to duplicate the problem I’m seeing in Lua.
It appears that the “Not implemented yet” is triggered when I attempt to call /modify with “Replace” containing DICOM DimensionIndexSequences (0020,9222). These are part of the Multiframe Dimension module and appear in my multiframe images as part of the Shared Functional Groups Sequence (5200,9229).
If I remove the offending 0020,9222 from the Replace JSON, the modify call proceeds without error. Examining the resulting updated DICOM output, it appears that the Replacements I specified were correctly replaced. It’s a large amount of data, so I can’t be sure, but it looks good.
The multiframe DICOM images I am working with are large (6M+). If I get a chance, I’ll try to have the researchers create a small version of a multiframe DICOM that I can upload.
Yes, please share one such DICOM file and associated call to the REST API so that we can try and work on a fix.
Sébastien-
Ok. I have a Siemens Enhanced dicom localizer obtained using a product sequence for an ex vivo animal tissue study and have attached it.
I’m also attaching the json body that I use with the call to “modify”. I’ve included the full JSON, but I think you’ll find you can trim it down to the offending tags in the 0020,9222 sequence.
f854d823-c911-45f7-9f04-8213323f46da.dcm (1.58 MB)
jsonbody.txt (1.19 KB)
Hello,
This is because modifying tags with the “AT” value representation (attribute tag) was not supported in Orthanc <= 1.9.3.
This is now implemented by the following changeset that will be part of forthcoming Orthanc 1.9.4:
https://hg.orthanc-server.com/orthanc/rev/72af097bb92b
Sébastien-
Thanks for looking into that, Sebastien.