Error Trying to Perform FS Motion and CTF Correction

[Kyle Messina]

Hello again!

I'm currently assisting someone and teach them Warp for reconstructions but I'm having issues getting the initial FS Motion and CTF correction to work and not error out on their dataset.

When I run FS motion and CTF correction every micrograph fails to process with a command line error of: 

TIFFFillStrip: Invalid strip byte count 0, strip 12

This error happens 4 to 5 times in a row before Warp jumps to the next micrograph and it happens again on the next one.  

Looking at the log files, it does complete motion correction but errors out at "MovieProcessCTF" specifically stating:

System.Exception: Max frequency to fit is higher than the Nyquist frequency.

At the moment, I'm not sure what could cause both or either of these issues so any advice would be appreciated!  

A couple of things that may be contributing to this: They did not know their Pixel Size or Exposure so we used the values present in the mdocs.  While in the mdocs I noticed that their images were 2.6k by 2k and were binned by 2.  I've never worked with images in Warp that were binned coming off the Krios...so if I need to treat them differently, that would be good to know and maybe that's causing issues.

Thank you,

Kyle Messina

[Alister Burt]

Hey Kyle,

Did you try setting —c_range_max to something greater than 2x the pixel spacing?

Cheers,

Alister

Sent from mobile - apologies for brevity

On Jan 9, 2026, at 13:50, 'Kyle Messina' via Warp <war...@googlegroups.com> wrote:

Hello again!

--
You received this message because you are subscribed to the Google Groups "Warp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to warp-em+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/warp-em/62558e2f-2ea7-4bdf-8b23-51e909fa5f7cn%40googlegroups.com.

[Kyle Messina]

Hi Alister!

Sorry for not getting back right away, I had to catch up on a few things the last couple days.  I have part of the dataset on my workstation now so I can freely troubleshoot any issues. Turns out that the CTF max value was the issue as we had the wrong pixel size at the time. 

Thankfully that fixed the main issue.  The good news is that it will go through the movies now and the histogram looks good...but for some reason for each micrograph it still states: 

72/78, 00:13 remainingTIFFFillStrip: Invalid strip byte count 0, strip 12.                                                                                                                                
TIFFFillStrip: Invalid strip byte count 0, strip 12.
TIFFFillStrip: Invalid strip byte count 0, strip 12.
TIFFFillStrip: Invalid strip byte count 0, strip 12.
TIFFFillStrip: Invalid strip byte count 0, strip 12.

TIFFFillStrip: Invalid strip byte count 0, strip 12.

Any idea what is causing this and is this an issue?

Thank you,

Kyle

[Kyle Messina]

Hello,

Follow-up to yesterday. I think I know the what may be causing the TIFFFillStrip issue.  It may be the something off with the movies and not the data analysis

When I was teaching we initially worked up the tiltstacks (mrc files) from TOMO5 in IMOD.  The tiltstacks all looked fine and the reconstructions went well.   Moving over to Warp, I started using the IMOD and Aretomo wrappers for alignments and noticed that some of the Positions consistently failed alignments no matter the wrapper.  I looked at the aligned stacks (successful and failed) and saw that the aligned stacks (success or fail) had an odd line down the middle and the tilts had odd visual artifacts (images attached as Aligned).  I went back to the original mrc tiltstacks and I did not see any line down the middle and no obvious visual artifacts.

So I went to the original movies (tiffs) and when I used 3Dmod to view, I got the same TIFFFillStrip error as when I ran the motion and ctf correction in Warp and I can see a very faint line down the middle that is where it shows up in the attached images.  So my guess is something is off with the movies.

My question is, any idea what may be off and is there anything I can do to salvage the data/work around this issue?

From,

Kyle

[Mathew McLaren]

Hi Kyle,

I had an issue a long time ago with strong lines of contrast at the edges of my tomograms causing issues during tilt series alignment, followed by these lines running through my reconstructed tomograms. Dimitry suggested making a defect map to exclude the problematic regions of the frames, which significantly reduced the issues I was having. If these lines are consistent in their location across your micrographs, you may be able to fashion your own defects file to exclude them. This was done in the Windows version of Warp but I assume it's still valid for the Linux version as there is a --defects_path option when generating settings files. Here's the link to the discussion: https://groups.google.com/g/warp-em/c/ZlVvesMjisQ/m/sG18wa_4BgAJ

You could also try converting your files to MRC on the off-chance that it would solve the issue, but I imagine any corruption (or whatever this is) will propagate through into other images.

Cheers,

Mat

To view this discussion visit https://groups.google.com/d/msgid/warp-em/27da73da-82c8-4474-a77d-2a6099a272c8n%40googlegroups.com.

[Niharika Shukla]

Hi Kyle,

