Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pinnacle registration info #1811

Open
hotsenblotz opened this issue Oct 24, 2023 · 9 comments
Open

Pinnacle registration info #1811

hotsenblotz opened this issue Oct 24, 2023 · 9 comments

Comments

@hotsenblotz
Copy link

Just tried out the phmedphys_pinnacle module, it works great! Really appreciate all your hard work and keep it open source. My question is if the Pinnacle TAR file has a secondary MR image set, after exported using phmedphys_pinnacle module, the registration info will be lost. Is it possible to keep this info? I think Pinnacle may keeps registration information in file plan.RegManager or plan.Plugin.DeformationPlugin, but wasn't able to find any answers online.

@crcrewso
Copy link
Collaborator

There's an old pinnacle email group (I've lost track of) that might know how the MR registrations used to be kept. If you can find it or have samples that we could look at I'd definitely be interested in exploring this further.

@hotsenblotz
Copy link
Author

@crcrewso Thanks for your reply. Sorry that I can't provide patient files as test sample. Are you talking about this google group (https://groups.google.com/g/pinnacle3-users)? I did some searching, but can't find any useful information. Do you think it's possible to get it working within phmedphys_pinnacle module?

@crcrewso
Copy link
Collaborator

That's the group, without seeing what the files look like or what version of Pinnacle you're recovering from I can't be sure. My clinic didn't have many MRIs in the datasets when we took on converting our archives.

@hotsenblotz
Copy link
Author

It doesn't needs to be MRI, could be PET. I believe that I found the registration info is saved in plan.VolumeInfo file, but have no idea on how to implement this in phmedphys_pinnacle module. Could you please share some thoughts? A sample code will be a great help!

@crcrewso
Copy link
Collaborator

Sorry I should have been clearer, we don't have any registrations of multiple images in our archives, access to RT compatible PET and MRI scans occured only after we transitioned to Eclipse.

@hotsenblotz
Copy link
Author

#1597 (comment)
It seems like you worked on a similar issue years ago, are you or anyone else able to implement @sjswerdloff 's following idea?
#1597 (comment)

@sjswerdloff
Copy link
Collaborator

sjswerdloff commented Oct 27, 2023

#1597 (comment)
It seems like you worked on a similar issue years ago, are you or anyone else able to implement @sjswerdloff 's following idea?
#1597 (comment)

I think having sample data to work on is kind of key for all of this.
The correct DICOM object to use for representing this information is the Spatial Registration Object, but you need to have DICOM references (at a minimum, Frame Of Reference UIDs for each of the image series).
If the original DICOM data (MR, CT, etc.) has been stored along with the rest of your patient data, then the original FoR UIDs (and other UIDs) are available. Otherwise, one needs to export the image volumes as DICOM and gather the UIDs used when those were generated (or from the new DICOM data).

The snipped of Volume Info provided in #1597 was translation only in the 4x4 matrix...

@hotsenblotz
Copy link
Author

@sjswerdloff , thank you for your explanation. Do you have any suggestion to properly anonymize patient in pinnacle? I can change the patient name and DOB, but what about the info in DICOM images?

Could you explain what is the 4x4 matrix means?

@sjswerdloff
Copy link
Collaborator

sjswerdloff commented Dec 23, 2023

@hotsenblotz Sorry for the delay, I didn't see the latest comment until now.
If you want to anonymise the DICOM images, you can use that capability in pymedphys (anonymisation or pseudonymisation, I'd suggest pseudonymisation because you have multiple DICOM objects that you'll want to have references between).
You would probably want to pseudonymise the DICOM image data first, and extract the resulting patient name and DOB and use those to substitute in the pinnacle data.

A (rigid) registration consists of rotation and translation. The Spatial Registration Object (which is for rigid registration, scaled registration or affine, i.e. "Linear transformations"), the alternative is Deformable Spatial Registration) contains a single matrix that contains both the rotation (a 3x3 matrix) and the translation (a 1x3 vector). The other four elements are constrained to constants (1 for the global scaling, 0 for the others) to avoid scaling and/or warping.
Frame of Reference Transformation Matrix Type attribute:
https://dicom.innolitics.com/ciods/spatial-registration/spatial-registration/00700308/00700309/0070030a/0070030c

So "the 4x4 matrix" is contained in:
Frame of Reference Transformation Matrix attribute:
https://dicom.innolitics.com/ciods/spatial-registration/spatial-registration/00700308/00700309/0070030a/300600c6

There is considerable discussion of the matrix at the URLs above (or you can go directly to the DICOM Standard, but I like the innolitics browser... it's a few years behind the current version, but all of what is in this discussion is 10+ years old... so not an issue).

Real medical image data for the same patient would use rigid transformations for this type of thing.
I mention the rest for completeness sake.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants