Can extracting particles images from Relion be different chirality with Cryosparc extracted particles?

Hi Everyone,

I am suffering at following processing after Relion Bayesian polishing extraction.

Here are what I did.
Micrograph were collected with super resolution, then 2x binned through motion correction (both Cryosparc and Relion too)

Starting particles for Bayesian: 1.8million particles.
Preliminary processed through Cryosparc 3.1.
Nu- Refinement results with 512px box size
When import particles to Relion, used --swapxy and --inverty.
I confirmed particle centering using subsets around 100 particles (Relion subset) and 150 particles (Cryosparc subsets, then did --swapxy and --inverty) for re-extraction particles.

After Bayesian polishing extractions, Shiny particles were imported to Cryosparc and checked imported image thumbnail particles were correctly centered.

And I did NU- refinement with previous Cryosparc NU- input maps and Shiny particles.

But processing speed were extremely slower comparing to before Bayesian polishing.
Also map resolution and quality are poor.
So I did following Hetero- same as I did before (I did same thing without Bayesian), But results also poor.
I guessed particles overall distribution pattern looked same except z-fliped.

Here are two kind of Nu- refinement results.

Nu- refinement results before Bayesian polishing

Nu- Refinement Results After Bayesian Polishing

Is it possible Relion extracted particles can have different chirality to Cryosparc?

I may try to input Z-fliped map as reference map when I have a chance.

If I did something wrong, Please advise me.



Commonly when I processed through the Cryosparc, my output maps were Z-fliped. But only this dataset wasn’t z-flipped.

Using a reference map with the same handedness as the particles or decreasing the low pass filter to something like 50-60 may help. I could be wrong but my understanding of this problem is that it’s from the refinement using finer sampling too quickly. Sometimes repeating the job multiple times with the output particles from the previous job also works.



weird. could also just ab initio with small subset and use that as reference for NU-refine. we swapXY not invertY

Hi Jinseo,
You mention you ran motion correction with cryosparc and relion and that you used cryosparc for preliminary processing. From which micrographs did you extract the particles that you as input for bayesian polishing? You should extract from mics that were motion corrected in relion, and not motion corrected in cryosparc. Relion motion correction (mc2 or relioncor) is a prerequisite for polishing and you should use those exact micrographs for extraction to generate the half maps you input to polishing.
If you did this properly, I would then say run 2D classification to ensure your overall classes and distribution look the same and that you used the right coordinates just to ensure that you do need -inverty.


I did extraction bayesian polishing input particles against Relion motion corrected micrograph to check centering. I have tried 3 time, but I couldn’t find any issues for centering.
Finally I did 2D classification against Bayesian polishing output particles.
It seemed all particles are located somewhere in the boxes (Final results looked normal. But among interations, I could see particles were slightly off-centered). I guess my original micrographs are super-resolution with 0.4125 pixel size. I converted that to be physical pixel size as 0.825A/px during motion-correction in Cryosparc and Relion. I guess there are some miss-calculations while Bayesian polishing communication between original mics and motion corrected mics. So later I will try re-extract particles base on raw frames (0.4125A/px), then try Bayesian polishing again.


The pixel size shouldn’t be a problem if you specified the super res pixel size for your import in relion and binned by 2 in motioncor. I’ve never inverted Y when moving from cryosparc to relion only swap xy. Is it possible that the post process star file and particle star file you’re using as inputs for polishing don’t match up?


HI Jinseo,
Please see discussion on the ccpem board from the very helpful Takanori Nakane regarding bin → polishing unbin. I don’t think this is the issue, but I am not sure.

Slightly off-center 2D classes at intermediate iterations is normal. If your particles are very packed on the grid you might end up with good-looking particles by accident. The z-flip or inverted hand of your map is nothing to worry about and would be expected to go to decent resolution compared to the input. How did you obtain your polishing settings? Did you run training or use a standard/suggested setting?

I still don’t quite understand which micrographs (cryosparc or relion motion correction) were used as input to generate the half-maps that were used for polishing. In other words, from which set of micrographs did you extract to obtain the particles that were used as input for polishing?

When using cryosparc to process mics that underwent motion correction in relion (either mc2 or relioncor), the resulting particle stack and refinement should not need invert y at the step, only swapxy.

Hi, Jinseo. Have you solved these issues? I suffered the same problem when using the shiny star file for NU -refinement. Results revealed that the shiny particles location were different with the previous.

Hi hemaoshou,

I suggest you should check two thing.

In my cases when I converted files from CS to Relion, used two flags --swapxy --inverty.
But if it doesn’t help your issues, you should check your original particles locations on micrographs.
If you extracted particles from 2x binned micrographs during motioncorr, your last particles location’s x, y coordinates might not reflect original x,y coordinations, means (200, 200) → (100, 100) like, so I solved that issues with overwriting coordinates from my last extraction job .cs file.
Hope to be helpful for you.


First, for the benefit of any readers of this thread, EM images are projections and do not have chirality. Structures of either hand can produce the same image if they are rotated to complementary orientations. The hand of a single particle reconstruction is random. You can either flip hand early and use the correct hand reference for further steps, or flip hand at the very end just for model building.

The problem with polishing resulting in somewhat worse resolutions is mostly likely caused by loss of register between the movies and the refinement being used for polishing. As the process depends on projection matching between particles in the movies and the reference structure, they need to agree exactly. In practice, the only way to ensure this is to re-extract the particles from the Relion MotionCorr job and then re-refine them. Thus:

  1. Full cryoSPARC pipeline (motion correction → refinement)
  2. MotionCorr in Relion
  3. Export particles, use --strip-uid and --micrograph-path MotionCorr/job001/etc but not --inverty (–swapxy does nothing anymore, don’t use it)
  4. Double check paths and optics groups in converted star file and
  5. Extract particles (either in Relion, or in cryoSPARC after importing and linking new micrographs) - DO NOT RECENTER PARTICLES
    5a) A 2D classification cleanup to remove any empty particles will make polishing less likely to crash and is recommended but not strictly necessary
  6. Refine re-extracted particles
  7. Export particles with --strip-uid and --copy-micrograph-coordinates Extract/job001/ (or --inverty if cryosparc was used to extract)
  8. Triple check paths and optics groups and pixel sizes in all star files, use --recenter if you want to recenter before polishing
  9. relion_postprocess on refinement from step 6
  10. Run Bayesian Polishing using from 9, particle star from 7, from 2
  11. Run 2D classification on polished particles, a small number will be corrupted by new artifacts and should be rejected
  12. Refine polished particles

This protocol works, have done it ~30 times in the last 2 months.

Note: If your motion correction and particle picking was outside cryosparc and you only import particles there from the beginning, then you start from step 3 and DO use --inverty.