Signal of adjacent particles mess up 2D and 3D classification

[ccgauvin94]

@Ufuk

I tried to re-extract at an optimal box size (220A). However, no matter what I did, I could not overcome the problem of adjacent particles’ signal being considered in classifications and reconstructions. I played with myriad of settings and applied very tight masks. But still, the signal from the central particle would be overshadowed by the signal from adjacent particles, so that the central particle lost its features and turned into a blob:

Have you tried windowing, as described here?

Exact meaning of Window inner radius and Window outer radius in refinement

Hi @dzyla, The window inner radius and window outer radius in a refinement job control windowing that is applied the the particle images rather than the volume. So in your case setting them to 0.6/0.7 windows the particle images before using them for alignment/reconstruction. The 3D density however is always windowed by a soft spherical mask that just cuts out the corners of the box, along with a shaped mask (by default, based on dynamic masking). In the final refinement output, however, these …

If my understanding is correct, windowing should prevent the neighboring particles from impacting the alignment, but will still consider all the information in the box in Fourier space for reconstruction.

@Ufuk

If you look at the GFFSC after auto-tightening, there is precipitous drop at 4A. Any ideas why this might be?

The dip in the auto-tightened FSC is from the mask edge. You can read about those here:

Tight, corrected and loose GSFSC curves

Here is a short explanation of the different FSC curves in cryoSPARC: #FSC calculations in CryoSPARC ##No Mask: This is the raw FSC calculated between two independent half-maps reconstructed from the data. There is no masking applied, so both the structure and solvent are included in this FSC. ##Spherical: This is the FSC calculated after applying a soft spherical mask to both half maps. The outer radius of the soft sphere is equal to half the volume box-size (i.e. the sphere extends to the…

Specifically, the “Corrected” mask section will describe what’s happening. A large dip can be indicative of a mask that is too tight. In your case, I wouldn’t worry about it too much for now.

One downside to using a tiny box size is that you’re potentially leaving your high resolution information out of the reconstruction. Especially in the case of small particles that don’t have great contrast . If you collected data at a higher defocus to make them visible, then data actually gets delocalized quite a distance away, as a function of spatial frequency. If you then make the box size too small, that delocalized data will be outside the extracted box and not available for per-particle CTF estimation.

Another problem that can happen with small box sizes is aliasing. My understanding of aliasing isn’t great (would be happy for someone else to chime in) but I believe it occurs when oscillations in the CTF occur at a greater frequency than can be described by the number of pixels in the box. That means some oscillations will be combined into larger oscillations, and the phase flipping that’s applied based on the originally estimated defocus will be incorrect. This happens at higher resolution, I’m not sure if it’ll be a factor at the resolution you’re at, but it’s also dependent on defocus and box size.

There’s a handy calculator here, and you can input your settings and see if there are aberrations in the generated Fourier transform:
https://3dem.github.io/relion/ctf.html

Also, it’s always tough to tell from a surface view what the actual resolution of the map is. Have you docked the model in? That really doesn’t look 3.18 Å to me, from the surface view you posted.