Store particle coordinates in starfile

[jojoelfe]

Description

This adds two new columns to the cisTEM starfile called cisTEMOriginalXPosition and cisTEMOriginalYPosition. These contain the coordinates of the particle in the image stored in cisTEMOriginalImageFilename. These values are already stored in the cisTEM database, but were not available in the starfiles. We plan to use this for template matching purposes, where they denote very useful information (position of the molecule in the cell). This will also allow for cisTEM starfiles to be an input for refine_template.

This PR only establishes these columns, but they aren't used anywhere yet. This will come in later PRs.

The columns are already used for the blender plugin MolecularNodes to make visualizations like these:

https://github.com/timothygrant80/cisTEM/assets/6081039/cef924ac-8b8f-47d1-839c-9b4fbfce477a

I have rebased my feature branch to be current with the master branch using to minimize conflicts and headaches

• [x] yes
• [ ] no

Which compilers were tested

• [ ] g++
• [x] icpc
• [ ] clang
• [ ] other (please specify)

These changes are isolated to the

• [ ] gui
• [x] core library
• [ ] gpu core library
• [ ] program it modifies

How has the functionality been tested?

Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration.

• [ ] Tested manually from GUI
• [ ] Tested manually from CLI
• [x] Passed console tests
• [ ] Passed samples functional testing
• [ ] other (please specify)

Checklist:

• [ ] I have not changed anything that did not need to be changed
• [ ] I have performed a self-review of my own code
• [ ] I have commented my code, (w.r.t. why), particularly in hard-to-understand areas
• [ ] I have made corresponding changes to the documentation {Ok to pass for now}
• [ ] My changes generate no new warnings
• [ ] Any dependent changes have been merged and published in downstream modules

[bHimes]

Hey @jojoelfe, I'm wondering what the advantage is to having another dedicated column name vs just taking an approach similar to relion and having a star file that is for a micrograph?

Part of the pipeline I setup to handle most processing stages without particle stacks does just this, using the existing X/Y shifts to indicate the position in the micrograph. If particle stacks are needed, a new star file is made.

The total shifts are trivial to combine, particularly using the python starfile class, but it would also be easy to add a method in cisTEM directly.

[jojoelfe]

Hey @jojoelfe, I'm wondering what the advantage is to having another dedicated column name vs just taking an approach similar to relion and having a star file that is for a micrograph?

I think it comes down to

• It's easier to use a single starfile as an input for programs. I think relion gets around it by having a starfile that "imports" the per micrograph starfiles, but we have no such mechanism (yet)
• The SHIFT columns uses the center of the image as origin, whereas particle picking and template matching use the corner of the image. I know that it is trivial to convert, but probably will be a source of confusion for many.
• We now have some workflows where we do template matching, classification of particles in a particle stack, and then want to go back to the image coordinates for visualization/refine_template. There is probably a way to match a particle stack back to the original coordinates, but it is much more straightforward if one can just pull them along.

Also, I don't think we are hitting the long limit for maximal number of columns yet, so having these columns (which are only written upon request) does not incur too much problems (even though I realize we should be cautious about introducing new stuff).