[searchRange] and [stepSize]
Finding the optimum x & y translations, while simultaenously finding the optimum rotation angle, is a difficult problem. The problem arises because translational and orientational alignment are interdependent. That is, translational alignment works best when the images are rotationally aligned, while rotational alignment works best when the images are translationally aligned. So, many of SPIDER's alignment algorithms perform a brute-force search, attempting separate orientational alignments for various combinations of x & y shifts. For example, using a [searchRange] of 1 would result in the following shift combinations:
{(-1,1),(0,1),(1,1),(-1,0),(0,0),(1,0),(-1,-1),(0,-1),(1,-1)}
As the allowed shift increases, the number of required orientational alignments increases quickly. Alignment is generally the slowest step in image-processing (except for 3D classification). One way to reduce the computational requirements for large shifts is to not re-align for every shift. This is specified by the parameter [stepSize]. For example, using a [searchRange] of 2 and a [stepSize] of 2 would result in the following shift combinations:
{(-2,2),(0,2),(2,2),(-2,0),(0,0),(2,0),(-2,-2),(0,-2),(2,-2)}
(notice that odd-numbered shifts are skipped)
If instead the [searchRange] remained 2, while the [stepSize] was reduced to 1, there would be 25 orientational searches (more than I want to list) instead of the 9 above.
There are other alignment strategies to try to cope with this interdependency, such as those that use rotationally-invariant autocorrelation functions, but in my experience, they don't work well.
[objDiameter] and [innerRad]
How SPIDER performs orientational alignment is that it first converts the Cartesian image to polar (radius vs. angle) form, and then performs a series of 1D cross correlations (each of which is fast). A 1D cross-correlation in the polar representation is equivalent to a rotation in Cartesian space
The maximum radius is specified, indirectly, by the parameter [objDiam]: object diameter. The simplest strategy would simply be to divide the object diameter by two to get the radius. If the chosen radius is too small, the outermost features (which are likely to provide the best "handles" for alignment) will not be included in the orientational alignment. If the chosen radius is too large, then noise outside the particle will be included in the alignment. (This isn't so bad, since features here are generally weaker than over the particle, and thus will not influence the alignment strongly.)
How most of the procedures here are written, the chosen radius by default is 70% bigger than half the object diameter. Particles are (hopefully) not perfectly round, and they are generally not perfectly centered. So, the radius chosen in practice is padded a bit.
Also, the maximum radius must allow for a shift of up to [searchRange] while remaining within the image window. For example, for a 100-pixel image and a search range of 8 pixels, a radius of 44 would be too big. That is, a circle at the image center and then shifted 8 pixels would go off the image. The procedures here generally trap for this before crashing the alignment commands. A message will be echoed to the screen of the form:
Tested alignment radius of 53 from specified object diameter of 75 too big
Using outer alignment radius of 39 pixels
It may be that you need a large [searchRange] and large outer radius, beyond what the SPIDER procedure will allow. It may be that your particle is windowed too tightly, and that you need to rewindow the particles into larger windows.
The choice of inner radius [innerRad] is not so crucial. The reason is that, at low radius, few pixels are available to cover all 360 degrees. Thus, the polar plot of intensity versus angle will not change rapidly at low radius.
However, sometimes one sees in the final average a hole at the inner alignment radius, or that there is a halo at the outer alignment radius. For the former, I lately use a [innerRad] of 1. For the latter, I play with the outer radius to try to minimize this sharp boundary.
[cgOption]
In the 2D alignments, especially the reference-free variants, it is possible that the averages will be off-center. For the untilted images, it is helpful for the images to be centered. For the tilted images, it is vital that the particles are centered well. (The tilted images are the ones used in the 3D reconstruction, and are thus required to have a common origin.)
There are three strategies implemented to center the averages:
To help decide whether the centering works properly, two circles are overlain onto the intermediate averages, corresponding to the inner and outer radii. For reference-free alignment, all three centering options are written, to the stacks Zerodegr/Pairwise/stkcentavg for pairwise.msa. If you don't like the option that was selected, you will need to re-run the alignment. For multirefalign.msa, circles are currently not drawn onto the references Zerodegr/Multiref#/stkref.
Source: align.html Page updated: 2015/08/13 Tapu Shaikh