Closed NicerNewerCar closed 5 months ago
Testing in release using BN00106
track:
@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 (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
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?
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!
Key variable form sequential 3d ct that need to be computed for agreement/ accuracy testing:
below are the stl surface files in neutral dicom cs
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)
The rad and mc1 are not similarly transformed.
Has the tra meaning somehow changed? @NicerNewerCar
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
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
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.
When loading the flexion dicom (with spatial reference meta data)
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?
From another viewpoint:
@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.
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
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
The volume data did require a flipX, flipY to achieve the same spatial overlay:
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.
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:
I'm attempting to process automatic camera base vrgs, but the proces has thus far taken 20 mins and still going...
Will update tmrw
Will finalize and integrate today
Related pull requests:
ToDo