Weird output CTF correction

[damsport11]

Hi, we are trying to use the novaCTF software to correct the CTF for some of our tomograms. Unfortunately, we do get weird, unrecognizable images as output after the CTF correction (2nd step):

The command that we used to create the defocus files was: novaCTF -Algorithm defocus -InputProjections tomogram3.mrcs -FULLIMAGE 4096,4096 -THICKNESS 596 -TILTFILE tomogram3.tlt -SHIFT 0.0,0.0 -CorrectionType phaseflip -DefocusFileFormat ctffind4 -CorrectAstigmatism 1 -DefocusFile defocus_file.txt -PixelSize 0.272 -DefocusStep 30

The command that we used to do the ctfCorrection was: novaCTF -Algorithm ctfCorrection -InputProjections tomogram3.mrcs -OutputFile corrected_stack.st_25 -DefocusFile defocus_file.txt_25 -TILTFILE tomogram3.tlt -CorrectionType phaseflip -DefocusFileFormat ctffind4 -CorrectAstigmatism 1 -PixelSize 0.272 -AmplitudeContrast 0.07 -Cs 2.7 -Volt 200

Our defocusfile was created using CTFFind4 and heads like:

 # Output from CTFFind version 4.1.8, run on 2017-11-08 14:05:46
 # Input file: tomogram3.mrcs ; Number of micrographs: 41
 # Pixel size: 2.726 Angstroms ; acceleration voltage: 200.0 keV ; spherical aberration: 2.70 mm ; amplitude contrast: 0.07
 # Box size: 1024 pixels ; min. res.: 30.0 Angstroms ; max. res.: 5.0 Angstroms ; min. def.: 40000.0 um; max. def. 100000.0 um
 # Columns: #1 - micrograph number; #2 - defocus 1 [Angstroms]; #3 - defocus 2; #4 - azimuth of astigmatism; #5 - additional phase shift [radians]; #6 - cross correlation; #7 - spacing (in Angstroms) up to which CTF rings were fit successfully
 1.000000 59891.027344 58239.968750 -0.722487 0.000000 -0.007407 19.384889
 2.000000 65787.750000 65121.347656 47.391100 0.000000 -0.007546 21.638946
 3.000000 61857.050781 61439.832031 16.659393 0.000000 -0.008426 18.244602
 4.000000 64301.230469 63620.773438 -63.011589 0.000000 -0.006423 19.384889
 .....

Any idea that could explain our output? Questions we do have is whether we should load the real raw .st file or the IMOD-aligned .ali file? FULL-IMAGE represents the full XY pixelsize? Thank you very much in advance for your help!

Casper Berger & Kevin Knoops Maastricht University

[turonova]

The FULLIMAGE parameter is in pixels, i.e. it specifies dimensions in x and y of your image and that regardless of the actual pixel size. What is the size of the image you try to correct? The parameters in the first step suggest it is 4096,4096 but in the image you have sent both stacks are 1024x1024 (although I assume this is only size of the display window not the image). If your pixel size is 0.272 for unbinned stacks and you corrected 4xbinned stack (1024x1024) then you have to multiply your pixel size by 4.

Does all the stacks look weird or only the number #25? You can try to run CTF correction on the original defocus file to see what output you will get. If this one already looks weird could you please send me the header information of your tomogram3.mrcs?

As for the alignment - it does not matter if the stacks are aligned or not. The only important thing is that the number of lines and the order in your defocus file correspond to the number of projections in the stack (and also in you tilt angles file).

[damsport11]

Hi, thanks for the quick reply! Indeed, the images are 4kx4k (1024² is IMOD window size). All the stacks look this weird (#=35) unfortunately. Header of original is:

 RO image file on unit   1 : tomogram3.mrcs     Size=    1343489 K

 Number of columns, rows, sections .....    4096    4096      41
 Map mode ..............................    6   (unsigned 16-bit integer)  
 Start cols, rows, sects, grid x,y,z ...    0     0     0    4096   4096     41
 Pixel spacing (Angstroms)..............   2.726      2.726      2.726    
 Cell angles ...........................   90.000   90.000   90.000
 Fast, medium, slow axes ...............    X    Y    Z
 Origin on x,y,z .......................    0.000       0.000       0.000    
 Minimum density .......................   334.31    
 Maximum density .......................   2960.9    
 Mean density ..........................   1648.2    
 tilt angles (original,current) ........   0.0   0.0   0.0   0.0   0.0   0.0
 Space group,# extra bytes,idtype,lens .        0        0        0        0

Header of CTFcorrected stack is:

 RO image file on unit   1 : corrected_stack.st_25     Size=    2686977 K

 Number of columns, rows, sections .....    4096    4096      41
 Map mode ..............................    6   (unsigned 16-bit integer)  
 Start cols, rows, sects, grid x,y,z ...    0     0     0    4096   4096     41
 Pixel spacing (Angstroms)..............   2.726      2.726      2.726    
 Cell angles ...........................   90.000   90.000   90.000
 Fast, medium, slow axes ...............    X    Y    Z
 Origin on x,y,z .......................    0.000       0.000       0.000    
 Minimum density .......................   334.31    
 Maximum density .......................   2960.9    
 Mean density ..........................   1648.2    
 tilt angles (original,current) ........   0.0   0.0   0.0   0.0   0.0   0.0
 Space group,# extra bytes,idtype,lens .        0        0        0        0

It comes to mind that the "corrected" stack has the same densities and map mode, however, occupies twice the filesize? We have tried your suggestion to use the original CTFFind4 output defocus file and this gives a similar weird stack. We have also tried it with a tomography stack downloaded from EMPIAR with the same result.. Thanks again for the help. Cheers, Casper&Kevin

[turonova]

Do you have the latest version of novaCTF (from this page not from EMBL webpage)?

The output of CTF correction is always in float (mode 2) and thus the header you posted is definitely incorrect (causing nonsense output when visualized). I fixed this bug in August (see history of changes here). You can easily check this by looking into the volumeIO.cpp - line 46 should contain header.mode=2;. If not, please download the latest github version and try again.

[damsport11]

Yes, indeed the software was downloaded form EMBL... Thanks for the help!