Hello,
I am trying to set Implementation Class UID and Implementation Version Name. There is a way to change it in meta header when writing files, but for association it is not possible. It seems like it was not designed to be ever changed.
Is there any reason to keep these values hardcoded in DCMTK?
The reason why it is needed, is that we are creating a DICOM module that is going to be used by several different products, where we need the ability to configure implementation version name and implementation class UID per product.
I created a small sketch, that should allow to change these values.
Please have a look at https://github.com/DCMTK/dcmtk/pull/68 and let me know what do you think.
Thanks,
Vasyl
Unable to change Implementation Class UID and Implementation Version Name
Moderator: Moderator Team
-
- Posts: 4
- Joined: Mon, 2022-09-05, 09:33
-
- DCMTK Developer
- Posts: 2049
- Joined: Fri, 2004-11-05, 13:47
- Location: Oldenburg, Germany
- Contact:
Re: Unable to change Implementation Class UID and Implementation Version Name
Hi,
the reason is that if you use DCMTK in order to write or transfer DICOM objects, then, by our interpretation, DCMTK is still the DICOM software implementation that you use. Maybe we also like to see DCMTK-based implementation version information from time to time Anyway, I understand the need for the feature, of course. We will discuss the feature and pull request and let you know.
Best regards,
Michael
the reason is that if you use DCMTK in order to write or transfer DICOM objects, then, by our interpretation, DCMTK is still the DICOM software implementation that you use. Maybe we also like to see DCMTK-based implementation version information from time to time Anyway, I understand the need for the feature, of course. We will discuss the feature and pull request and let you know.
Best regards,
Michael
Re: Unable to change Implementation Class UID and Implementation Version Name
Thank you Michael and Vasyl.
I work in Vasyl's team. I fully agree with the principle Michael, and I too understand that it is a value for DCMTK and OFFIS to see the DCMTK identification. We will also be working within our organization to understand if it can be acceptable to use the OFFIS implementation identifiers. However, we are aiming at supporting equipment from multiple product lines, and being able to separate between the implementation of these product lines based on implementation identifiers has traditionally been a hard requirement.
Please note that we aim at using an unmodified DCMTK implementation to support our needs. This means that instead of forking and adapting DCMTK locally, we would like to contribute back. At the moment, the implementation identifiers could be the only real obstacle in our way. With the ability to configure TCP connect time per service, DCMTK now has an edge over commercial alternatives.
I will take this up with our interoperability team to fully understand which requirements we have to adhere to and come back to you. In the meantime, I am happy to hear that you will consider the proposal and discuss it.
Best regards,
Jøger
I work in Vasyl's team. I fully agree with the principle Michael, and I too understand that it is a value for DCMTK and OFFIS to see the DCMTK identification. We will also be working within our organization to understand if it can be acceptable to use the OFFIS implementation identifiers. However, we are aiming at supporting equipment from multiple product lines, and being able to separate between the implementation of these product lines based on implementation identifiers has traditionally been a hard requirement.
Please note that we aim at using an unmodified DCMTK implementation to support our needs. This means that instead of forking and adapting DCMTK locally, we would like to contribute back. At the moment, the implementation identifiers could be the only real obstacle in our way. With the ability to configure TCP connect time per service, DCMTK now has an edge over commercial alternatives.
I will take this up with our interoperability team to fully understand which requirements we have to adhere to and come back to you. In the meantime, I am happy to hear that you will consider the proposal and discuss it.
Best regards,
Jøger
-
- DCMTK Developer
- Posts: 2504
- Joined: Tue, 2011-05-03, 14:38
- Location: Oldenburg, Germany
- Contact:
Re: Unable to change Implementation Class UID and Implementation Version Name
Hi Vasyl and Jøger,
we discussed your proposal during our developer meeting today. In general, this could be a useful extension to the DCMTK network API, although I agree with Michael that changing the Implementation Class UID and Implementation Version Name should be an exception.
I've also commented the proposed patch on GitHub.
we discussed your proposal during our developer meeting today. In general, this could be a useful extension to the DCMTK network API, although I agree with Michael that changing the Implementation Class UID and Implementation Version Name should be an exception.
I've also commented the proposed patch on GitHub.
-
- Posts: 4
- Joined: Mon, 2022-09-05, 09:33
Re: Unable to change Implementation Class UID and Implementation Version Name
Thank you for the feedback.
I re-implemented the change in the proposed way in the new draft PR.
Please have a look https://github.com/DCMTK/dcmtk/pull/69
I re-implemented the change in the proposed way in the new draft PR.
Please have a look https://github.com/DCMTK/dcmtk/pull/69
-
- DCMTK Developer
- Posts: 2504
- Joined: Tue, 2011-05-03, 14:38
- Location: Oldenburg, Germany
- Contact:
Re: Unable to change Implementation Class UID and Implementation Version Name
Thank you. I'll check your new proposal as soon as time permits...
Who is online
Users browsing this forum: Ahrefs [Bot], Bing [Bot] and 1 guest