Template picking; templates offset

Hello developers,
Here is what I found a couple of days ago. Using CS 4.2.1+230427. I have a template created in CS:
templ_init_1. If I input that as a template in “template picking” job, when I run the job, that template becomes:
templ1_sm. You;ll notice that the image is mirrored and off center. It is even more dramatic for a different template:
templ_init_3 (outside of template picking job), and
templ3_low_sm inside of job.
Any idea why that is happening and how to get them right inside the template picking job?
Another effect, the previous templates were not low-pass filtered in the job; if I use the default filtering settings (20A low-ass filtering), I get

with a lot of ringing around the particle. That tells me that the template was masked with hard edge mask and Fourier filtered. Not what I want to see. Would it be possible to create soft-edge mask to remove the ringing?
Thank you, Michael

Thanks @mbs for reporting these observations. Please can you post additional details

  • job type, inputs and parameters for the template generation job
  • non-default Template Picking job parameters
  • Were the second and fourth figures taken from the Template Picker job’s event log, where they had template prepared <number> captions?

Hi @wtempel, thank you for response. Yes, it was Template Picking job, and yes, second, fourth, and fifth snapshots were taken from event log with “Download as png” option. Non-default parameters in the job input: particle diameter 900, low-pass filter 1 (for second snapshot), 2 (for fourth one). And since particles were sparse, I used 20 as max number of local maxima to consider. The rest was default settings. Actually, you probably noticed already two “ghosts” (in the lower left and upper right sides of the darker circle, I thin that is aliasing. And if that is the case, something is wrong with the low-pass filter applied in the job. Do you do any sub-sampling? I think ringing might be responsible for false-positives in the template picking and actually similar effect could influence 2D classification as well. Especially with this particular dataset I see problems with Class2D jobs as well. Let’s make it separate at this point though, otherwise too many things come at once.
Template generation inputs are the usual 3D map, and all defaults, 50 templates generated, I selected just four out of those since all I need was side views, particles are so long that they sit flat in the images.
Thanks,
Michael

Hi @mbs, sorry for the wait. May I ask the box size and pixel size of your data?

Hi @hsnyder, the box size for templates was 720, and the pixel size was 1.1 A/pxl.
Thanks,
Michael

1 Like

Hi Michael, thanks for providing that. I think that this is due to the fact that the entered particle diameter (900A) is much larger than the box extent (~792A), which is causing the soft-edge mask to clip against the box edge and cause those ringing artifacts you’re seeing. Try setting the particle diameter to 730A in the template picker, and let’s see if that helps

–Harris

Hi Harris, That is what happens with particle diameter set to 730A:


Thanks, Michael

The previous snapshot was with template low-pass filtering set to 2A, below is everything the same except that template filter was set to default, 20A:


Michael

Hi Michael,

Thanks for trying that. I looked more into this and ultimately you’re right - a hard-edge filter is causing the ringing that you’re seeing. We’ve noted this as a feature request. The fact that the template is inverted along Y is a display artifact, and the shift is caused by some internal re-centering that takes place (which currently can’t be disabled, but I’ve noted that down too).

Harris

Hi Harris,
Thanks for reply. My biggest concern is of course the offset from the center, because of that template just does not work. Is there anything I can do as a workaround? Say, deliberately shift the template going into the job? Mirroring in Y direction is no problem, the template would be rotated anyway every so many degrees. I tried a template created outside of cryosparc, it gets shifted as well.
Do you want me to open yet another topic, or shall we continue on this one? I have more questions/problems with 2D classification of these particles, actually it may be general problem. These particles do not get aligned well and that leads to bad classification. My thinking is that some kind of Fourier filtering is involved somewhere and associated ringing leads to artifacts that interfere with alignment. I could attach snapshots from different checkpoints within a job where reasonable classes show up and disappear again and final result is just a round blob. Have other examples as well. It sounds like a general problem in cryosparc.
Let me know what do you want me to do.
Thanks,
Michael

Hi Michael,

Noted, we’ll make sure the internal re-centering can be turned off in a future release.

Regarding the other issues you’re describing, let’s continue to use this thread. I would be interested to see the snapshots you’re referring to.

Harris

Hi Harris,
Turning off internal centering would be good, but do you know what went wrong in this case?
Here is a series of snapshots from 2D classification job in 3.1 version. All particles were hand picked, so there is no noise in that sense. They are also pretty well defined in shape, cylinders with tails coming out from one side. The snapshots are from successive iterations in the job. Custom parameters: number of classes 6, resolution 12 A, initial uncertainty factor 5, force max over poses/shifts off, remove duplicate particles off, number of online EM iterations 200, batch per class 10 (total number of picked particles 122). The rest was default.
Here are the snaps:


iter 6
iter 12
iter. 17
iter 18
iter 24
iter 36
iter 64
iter 98
iter 110
The rest is different amounts of blur. Final classes are shown in the first snapshot with original particles. You could see that occasionally good classes show up, and then get destroyed again. I tried classification with- and without forcing max over poses/shifts, does not make much of a difference. Same for initial uncertainty factor. Sorry for large number of images.
What do you think?
Michael

Hi Michael - when you say you tried with and without force/max, did you double check that it is doing what you selected? If you have less than 20 classes, it defaults to force/max off, even if you initially switched it on.

Also you might try switching off sigma annealing (annealing of the noise model), by setting the iteration to start annealing to a large number (e.g. 200), sometimes this makes a difference

Hi Olly, Yes, I did check force/max parameter in the job, it did change according to how I set it up. Ran more jobs today, tried high-pass filtering particles; I think that helped a bit. Here is an image of high-pass filtered particles to 150A:
image
Without forcing max over poses runs are still unstable, some result in reasonable classes, some are still completer mess. With max/poses enforced classification works better. In both cases 20 iterations were not enough, I eventually increased the number to 80. Even then, up to 78th iteration classes were messy but did produce reasonable result in the end. Efficiency was not great, out of 122 original particles at least a half was not in the final good looking class(es). With force/max:

run 1
run2
run 3
Without force/max:

Tried to run without sigma annealing, did not really help:

Not a single iteration showed anything reasonable.
One of the problems I see in classification is alignment, upside down mix-ups (easy to see in the previous post), and rotational alignment as well. During iterations sometimes you get really good looking classes which disappear and do not come back, at least not with that good quality. Not sure if density normalization would help.
Michael

1 Like

def looks better with highpass! Have you tried with a tighter mask radius, to really focus on the junction between the shell & the tail, maybe that might help (as it seems pretty well centered in the individual particle images?

No, did not try that yet, wanted to use cylindrical part to help with poses. In addition to everything there is a symmetry mismatch in there, so you need quite a number of particles in the set to do C1 reconstruction. And curvy tails do not help.
Michael