I have had a similar issue and tried to resolve it using the --defect_path option as described by Mat. Unfortunately, I ran into issues applying the defect map in the Linux version of Warp Tools as it did not seem compatible with the format of my defect map. However, I was able to successfully mask this line by using torch-cryoeraser as described by Alister in this discussion: https://groups.google.com/g/warp-em/c/REtTN5JVeQc.  I believe Hamid has also developed some code that could similarly mask the defect and was also performing quite well.

After masking the line in the individual images, the alignment was improved​ and I was able to reconstruct the tomograms.

Best,

Niharika

To view this discussion visit https://groups.google.com/d/msgid/warp-em/CAA%3DxVZtXSeoUKC-9u6xrJ36LD4G0F1w1gmfMfsP7XxkLtGyd8w%40mail.gmail.com.

[Matt Martinez]

Hi Kyle,

Just a couple of notes, not sure if these will help you but I am stubborn about keeping my Etomo workflow and combining with Warp, and I also collect tilt series using Tomo5. 

1. The tilt axis in the mdocs from Tomo5 is incorrect. You need to add 90 to the value in the mdoc (i.e. my mdocs specify -87, so I change it to 3). Additionally, you can also specify --override_axis during ts_import to the desired tilt axis

2. I found that running the etomo wrapper for tilt series alignment from Warp doesn't set all the same variables as the defaults when manually aligning and reconstructing in IMOD. See this github issue (https://github.com/warpem/warp/issues/369) where I went down a rabbit hole fixing all the problems I was running into. In particular when running the Etomo wrapper from Warp (ts_etomo_patches and ts_etomo_fiducials), there are some global variables (from the fine alignment tab in IMOD) that are set differently:

     - Rotation solution type = No Rotation (in IMOD, the default is "Solve for all rotations")

     - Magnification solution type = Fixed magnification at 1.0 (in IMOD, the default is "Solve for all maginifications")

     - Tilt angle solution type = Fixed tilt angles (in IMOD, the default is "Group tilt angles")

Running ts_etomo_patches/fiducials with the default Warp values produced pretty poor alignments in my experience, but changing to the IMOD defaults for these specific variables solved that issue. I've never seen these specific lines that you're seeing, but if you don't see it from IMOD but DO see it after Warp alignments, then maybe this can help!

There are some other notes in there about the proper way of importing alignments from IMOD since it seems the tilt stacks were flipped between IMOD and Warp, so David Mastronarde advised me on how to properly transform the .ali file if that's something else you'd rather do.

Hope this helps!

Matt 

[Marten Chaillet]

Hi all,

@Matt , I would be cautious with the 2nd solution because as far as I know Warp does not support magnification changes in its metadata model. I also think tilt angle changes from etomo will not be read when importing alignments. A different rotation (i.e. tilt axis angles) per tilt should be okay though!

When you solve the alignment for those parameters but are not able to incorporate all of them in Warp, it would mean the whole alignment is invalid.

Cheers,

Marten

Op vrijdag 16 januari 2026 om 01:48:43 UTC+1 schreef mpmart...@gmail.com:

[Kyle Messina]

Hello All,

Thank you for all the potential solutions.  

@Niharika: For torch-cryoeraser, can this be used to mask multiple micrographs in batch? I ask since these lines appear throughout the entire dataset as far as I can tell and would rather not have to go through 100s of individual images. Worst case, I could work with a lab mate to help me with a script to run it in batch since we've done that with other programs before.  

@Matt: Yes, I was aware of the Tomo5 tilt angle issue and I actually made a post about it here a few months back since initially that was some of the initial issues I was running into when learning Warp for the first time. Using --override_axis was my go to for fixing that issue.  I really appreciate the second part of your post since even in my datasets that worked, I could never get good alignments from both the IMOD and AreTomo wrappers and wondered why.  I would do the export/import option and everything worked fine so I assumed it was something with the Wrapper.  I'll definitely take a look at that post since I'm curious what is causing that issue.  For this dataset, both the wrappers and export/import are having issues which tells me something about the micrographs themselves is off.  So I feel like either trying the masking or just recollecting data that isn't off/glitched may be the quicker solution.  

At the moment, we're planning on doing a quick data collection next week to see if the binning I mentioned is the cause of the problem.  Turns out our microscopist did not realize they had binned the data so we're going to collect a couple tilts with bin 1 and bin 2 and see if the issue is replicated and if it is fixed by just not binning by 2. 

Thank you for all the input so far!

From,

Kyle  

[Matt Martinez]

Hi Marten,

Forgot to get back about this. I definitely am not familiar with all the complexities, but in the end these global variables (rotation, magnification, tilt angle) are just modifying the transformations in the .xf file, right? From the Warp point of view, the values in the .xf serve to produce to alignments for tomomgram reconstruction which wouldn't necessarily have an impact anyways on the Warp metadata model? This is just my crude understanding anyways. In the end this has helped me produce well aligned tomograms from Warp, so not sure necessarily why this works better in my hands.

Matt