Hi,
Is soft real space windowing of particle images performed before or after CTF correction (I assume the latter)?
Cheers
Oli
Hi,
Is soft real space windowing of particle images performed before or after CTF correction (I assume the latter)?
Cheers
Oli
Oh, good question, I always assumed the former. Isn’t that what Relion does? So the window must be large enough to include the delocalized signal?
actually yes you’re probably right on that!
The reason I ask is we’ve had some cases recently where turning off both real space windowing and dynamic masking completely (and just letting NU handle downweighting of solvent contributions) has helped the quality of the resulting map, and was trying to figure out why
I think I know that’s what Relion does, as I recall in their code the outer part of the loop over the experimental image pixels starts with a test that the pixel is within the smaller Fourier radius between Nyquist, the E-step limit, and the internal downsampling.
We were typing at the same time - have you tried using a larger box yet?
Yes - in this particular case a larger box helps only marginally… get nearly identical (0.02Å difference) results for a 450px and 600px box when switching off real space windowing and dynamic masking (and 450px is a very tight box in this case). It’s useful using a smaller box, as 450px refinements are a lot faster to run.
Was wondering if this was because we still lose signal beyond the edge of the box, we do catch it in the corners.
Skipping masking definitely helps in some cases, and often at least doesn’t make things worse. I would have thought it would make NU-refinement slower, but it doesn’t seem to.
That’s 450px with no masking/windowing and 600px with windowing?
Is 450px really tight w/o windowing, or only if the window is 0.85? If the window has to be bigger, maybe it’s dropping off fast enough to generate some ringing that’s creating false minima?
Hey @olibclarke @DanielAsarnow just to confirm, in cryoSPARC, particle windowing is done before the CTF is handled.
The CTF is not “corrected” in the sense that we don’t ever multiply particle images by the inverse-CTF (since it can’t be inverted) but when we are accumulating the information from particle images to form a reconstruction in the M-step, the particle data is weighted by the CTF to account for the fact that some spatial frequencies have more signal than others due to the ringing in the CTF.
This means that the box size and the window both should be large enough to include the delocalized signal in the particle images. Note that the effect of tightening the box/window is a gradual one, i.e. it’s not that all the high-res signal is near the outside of the box - there is high res signal spread everywhere in the box and it is lost gradually as you tighten the box/window.
Non-uniform refinement’s local cross-validation procedure runtime is independent of the mask used and being able to do a refinement completely without a mask is a bonus side-effect of the procedure. The solvent is “optimally regularized” automatically without masking.
@olibclarke what resolution do you get with the 450px box with windowing (and/or masking) on? could it be that for this particle/defocus range, 450px is large enough to not limit the resolution?
Hi @apunjani,
Thanks for the helpful explanation!
Keeping box size 600, I get 2.56 Ă… with dynamic masking and real space windowing on, and 2.38 with them off (with noticeable map improvement). Going to 450px improves matters slightly in terms of resolution (to 2.3Ă…), but significantly in terms of speed, so I stuck with that for subsequent refinements.
Cheers
Oli
That’s a neat improvement! (2.56->2.38) Any indication if that is mostly due to turning off masking or windowing? Possible to try a run with 600px box, masking off, but windowing on?
My impression was that turning off masking was the major contributor at 600px - I wouldn’t think that turning off windowing would make a big difference at this box size (but at 450px I think it did). Sure, I can set that up!
In other cases, turning off masking made a marginal difference, but in cases with floppy heterogeneous bits it sometimes seems to help significantly.
Surprisingly, turning off masking didn’t seem to make runtimes slower - if anything a little faster. I guess the local cross validation is always done across the entire box, not just in the mask?
That makes sense - maybe not worth another run then since like you said at 600px turning off windowing is unlikely to make a difference.
This is interesting thanks!