Export DICOM registration without anonymizing series

Maybe this is a naive question, but I cannot figure out this problem. I have two CT series that I have segmentations from totalsegmentator that I want to export as rtstructs using RTSlicer. I also perform registration between the two CT volumes and want to export this registration as DICOM so that I can eventually pull everything into Eclipse (the two CT volumes with associated contours and the registration between them). So I export the contours with slicerRT, and then I export the transform with the REG export type, but this creates an .sro and moving and fixed folders with anonymized images. How can I get the .sro for the two non anonymized volumes?

I guess I can be more detailed. I have two different DICOM imaging series of the same patient that I eventually want to compare the dose distribution. Each series has a segmentation (i.e. cord and vertebra T2) loaded from .nii that I want to export as an RT struct. I am looking at how couch tolerances affect the dose so I perform different registrations between the two series (focused around the treatment site T2). What I would like is to export the series with the associated RT structs as well as the DICOM registration objects that connects the two series together that Eclipse uses for registration. An example of my workflow:
image

I am able to export the segmentations as RT structs just fine, however, I am really struggling with exporting the registration. When I export the transforms as DICOM it creates a fixed and moving folders with the images and .sro, however, it seems like it anonymizes because when I load these back into slicer they have a different patient name and ID. I am also not able to export the RTstructs to the fixed or moving images.

In short, I would just like to export contours and registration and have them connected correctly to the corresponding series.

You are right, the current implementation of the DICOM RTSTRUCT and SRO exporters have this limitation that they always export a new reference image. Instead, we should update the exporters to use the existing images if they are loaded from DICOM.

We use Plastimatch for creating the SRO and it allows specifying an existing DICOM file, so we would just need to modify the code here specify DICOM file path and the exporter plugin to provide a DICOM file path instead of a node ID.

Would you have the time and expertise to modify C++ and Python classes?

Alternatively, a workaround could be to use pydicom to modify the generated DICOM SRO file to match the patient name, ID, and UIDs of the original DICOM images.

Thank you for the reply! I need a quick fix to meet a deadline so I will look into that workaround, but long term the functionality you mentioned will be great. I will take a look at implementing those changes to the C++ and Python classes and share my progress (I will likely have follow-up questions).