I would first do symmetry expansion, then volume alignment tools (to recenter ASUs at center of box), then re-extract - this works fine for us at least in lower symmetries. Is this what you are doing? I don’t see an extraction step in your workflow?
Right, the next step would be extraction. I just took the output of the Volume Alignment job into Inspect Particle Picks first to see if the centers looked appropriately dispersed on each icosahedron. The Inspect job notes the correct number of (expanded) particles per micrograph, but it only displays a single circle at the center of each icosahedron, so I thought all of the subparticles must be overlapping and not centered on distinct asymmetric units.
EDIT: Also when I use csparc2star on the Volume Alignment output to inspect my particle metadata, the 60 centers for a given icosahedron all match.
hmm - I haven’t tried that, it is possible that inspect particle picks has an issue - I know that for us extraction correctly extracts at the sub-particle centers, so maybe try a test-extraction and see?
Also you want to symmetry expand first, then volume alignment tools - in your workflow it looks like you are doing the other way around?
Can confirm - same issue on my end. Extraction gives correct centers, but coordinates after vol alignment tools are displayed incorrectly in Inspect Particle Picks and Manual Picker (overlapping on center of particle). @team I think this is a bug?
@olibclarke@lucas.adams Highlight of a single particle center (the previous center of extraction) even after symmetry expansion, but before re-extraction (with recentering enabled), is currently the expected behavior of interactive particle inspection. We are considering visualization of “pre-re-extraction” shift information (relative to the center of previous extraction) for a future cryoSPARC release.
This is correct. The volume alignment tools updates alignments3D/shift only, and not the location of the particle on the micrograph (location/center_x_frac and location/center_y_frac). The alignment shift is the residual shift required to centre a particle after it has been extracted and written to disk in the first extraction; so in cryoSPARC, the alignments3D/shift is effectively what defines the “particle origin” you mention. The geometric information needed by cryoSPARC to reconstruct a particle stack must be contained entirely in alignments3D, and since we can’t always assume that the original micrographs exist or have location information, we don’t attempt to do this (until the point of re-extraction with re-centering, if done).
The information displayed in inspect picks is location/center_{x,y}_frac, which is the pick location on the micrograph.
Re-extraction with re-centering updates location and alignments3D such that location stores the updated location of the particle on the micrograph, and the alignments3D/shift stores the small residual (<1px) shift value. E.g. in your example, this would cause the location field to now store the coordinates of the ASU on the micrograph, rather than the centre of each icosahedral particle.
In either case, re-extraction with re-centering is obviously preferred (especially if the new centre is an appreciable distance away from the original centre, as centered particles suffer less from the effects of CTF delocalization), but it is technically optional in this workflow. For small changes to the centre, you can run volume alignment tools with a new centre, and proceed immediately to local refinement and the geometry should be correct. The issue of inspect picks not showing the updated location is merely an artefact of this subtlety, and doesn’t affect anything else internal. Thus, the workflow you outlined in your first post (quoted below) should work.
@lucas.adams In what way do you notice the .star files to be incorrect when omitting the re-extraction step? I believe the rlnOrigin{X,Y}Angstrom should correspond 1-to-1 with our alignments3D/shift field. In this case, you won’t observe rlnCoordinateX being updated unless you re-extract, of course, since rlnCoordinateX stores the coordinate of the particle in the micrograph (and this is fixed after extraction).
Misunderstanding what the volume alignment tool was doing (adjusting shifts, not coordinates), I noted the unchanged coordinates in the .star file but did not notice the updated shifts/Origin[X,Y]Angst. Looking now, the .star file is correct and re-extracts the way you’d expect.
Maybe just to clarify the reason to perform this workflow, would this theoretically give a better reconstruction of the ASU than performing symmetry expansion and then local refinement with a mask of one ASU. Just asking because I usually use symmetry expansion for helical refinements and then local refinement of the ASU, and I thought that was the “best” way.
In theory local refinement on symmetry expanded particles should give the same results as local refinement on the extracted subparticles (though I’ve never tested this head-to-head). We just encounter memory/computational bottlenecks when using the full particles, especially after expansion increases our particle count 60x.
You can find the appropriate position to recenter using Chimera. Navigate to the center of the ASU that you want to recenter on, place a marker there (ac mc), then select the yellow marker sphere and get the coordinates (measure center sel). You can then enter these x,y,z values into Volume alignment tools.
When you doing the particle shift in Volume alignment tools, do you input any static mask?
The mask is the ASU mask or the whole protein?
There is also an option for symmetry alignment, I guess we don’t need this for particle shifting?
I would input a mask covering the ASU (which will then be recentered along with the particles and volume). You can then use the recentered mask for refinement or classification.
Correct, you don’t need symmetry alignment unless the ASU itself has local symmetry.
Double check that the values you input are in the correct format - I think Volume Alignment Tools wants it in pixels (not sure, check the tooltip), maybe you input the value in Angstroms?