Appion

I committed the change to change the params file to use the camera length adjusted nominal mag. This means that if you have your own script to convert the old 10000 output with a multiplication of the sore, you should revert it to no change.

The run parameter change in appion refineJobFrealign.py still needs to be done. Since database connection is not assumed here, I will have to pass apix from php output.

I'm not sure if mag refinement changes by Film or particle. I've used it a long time ago, and it made things worse. Niko seems to be of the same opinion, from what I recall. Technically speaking, Frealign should work fine if the 3 values (physical pixel size, pixel size, mag) are related to one another. So 10,000 might actually work, if you're pixel size is 1.31 and dstep=1.31. I don't know how it is coded, so unfortunately can't be of more help here.
Dmitry

The method Dmitry described is what I always do.

Is there an advantage to not just using the real dstep value? it seems like these short cuts could cause a lot of confusion in the future...? (e.g. when the previous wrapper for ctffind3 would automatically calculate the defocus search range so that if your appion-nominal defocus was off all the ctf estimations would fail)

just a thought

The reason I always do it this way is that the apix and mag*physical pixel are the same number calculated two different ways. I always trust the Leginon derived apix the most because it is typically very well calibrated where the post column magnification is not, and we typically derive it from the apix calibration. My thinking goes that since the magnification is really just dependent on the apix, why not just make the dstep the same as the pixel size and the magnification 10000. That way it is easy to look at the values and know that there are no math errors and the two numbers are not in disagreement.

I just realized I made a typo I meant physical pixel/mag

note to my earlier post (from conversation with Yong Zi): FPART = FALSE means micrograph by micrograph, FPART = TRUE means particle by particle, so this might apply to mag refinement as well.

Hi Anchi,

When I prepare the par file for a krios/k2 dataset, the actual mag comes out to be: 76336. I think is is actually supposed to be about half that. Since it's in super resolution a dstep of 2.5, not 5 µm should be used.

Sorry for the delay,
Melody

Well, this proves that how useless camera physical pixel size is.

The value is determined in the instrument, hard coded in K2SuperResolution camera, and has been used for 3 years in ctfestimate.py (CTFfind3), and did not break a thing.... I am afraid to change it in 3.2 now because it might actually break something....

The reason that nothing breaks is because we always cancel its effect. Camera physical pixel size (ppix) is recorded in the Leginon database referenced by each image. It has never been used by itself in Appion. Because pixel size at the specimen (apix) is measured independently, xmag for CTFFind has always been defined as apix / ppix. CTFFIND would internally calculate apix = xmag * ppix.

Until now that we put xmag in a text file for everyone to see : )

Opened Issue #3763 and fixed it in pyscope. It will take effect when Leginon etc is updated on a camera computer. We will not go back to change any of the old data, though, so if you process old data, the old physical pixel size will stay there and therefore xmag would be wrong.

Melody, this can not be tested further unless you collect new data, as long as the ratio is exactly 2x of what you expect, this issue can be closed.