Appion

The source code is in myami/programs/ace2

ace2correct.m has parameter input and ctf.m has ctf equation

I edited ctf.m, ctf.h, ace2correct.m. There is another struct member called phase_shift throughout. If any parameter in the
ctfvaluesfile.txt is not listed, then there are default values that are used. This is true now also for phase_shift (the default is zero).

Everything is compiling and running: on the other hand, I didn't do anything except create containers for the new value of phase shift. Now to alter ctf.m and the actual formula and check it is doing the correct thing...

In routine, ArrayP g2DCTF
of function ctf.m

I added the following if statement as shown

--------------------------------------------
f64 B = sqrt(1.0 - ampconst*ampconst);
f64 A = ampconst;// ensures A^2+B^2=1, and A cos g+ B sin g has maximum of 1;

if (phase_shift != 0){
        B = cos(phase_shift);
        A = sin(phase_shift);
    }
---------------------------------------------

So if the phase shift gets set, it ignores the amplitude-contrast parameter ampconst. 
 The issue is that ampconst seems to be fixed, so phase_shift should take precedence in the cases where it is calculated

It does not make sense to abandom amplitude contrast when there is phase shift. ace2correct takes values from already estimated value which includes both terms. Your if statement will cause an offset in the correction, won't it ?

I will post some supporting figures, but the adjusted code seems to work pretty well. In the case where there is a calculated phase shift, it seems the program is just using this value to perform correction. I will explain method shortly.

I am not sure I understand this. Are the red and blue (smooth) curves meant to match. How do we know the red curce is correct?

Regarding CTFFind4 output, Phase shift definition conversion is covered during the generation of the txt file I gave you already. It should be fine.

Hi, Phil, this will not work when additional phase shift + arcsin(A0) becomes larger than 90 degrees because the cosine term which traditionally is made by sqrt(1-sq(A0)) will not represent the behavior of a phase shift larger than 90 degree.

The cosine term is the B in ctf.m

Good point, Anchi. I had been too narrow minded with the data on hand.

Better is

ctf.m
if (phase_shift != 0){
f64 phase_shift_New= phase_shift+ asin(ampconst);
A = sin(phase_shift_New);
B = cos(phase_shift_New);
}

This will handle the case you point out, which I checked numerically as given above.

Shall I go ahead and commit changes to ace2correct.m and ctf.m ?

I also went a round of emails with Alexis Rohou (author ctffind4) who corroborated the approach here.

How should we keep track of the amplitude contrast in the database. I think adding another parameters is overkill. Can we convert all amplitude contrast values to a single angle and then change the software around it to use the new format?

What is the new format ? I've already added extra_phase_shift in database so that amplitude contrast can stay the same.

Amplitude contrast is expressed the way it is for physical reason that it contribute to 7% increase in intensity when extrapolate to zero frequency. I don't think It is overkill to have phase shift as a different parameter in the database. We need to track how phase plate changes phase over time independent of using carbon or ice amplitude contrast.

In the ctf estimation programs, I believe the assumption is to keep amplitude contrast fixed which the user can enter from theory or measure by fitting a non-phase plate image of similar material. In the fit, it may be combined with phase shift form phase plate, but it will be separated out in the output.

I tend to agree with Anchi's point of view: having an extra_phase_shift.
Mathematically amplitude contrast and phase shift cover the same information, but the way that ctffind4 relays the information, and the way that we think of it, is that there is the base amplitude contrast (the 0.07) and then the additional part due to the phase plate.

By the way, I did not mean to imply that I checked the scenario for phase plate data that had phase shifts greater than a quarter wave. I just meant that the new code compiled and ran correctly on the data that I had.

I tried looking at another micrograph that claimed a much higher phase shift (16sep22d 3sq 35hln 1hln 2epn), but it was hard to repeat the same calculation, because the CTF oscillations were so small in magnitude. I don't know how to reproduce the better looking (but also small) oscillations in the leginon/ACE panels. So, I will commit changes today

I have been trying yesterday to commit my changes to the trunk. I started with a fresh trunk today. Something won't work. Here is my sequence of commands

318    14:52    git clone http://pbaldwin@emg.nysbc.org/git/myami
   335    14:58    git add programs/ace2/ctf.m
   336    14:58    git add programs/ace2/ctf.h
   337    14:59    git add programs/ace2/ace2correct.m
   338    14:59    git commit -m "changes ace2correct.m and ctf.m to include phase plate line from ctffind4, refs #4471" 
   344    15:01    git pull
   346    15:02    git push origin trunk

Here is the error

error: Cannot access URL http://pbaldwin@emg.nysbc.org/git/myami/, return code 22
fatal: git-http-push failed

Can someone help me? Thanks

Created an issue for Sargis as this is likely a server issue.

Ok, so ctf.m, ctf.h, ace2correct.m were correctly pushed to the trunk thanks to Anchi and Sargis.

Do I need to push the executable there? Or does somebody compile on the server?

Thank you, Philip

I just committed the executable ace2correct.exe also
It is showing up on the repository correctly
(REDMINE/projects/appion/repository/revisions/trunk/show/programs)

I tested ace2correct.exe on the test image with two phase shifts:
Image 0. The uncorrected image
Image 1. Corrected with the correct phase shift, phi
Image 2. Corrected with phi + pi/2

When adding the corrected image 0 and 1, the power spectrum oscilates as Phil presented earlier (right half of the image I attach). When adding Image 1 and Image2, I get double the oscillation (left half of the attached image). confirming the phase shift correction is correct. See attached image.

A minor request: The program prints all other options it reads but not the extra phase shift. Could you make print out that as well so that it is more readable ? Thanks.

In addition, ace2correct.exe is also in myami/appion/bin. Please push your new version there as well.

Ok, there is an extra phase shift line. I originally wrote such an output line, but removed it at some juncture.