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

Image Transformation Post-CTF Estimate #165

Open
MXXXZ opened this issue Nov 7, 2023 · 4 comments
Open

Image Transformation Post-CTF Estimate #165

MXXXZ opened this issue Nov 7, 2023 · 4 comments

Comments

@MXXXZ
Copy link

MXXXZ commented Nov 7, 2023

Hi Ben,
I'm currently using emClarity version 1_5_3_11_v19a, and I have come across an issue regarding my tilt series files. After conducting a CTF estimate, the image undergoes a 90° resize and a portion of the original field of view appears to be cropped

IMAGE1 the view of aligned stacks in IMOD.
image02

IMAGE2 the field of view from the '_ali1.fixed' file in the 'aliStacks' folder, after performing the CTF estimate, showing the rotation and cropping effect.
image03

Are there any parameter changes to fix this?

Thank you in advance for your time!

Mency

@bHimes
Copy link
Collaborator

bHimes commented Nov 13, 2023

The alignment applied to create your alignedStacks/tiltX.fixed during ctf estimate is predetermined by your alignment geometry you have in fixedStacks/tiltX.xf.

This either came from emClarity autoAlign, or you provided an xf from IMOD.

The images above would make sense if you manually rotated the tilt-series by 90* after doing the tilt-series alignment... something ctf estimate would not know about, and would subsequently apply the 90* from your .xf, resulting in a total rotation of 180.

@MXXXZ
Copy link
Author

MXXXZ commented Nov 15, 2023

My .xf files are generated from IMOD, and the initial rotation values may differ for different electron microscopes. Our EM has an initial rotation of around 90 degrees (the tilt axis is horizontal), which may result in rotations after CTF correction. Will there be adjustments to accommodate this parameter later in the process?

@asarnow
Copy link

asarnow commented Mar 13, 2024

Hey Ben, this is a real issue but maybe misstated before. The emClarity documentation asks for the tilt axis CCW from the vertical, say 85˚ for a "horizontal" K3 tilt series*. Unfortunately using 85˚ here produces an error message. Like me, @MXXXZ probably found that using 175˚ instead produces good alignments, but leads to an aligned TS in which the image content is properly transformed, but cropped because the output dimensions are swapped. It doesn't matter here if the alignments are from autoAlign, IMOD, or AreTomo. IMOD newstack actually has the same issue, but it can be resolved simply by swapping the SizeToOutputInXandY arguments, if the tilt axis is between 45˚ and 135˚.

Quick summary:

  • autoAlign w/ 175˚ - content is right, dimensions swapped
  • autoAlign w/ 85˚ (as per docs) - error message:
Your image rotation will result in a loss of data. Switching X/Y axes
Unrecognized function or variable 'PEETError'.
Error in MRCImage/open (line 75)
Error in MRCImage (line 67)
Error in BH_runAutoAlign (line 218)
Error in emClarity (line 253)
  • newstack -rotate 90 ts.mrc ts90.mrc, autoAlign w/ 175˚ - expected behavior

AFAICT the only workaround for now is to physically rotate the raw images before running autoAlign. This is feasible but does waste space and makes hybrid processing using Relion, WARP, or PYP extremely difficult. It seems like the intended behavior with 85˚ is exactly what we want - it's just not working at the moment.

*As an aside, different scopes with the same hardware can have different apparent tilt axes because it is physically possible to install the rectangular K3 in all 4 orientations on a Thermo scope and the choice is up to the install engineer - there's no spec. Ideally the tilt axis is near the long axis of the K3, both typically horizontal for a Krios install w/ GIF. The Falcon is square so it doesn't really matter if the camera is sideways.

@MXXXZ
Copy link
Author

MXXXZ commented Mar 16, 2024

@asarnow Thank you for the discussion. The issue of swapped dimensions not only results in a loss of data but also complicates the processing of particle coordinate files. The workaround I've been able to use involves manually swapping the reconstructed Bin1 tomogram, which is a cumbersome process not suited for batch data processing. Any related optimizations would greatly enhance the workflow.

@MXXXZ MXXXZ closed this as completed Mar 16, 2024
@MXXXZ MXXXZ reopened this Mar 16, 2024
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