4DCT / Sequential 3DCT

[NicerNewerCar]

• Enables support for multi-volumes to be passed through the pipelines
• Centers volumes on [0,0,0]
• Closes VRG- output tiff not associated with trial name #61
• Closes VRG - multiple series generated for a given camera placement #59
• Closes 3dct- on Generate Config: Err: Sequence Node -no attribute GetSpacing #83
• Closes 3dct - Seq nodes VRG output: incremented filenames- rather than series name #84

Related pull requests:

• ENH: Update schema to include clipping-range  Autoscoper#277

ToDo

• Documentation / Tutorials

[amymmorton]

Testing in release using BN00106

• Segmentations (mcv1, mc3, tpm, rad) , loaded from stl file
• Partial volumes generated from neutral CT of segmentation nodes
• vrg from flexion (4 cameras )
• cfg generation
• SAM load

[amymmorton]

[amymmorton]

track:

• rad, mc1, tpm

• compare (in RAD cs), tpm and mc1 resolved MBR

[amymmorton]

3D CT workflow operational
still need to

@amymmorton

• test tracking of single pose
• load/process 4dct

@NicerNewerCar

• facilitate more than one (sequence) image/frame in volume node for vrg/cam placment

[NicerNewerCar]

@NicerNewerCar

• 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]

[amymmorton]

@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?

• The secondary 3dct 'frame' also loads into slicer with a unified DICOM center as my 'reference' volume (all volumes load with same origin in dicoms)?

[NicerNewerCar]

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]

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

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

[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

[amymmorton]

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 <#75 (comment)>, 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]

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.

[amymmorton]

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:

[NicerNewerCar]

@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]

Following up offline discussing with @NicerNewerCar:

Since IO.writeVolume (called from saveSubVolumesFromSegmentation) saves the .tiff file as RAS¹ 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 ↩

[amymmorton]

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_5454748495840480277_m_-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_5454748495840480277_m_-1028758568709792776_user-content-fnref-1-9ffc4db928daba4604a2ba9182ea2a11> — Reply to this email directly, view it on GitHub <#75 (comment)>, 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]

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.

[amymmorton]

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

[amymmorton]

Have students for testing- can we please push to main for extension index availability asap?

[jcfr]

Will finalize and integrate today