Print

Print


Hi Jacob,

I’m replying to your posts one by one below, get ready for a bit of an early morning brain splurge :-)

Please note that I didn’t write Kino’s tomo import program, this is just my understanding of the details. I hope it’s useful!

Cheers, 

Alister

On 30 Jun 2022, at 03:11, Anderson, Jacob <[log in to unmask]> wrote:

After reading the "?" on the Tomo Import panel and reviewing the BiorXiv preprint, I had a few specific questions regarding the "Flip YZ"? and "FlipZ" flags.


First, let’s define what we’re doing here: One goal of the import program is to calculate, for each tilt-image, a ‘projection matrix' (4x4) which transforms (by premultiplying, on the left) a 3D point in the tomogram (as a column vector in homogenous coordinates, i.e. 4D with a 1 in the last dimension, XYZW). The XY component of the resulting column vector is the position of your 3D point from the tomogram in the 2D tilt-image.

More simply, these matrices (again, one per tilt-image) define the relationship between 2D input images and a 3D reconstruction

Here is an awesome resource for projective geometry
https://www.labri.fr/perso/nrougier/python-opengl/#id12

Okay, cool, so we’re trying to figure out these projection matrices from IMOD metadata.
  1. In IMOD, I post-process all tomograms choosing to "Swap Y and Z dimensions". From the output tomogram, I pick particles. I bring those coordinates into Relion. But during these steps, I don't think I ever explicitly swap dimensions in the tilt series I input to Relion. Should I still be using the "Flip YZ" in this context? If so, why? Does this change how Relion interprets the coordinates I input in the next step?
These dimensions are the dimensions of the tomogram, not the tilt-series - I explain some background which should explain why below.

IMOD employs a very clever computational trick when generating tomograms which allows it to only consider one row of pixels from the entire ‘aligned tilt-series’ during tomogram generation (in the absence of Xtilt), significantly reducing memory usage. The 2D XZ slices which are reconstructed are, by default, saved as XY planes in the reconstruction (for efficiency when writing them out, XY slices are nice contiguous blocks of memory). 

As a result, the user now has a choice in IMOD
- leave the tomogram as it is, always look at it from the side to get a ’normal tomogram’ in which Z coincides with the optical axis
- swap the Y and Z dimensions, giving a tomogram in which Z coincides with the optical axis of the 0 degree image
- rotate 90 degrees around the X axis, giving a tomogram in which Z coincides with the optical axis of the 0 degree image

People like slicing along the optical axis and slicing a 3D volume is fastest along Z (for the same reason as it’s more efficient to write XY planes, the data are a nice contiguous block of memory), so typically people either swap the Y and Z dimensions or do a 90 degree rotation.

I think the import program assumes by default that you performed the 90 degree rotation, the flipYZ option allows you to say ’nope, I did the other thing’
  1. In the tutorial dataset, "Flip Z -> Yes" is chosen. I was uncertain in which contexts we want to flip the sign of the Z coordinates. In the tutorial dataset, like my own, the Z values are all positive three digit numbers. Maybe I am taking it too literally, but I was uncertain when -ive Z values would be useful. 
Depending on how positive stage-tilt angles are interpreted during tomogram reconstruction, a reconstruction may appear ‘mirrored’ across the central XY plane (Z is ‘flipped’ across this central plane). I know, for example, that Warp has a different internal convention for what a positive tilt angle means than IMOD which can result in this Z-flip relative to how an IMOD tomogram is reconstructed from the same data.

This option allows a user to account for the possibility that they picked in a tomogram reconstructed with this ‘Z flip’.
  1. In the Relion 3.1 SPA pipeline, there is a way where users can see where particles come from in the micrograph (thin lime green circles on the micrograph). Is there any similar implementation in Relion 4 --tomo? This would be a convenient sanity check for making sure the boxed regions are on the intended features.   
Are you talking about the positions in the tilt-series? I have a script which does this which may be useful to you - I apologise that it’s not written particularly pedagogically, let me know if anything is unclear.
https://gist.github.com/alisterburt/bf929f82570622f1610d7b3904ef917f

If you are referring to the 3D positions in the tomogram, here is an example for visualising RELION 3.0 data without shifts which can be adapted for RELION 4.X data
https://gist.github.com/alisterburt/15fda2431760da76ac6a09d2967afc67

  1. More fundamentally, given the only *mrc input is a tilt series, I was curious how Relion4 is interpreting the Z-coordinate when extracting Pseudosubtomograms. Under the hood, in Relion4 creating a tomogram from the TS/IMOD directory where the Z helps set the position of the box?
Please see the explanation above about the matrices which relate 3D positions to 2D images - there is an existing program written which can reconstruct tomograms from RELION data called ‘relion_tomo_reconstruct_tomogram’ - this may also prove useful for checking that your import has functioned correctly :-)

Jacob



To unsubscribe from the CCPEM list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCPEM&A=1



To unsubscribe from the CCPEM list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCPEM&A=1