leginonbot
commented
5 months ago Original Redmine Comment Author Name: Gabriel Lander (@gclander) Original Date: 2013-10-09T12:41:25Z
I've noticed the same extremely sluggish processing of K2 data with ACE2 (~5 minutes per image). I think Anchi already has the code to pad out K2 images for display/binning purposes, it should be pretty straightforward to incorporate this into ACE2, as well as all the post-analysis (noise subtraction, peak extension, etc). We shouldn't do any padding/clipping for CTFfind since it seems to handle these irregular dimensions without a problem (~20 seconds per image), likely since it was developed to work with rectangular film data. Additionally I'm concerned that padding or clipping will affect the code we have in appion to deal with location-specific CTF correction for tilted images.
Author Name: Dmitry Lyumkis (@LyumkisLab) Original Redmine Issue: 2552, https://emg.nysbc.org/redmine/issues/2552 Original Date: 2013-10-09 Original Assignee: Saikat Chowdhury
I've recently noticed that my CTF estimation runs off of the K2 data run very slow (on the order of 2-20 minutes per image!). This occurs because ACE2 takes extremely long to generate an FFT (although CTFFind3 seems to have less problems). The prime number decomposition for the images off of Tecnai I (boxsize 3712) is [2, 2, 2, 2, 2, 2, 2, 29]. The 29 seems to cause problems. I would like to put in some code to check for prime numbers, and then clip the image prior to CTF estimation. I think we can just use the function getPrevEvenPrime() in pyami to clip. The question is whether to make this universal, for all CTF estimation algorithms, or just ACE2- (and I guess phasor???)-specific. Thoughts?