The default workflow that I use always includes Fourier cropping (downsample) of particles during extraction to save space and speed up calculations. I select crop based it on what information I want to preserve (e.g. secondary structure information is mainly resulting from the range 4-8 Å) and guesstimates of the final resolution of the 3D reconstruction. If I reach higher resolution than the cropped Nyquist, I will re-extract.
I am now contemplating the benefits of also routinely Fourier crop the micrographs during patch motion correction and I think I might adopt this workflow in the future. The main advantage would be to save disk space, as the 32-bit motion corrected .mrc micrographs takes up a lot of space (often more than the raw data when saved as non-gain corrected, LZW compressed .tiff movies).
My suggested workflow would be:
- Patch motion with Fourier crop to a Nyquist of approximately 2/3 of expected final FSC resolution
- Example: Data collected at 0.69 Å, F-crop during patch motion to 1.0 Å for a Nyquist frequency of 2.0 Å and useful for data that reconstructs to ~2.5 Å
- EDIT: Use 16-bit float option to save disk space
- EDIT: Apparently it is only possible to use crop factors of 0.75, 0.50 and 0.25
- Initial particle extraction with F-crop to 2-4 Å for a Nyquist frequency of 4.0-8.0 Å
- EDIT: Use 16-bit float option
- Remove “junk” particles
- Extract particles with less or without additional F-crop
- Reconstruction
- If necessary, *re-run patch motion* with less cropping (in case the reconstruction goes close to Nyquist)
- Referenced-based motion correction
- Use less cropping if necessary (if possible?)
- EDIT: Use 16-bit float option
- Do “Clear” on patch motion job(s)
Some questions
- How slow is re-running patch motion? Can one re-use the original trajectories?
- Are there any issues with doing non-integer binning during Patch motion?
- Is it possible to extract with less crop during RBMC (should be, since it is using the original movies)?
I would be happy to hear feedback if other people are also routinely doing this?I saw this bug reported, which I hope has since been fixed. Have anyone else encountered any other issues with such workflow?
Hi Daniel,
Just a couple of comments, if I may.
If saving disk-space is a priority, consider writing averaged micrographs in float-16 (half in size). This is also applicable to particle stacks. That may already get you to where you want to be. Going further, once initial CTF estimation is done, the non-doseweighted micrographs are somewhat surplus to requirements (a further…quarter?).
Fourier cropping is done routinely with super-resolution movies, so fear not. Valid F-crop factors in cryoSPARC are 1 (physical pix size sampling), 0.75, 0.5, and 0.25.
Cheers,
Yang
1 Like
Agreed with Yang – and just dropping the official CryoSPARC tutorial here in case you haven’t run across it, which convinced me that you never need to do anything in Float32. With float16 on, we haven’t had to decrease too much further, although this is somewhat because it’s hard enough to get people to understand the need and theory behind downsampling!
Not the same, but we re-run patch motion sometimes for denoiser training, and there doesn’t seem to be a way to speed things up. So my guess is that it is as slow as the first time around – even if you input the output of a motion correct job, it re-calculates everything.
1 Like
Yes, of course I always toggle the 16-bit option for Patch Motion, Extraction and RBMC jobs. I wish these were on by default or that there were global toggles for the entire CryoSPARC instance not just the projects.
I usually do not delete the non-dose weighted averaged micrographs, but once I have done RBMC, I clear the patch motion job. Is it possible to delete the non-dose weighted averages from the GUI?
I will update my suggested workflow above with those important points.
Too bad that one can only do 1.5x1.5, 2x2 and 4x4 binning. That feels like an arbitrary limitation. The name Fourier cropping suggests that it is done in Fourier space and then there is no reason for not allowing arbitrary crop factor, since interpolation in Fourier space is so good (cf. extraction jobs).
1 Like
Not currently. It has been requested (by myself and others), but not yet implemented.
1 Like
Thanks @daniel.s.d.larsson for your post
A fix for this bug was included in CryoSPARC v5.0.0.
Reuse of existing trajectories, unfortunately, is not supported.
is not currently support, but we noted this feature for potential inclusion in a future CryoSPARC release.
This is supported via the Fourier-crop to box size parameter in the Final Motion Estimation parameter section.
1 Like