AcquisitionDateTime Tag isn't replaced during modify REST API call

General
1

What steps will reproduce the problem?
When changing the AcquisitionDateTime tag of a DICOM image using the modify REST API: requests.post( f’http://localhost:8042/instances/{instance_id}/modify’, json={“Replace”: {‘AcquisitionDateTime’: ‘20240404111848’}, “KeepSource”: False, “Force”: True}, auth=( “–”, “–”, ), ) the AcquisitionDateTime isn’t actually modified and stays the same as originally.

I understand changing the AcquisitionDateTime is unusual but images were taken using a ultrasound machine set with the wrong date time settings so I am trying to change the StudyDate, SeriesDate, ContentDate and AcquisitionDateTime to the correct date.

What is the expected output? What do you see instead?
I expect to find the new instances with the new AcquisitionDateTime.

What version of the product are you using? On what operating system?
Im using the orthanc:latest docker image on a linux machine.

Please provide sample, possibly anonymized, DICOM files
These are images from a GE Voluson E10 Ultrasound machine.

2

Hi,

the /instances/.../modify route (at instance level, contrarily to /modify at other levels), actually does not modify the instance in place but downloads a modified version of the instance.

curl http://192.168.0.10:8042/instances/82a8583a-97677d77-2351e8c5-76757479-4639b653/modify -d '{"Replace": {"AcquisitionDateTime": "0240404111848"}, "KeepSource": false, "Force": true}' > /tmp/test.dcm && dcmdump /tmp/test.dcm | grep AcquisitionDateTime

So, to modify instance by instance, you actually need to have "OverwriteInstances": true, and re-upload the modified instance to Orthanc.

HTH,

Alain

1 Like
3

Why is the modification of instances not possible in place? What’s the reasoning behind this feature?

5

For historical reasons :wink:

Until quite recently, Orthanc did not allow to modify series or studies while keeping their DICOM IDs unmodified because, in DICOM, as soon as you modify a resource, you are supposed to generate new DICOM IDs for traceability reason. This is still the default behavior in Orthanc.

With this default behavior in mind, when you modify a series in place, it actually generates a new series in the study with all instances containing consistent information.

If you modify a single instance of a series and generate a new SOPInstanceUID (which is the recommended way to work in DICOM), you end up with one duplicate instance in the middle of a series and that is getting very messy. That’s one of the reasons why we did not allow it.

I’ll mark this topic for discussion with Sebastien but don’t expect a new feature soon - this is July/August ;-).

In the meantime, you can override the route in a python plugin to make it work the way you’d like.

6

Hm im not sure what the difference between a series and instance modification is. It sounds like the instance modification can be solved the same way you have solved the series modification.

I might indeed try to modify the route using a python plugin. Thank you for the idea. Let me know if you add a instance modification feature.