You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
pgfeller
changed the title
Failed to extract private tag sequenxe $(3009,1201)
Failed to extract private tag sequence $(3009,1201) - [DCF Private VS Segment Colume Sequence]
Apr 12, 2023
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,
ParseDicomOptions
to process private tag sequences as well (so this could be enabled if needed, but by default isfalse
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?thanks and kind regards,
Patrik
References:
The text was updated successfully, but these errors were encountered: