BrownBiomechanics / SlicerAutoscoperM

This 3D Slicer extension enables users to perform image registration.
https://autoscoperm.slicer.org
MIT License
0 stars 4 forks source link

4DCT / Sequential 3DCT #75

Closed NicerNewerCar closed 5 months ago

NicerNewerCar commented 9 months ago

Related pull requests:

ToDo

amymmorton commented 9 months ago

Testing in release using BN00106

amymmorton commented 9 months ago

sucess_4camFlexB sucessSegPV_vrg_SAM_cfgload

amymmorton commented 9 months ago

track:

fle_results1

NicerNewerCar commented 9 months ago

@NicerNewerCar

  • [x] facilitate more than one (sequence) image/frame in volume node for vrg/cam placement

I am working on writing up a tutorial on how to do this. But if you want to get a head start, feel free to check out sequences within Slicer. As this PR mostly revolves around them.

NicerNewerCar commented 9 months ago

4dct-slicer 4dct

amymmorton commented 9 months ago

@NicerNewerCar (HNY!)

I am going to evaluate how well the tracking of our 3dct radius tpm and mc1 results compare to previous methods- I'd also like to understand- within the SAM world, (and respective ct dicom from which tiff was generated- where the drrs are).

I'd like both relative measures and absolute measures of how we did.

When cameras are placed- how did you determine world origin? More specifically... the

..\Transforms\Origin2DICOMCenter.tfm

Insight Transform File V1.0

Transform 0

Transform: AffineTransform_double_3_3 Parameters: 1 0 0 0 1 0 0 0 1 0.1953125 0.1953125 -87.5 FixedParameters: 0 0 0

To confirm: is this established from my 'reference' volume when we generate the partial volumes?

NicerNewerCar commented 9 months ago

HNY!

The ..\Transforms\Origin2DICOMCenter.tfm transformation is used to transform the volume back to the original dicom location after centering has been done.

To confirm: is this established from my 'reference' volume when we generate the partial volumes?

Been a while since I've looked at the code but I believe I am taking the average center of all the frames in the sequence to compute the centering transform.

Hope this clears things up!

amymmorton commented 8 months ago

Key variable form sequential 3d ct that need to be computed for agreement/ accuracy testing:

  1. From reference pose (slicer volume node used for segmentation/PV creation) to each frame (subsequent slicer volume none - parsed as VRG) the relative motion (helical axis phi and t) of one RB relative to the other. (in the test dataset my rb1 == mc1 and rb2 == tpm) rb1 w.r.t rb2 from neutral to flexion

below are the stl surface files in neutral dicom cs fromSegNeutral_stllocaitonandPVcs_from tfm

inSLicerSegNeutral_stllocaitonandPVcs_from tfm

Outputs from the Autoscoper tracking: fle_mc1.tra and fle_tpm.tra

Each 1x16 matrix (reshaped into 4x4) is a transform in SAM space of the partial volume to the optimized pose in flexion

(as an example: from bvr wrist data:

fle_rad - Copy.txt fle_tpm - Copy.txt fle_mc1 - Copy.txt

But when the stl (in flipped partial volume space) are trnasformed by the respective tra, instead of getting a plausable anatomical pose: (like in bvr wrist) bvrwrist_appliedtra

The rad and mc1 are not similarly transformed. sam_3dct_errspace_transformed

Has the tra meaning somehow changed? @NicerNewerCar

NicerNewerCar commented 8 months ago

Has the tra meaning somehow changed?

No it shouldn't have as we haven't done any modifications to the save_tracking_results function within Autoscoper base

amymmorton commented 8 months ago

We modified the cameras.. and our tra is a function of the space it's defined in.. Could that change somehow affect the outputs?

On Tue, Feb 6, 2024 at 3:52 PM Anthony Lombardi @.***> wrote:

Has the tra meaning somehow changed?

No it shouldn't have as we haven't done any modifications to the save_tracking_results function within Autoscoper base

— Reply to this email directly, view it on GitHub https://github.com/BrownBiomechanics/SlicerAutoscoperM/pull/75#issuecomment-1930731669, or unsubscribe https://github.com/notifications/unsubscribe-auth/APUUPFWZYM55LS23TWLCD4LYSKJY7AVCNFSM6AAAAABA5C7NNCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZQG4ZTCNRWHE . You are receiving this because you were mentioned.Message ID: @.***>

--

Amy Morton, MSc

Sr. Research Engineer, Bioengineering Lab, Department of Orthopaedic Research The Warren Alpert Medical School of Brown University and Rhode Island Hospital 1 Hoppin Street, CORO West, Ste. 404, Providence, RI 02903

amymmorton commented 7 months ago

I'm thinking this has to be the camera placement. In order to create a viable cfg for this 3dxct- the volume flip req was [0 1 1]. Which is odd- as other bvr sets were [0 0 0] - so this to me means the projection is from a different perspective

I checked against a wrist dataset (Wn00108) Nothing to do with how the partial volumes are generated. image

amymmorton commented 7 months ago

When loading the flexion dicom (with spatial reference meta data) image

I visualizing voxels thresholded at 540 and slices at [0,0 50]. The stl from neutral are also plot in this space( and make sense that the green and magenta bones are more proximal .

Transforming the fle ct data by Origin2DICOMCenter, visualized voxel thresh 540, slices ([0,0,0].. @NicerNewerCar @jcfr This is really keeping me stumped. The tra output transforms don't match the flex dicom (transformed into sam origin) * note the mc1 tra is on the wrong side of the wrist...? flipped in X and Y?

image

From another viewpoint: image

NicerNewerCar commented 7 months ago

@amymmorton

flipped in X and Y?

This may be due to two different coordinate systems LPS vs RAS. I believe the conversion between the two is flipping the X and Y directions. See this page in the Slicer docs for more information.

jcfr commented 7 months ago

Following up offline discussing with @NicerNewerCar:

Since IO.writeVolume (called from saveSubVolumesFromSegmentation) saves the .tiff file as RAS[^1] using the itk::TIFFImageIO writer, we need to update generateConfigFile so that it serializes the volumeFlip settings so that if the tiff is loaded back it is loaded using the LPS convention. This will remove the need for the user to guess and manually toggle the checkboxes.

Similarly, if we are loading partial volume in Slicer, these should be done to account for the volumeFlip settings.

The volumeFlip settings should be considered as TIFFToLPS transform

[^1]: vtkMRMLVolumeArchetypeStorageNode::WriteDataInternal: https://github.com/Slicer/Slicer/blob/59608a21fa8a575a6e887bae056fea4ac476b4c9/Libs/MRML/Core/vtkMRMLVolumeArchetypeStorageNode.cxx#L533-L732

amymmorton commented 7 months ago

It looks like I was unintentionally responsible for my own frustration. Thanks to @mrainbow, I did not flip and the solve tra are as I would expect.

On Mon, Feb 12, 2024 at 1:59 PM Jean-Christophe Fillion-Robin < @.***> wrote:

Following up offline discussing with @NicerNewerCar https://github.com/NicerNewerCar:

Since IO.writeVolume (called from saveSubVolumesFromSegmentation) saves the .tiff file as RAS1 <#m_5454748495840480277m-1028758568709792776_user-content-fn-1-9ffc4db928daba4604a2ba9182ea2a11> using the itk::TIFFImageIO writer, we need to update generateConfigFile so that it serializes the volumeFlip settings so that if the tiff is loaded back it is loaded using the LPS convention. This will remove the need for the user to guess and manually toggle the checkboxes.

Similarly, if we are loading partial volume in Slicer, these should be done to account for the volumeFlip settings.

The volumeFlip settings should be considered as TIFFToLPS transform Footnotes

1.

vtkMRMLVolumeArchetypeStorageNode::WriteDataInternal: https://github.com/Slicer/Slicer/blob/59608a21fa8a575a6e887bae056fea4ac476b4c9/Libs/MRML/Core/vtkMRMLVolumeArchetypeStorageNode.cxx#L533-L732 ↩ <#m_5454748495840480277m-1028758568709792776_user-content-fnref-1-9ffc4db928daba4604a2ba9182ea2a11>

— Reply to this email directly, view it on GitHub https://github.com/BrownBiomechanics/SlicerAutoscoperM/pull/75#issuecomment-1939351694, or unsubscribe https://github.com/notifications/unsubscribe-auth/APUUPFQ3R2L4MRIL7WCIWSLYTJRBNAVCNFSM6AAAAABA5C7NNCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZZGM2TCNRZGQ . You are receiving this because you were mentioned.Message ID: @.***>

--

Amy Morton, MSc

Sr. Research Engineer, Bioengineering Lab, Department of Orthopaedic Research The Warren Alpert Medical School of Brown University and Rhode Island Hospital 1 Hoppin Street, CORO West, Ste. 404, Providence, RI 02903

amymmorton commented 7 months ago

The volume data did require a flipX, flipY to achieve the same spatial overlay: image

The check for which we've never done (no known volume representain was prev available for bvr). This slight modification in prost processing is very reasonable.

amymmorton commented 7 months ago

Now that we are firmly rooted for a single pose- it's vital to pivot back to multiple poses ( as in #59 ).

I can use the Sequences module to create a Sequences volume node of multiple 3d cts:

image

I'm attempting to process automatic camera base vrgs, but the proces has thus far taken 20 mins and still going...

Will update tmrw

jcfr commented 5 months ago

Will finalize and integrate today