Hi,
That there are many hoops one has to consider jumping through stems from the fact that cryoSPARC treats TIFF-formatted data differently from how most other 3DEM packages, e.g. RELION, do. In short, TIFF inputs experience an inversion along the y-axis when read by the latter but not the former.
Consider the scenario where motion correction of a set of TIFF moviestacks is performed separately in cryoSPARC and in RELION. The two sets of averaged micrographs will constitute mirror-images of each other (in the x-axis).
The implications for the difference in TIFF-handling is two-fold. Firstly, in order for particle locations (i.e. coordinates) to be valid when moving between software packages, their y-component has to be inverted. Secondly, because all re-extracted particle images inherit the y-inversion of the micrograph, some CTF parameters (e.g. astigmatism angle), and the euler angles and translations that describe the relationship between a reference volume and the constituent particle image have to be flipped appropriately.
The --inverty flag addresses the first of these two implications. The --flipy flag addresses the second. They operate independently. --swapxy was hard-coded into the metadata-handling some time in the past as it’s always required, so the flag is not really discussed these days.
What flags to use alongside csparc2star.py depends on the use-case. Moving between the two packages doesn’t always necessitate transformation. For instance, if you’ve decided to import the stack of micrographs generated in RELION for particle-picking in cryoSPARC (rather than repeat MC in cryoSPARC), then there is no y-inversion nor y-flip to account for if moving back to RELION. Or, if you’re going to repeat global alignment search following re-extraction, then strictly speaking, only coordinate treatment has to be considered.
On the other hand, if you’re working with e.g. EER or mrcs data, then both software packages treat them the same and no transformation is required.
There is an additional complication regarding the --inverty flag. csparc2star.py’s metadata-handling is coded to automatically apply a y-inversion to the coordinates. So one has to apply an explicit flag if you do not want the coordinates to be inverted, i.e. un-invert the inversion. I believe this convention came about due to K3 input data, and therefore LZW-TIFF movie-stacks, being the most common at the time.
##cryosparc2.py, line 73
def cryosparc_2_cs_particle_locations(cs, df=None, swapxy=True, invertx=False, inverty=True):
This is my understanding of the current state of play as a fellow end-user. YMMV.
Cheers,
Yang