I'm not a DICOM expert - so please appologize if my terminoligy is not a 100% accurate. I plan to use the dicomParser library for a tool to read DICOM images created with another propriatary tool of our company. So the resulting .dcm files use private tags to embed additional information into the files. Those files are for internal use and the technique is mainly use for convinience (to reduce the number of files we have to exchange & to simplify the processing of the data, as some of the magic has already be done).
We use RT structure files, where the volume sequences are embedded in one file as private segments:
At the moment I use a patched version of the library - but this is only a temporary solution, as I would like to use the vanially library to keep the dependencies up-to-date. As I understand the aim of the project is to closely adhere to the DICOM standard - so I do not know if support for such private tags is even part of the standard (sorry - did not read it yet - as it seems to be huge ...).
However - it seems that in the past this was supported - but created problems (see Issue #114). Which was fixed by a contribution by @Zaid-Safadi.
I wonder if it would be an option to add an additional, optional parameter to e,g, ParseDicomOptions to process private tag sequences as well (so this could be enabled if needed, but by default is false and therefore not break the library. This might add additional use cases for the library without interfering with other applications.
If such a modification is no option I would be interested if there is a recommended method to approach this, with minimal code in the app logic (I did not find a callback, or similar that I could use).
What is your opinion about our use case and an addition option in ParseDicomOptions? Or do you have a recommendation how to handle this elegantely without modifying the existing code?
Hi all,
I'm not a DICOM expert - so please appologize if my terminoligy is not a 100% accurate. I plan to use the dicomParser library for a tool to read DICOM images created with another propriatary tool of our company. So the resulting .dcm files use private tags to embed additional information into the files. Those files are for internal use and the technique is mainly use for convinience (to reduce the number of files we have to exchange & to simplify the processing of the data, as some of the magic has already be done).
We use RT structure files, where the volume sequences are embedded in one file as private segments:
At the moment I use a patched version of the library - but this is only a temporary solution, as I would like to use the vanially library to keep the dependencies up-to-date. As I understand the aim of the project is to closely adhere to the DICOM standard - so I do not know if support for such private tags is even part of the standard (sorry - did not read it yet - as it seems to be huge ...).
However - it seems that in the past this was supported - but created problems (see Issue #114). Which was fixed by a contribution by @Zaid-Safadi.
I wonder if it would be an option to add an additional, optional parameter to e,g,
ParseDicomOptionsto process private tag sequences as well (so this could be enabled if needed, but by default isfalseand therefore not break the library. This might add additional use cases for the library without interfering with other applications.If such a modification is no option I would be interested if there is a recommended method to approach this, with minimal code in the app logic (I did not find a callback, or similar that I could use).
What is your opinion about our use case and an addition option in
ParseDicomOptions? Or do you have a recommendation how to handle this elegantely without modifying the existing code?thanks and kind regards, Patrik
References: