Is there a way to control the number of tiles in the cryosparc patch motion correction?
The patch tile size is apparently set to a fixed physical dimension at the sample level, with the effect to get many more tiles at pixel sizes above 1 A/pixel, but very few below 1 A/pixel. Cryosparc does this automatically.
We are exploring very small sampling sizes of about 0.3A/pixel for the highest resolution samples (yes, graphene lattice for example transmits signal to 0.6A in our images). In practice, this means we get only 4x4 patches at that small pixel size.
It would be more meaningful if the tile size or the number of tiles could be influenced directly such as in motioncor2/3. What really matters for motion correction is the dose per detector pixel, not the dose per area at the sample level. Total dose is furthermore sample dependent, and inorganic samples can tolerate much higher doses. To set the patch size to a fixed area at the sample level may work for most biological samples with resolutions between 3-2 A, but it is not optimal at higher resolution, and it also results in too many patches at large pixel sizes.
If there is currently no way to control the number of tiles or the tile dimension by the user for motion correction, I would like to request adding this feature as an option.
Does “Override knots (X) and (Y)” not have an impact? I was under the impression that it was a way of adjusting how many patches it worked on, as setting it to 1x1 reduced memory usage dramatically on one dataset… so I would hope adjusting it the other way would also work.
No, this is only for spline fitting in x/y and z (frames/time).If the number of requested “knots” exceeds the number of automatically assigned patches, it outputs an error. It may work the other way around to reduce the number of used patches.
Hi @mwolf Your understanding seems very thorough, and you are correct that right now the tiles are fixed to a specific physical extent (500A). While we don’t necessarily expect a benefit from using smaller tiles, even at high magnification, I suppose there’s no harm in exposing it as a parameter. I’ve recorded this as a feature request for a future release.