Add a ProjectionModel specification
#20
Conversation
README.md
Outdated
| | `rotation_x` | ROTATION_X | tomogram rotation around x-axis | | ||
| | `rotation_y` | ROTATION_Y | tomogram rotation around y-axis | | ||
| | `rotation_z` | ROTATION_Z | tomogram rotation around z-axis | | ||
| | `dx` | SHIFT_X | particle shift in x-dimension | | ||
| | `dy` | SHIFT_Y | particle shift in y-dimension | |
There was a problem hiding this comment.
I'm a bit confused by these headers. This is about tilt images right? so not about tomograms or particles?
There was a problem hiding this comment.
sorry, forgot to update the shifts labels in the table copied from poses!
The way rotations are parametrised for tilt-series alignments in all softwares (AFAIK) is in terms of 'rotations of the specimen' i.e. in the microscope reference frame
| ```python | ||
| from cryotypes.projectionmodel import projection_model_to_projection_matrices | ||
|
|
||
| projection_matrices = projection_model_to_projection_matrices( | ||
| df=projection_model, # ProjectionModel dataframe | ||
| tilt_image_center=(1919, 1355), # tilt-image rotation center (xy) | ||
| tomogram_dimensions=(3838, 3710, 2000) # dimensions of tomogram (xyz) | ||
| ) | ||
| ``` |
There was a problem hiding this comment.
Maybe we should provide the same for particles (if one wants to work with affines rather than pos + rot).
There was a problem hiding this comment.
possible but not sure of the benefit there, will open an issue to discuss something re this though
| | `pixel_spacing` | PIXEL_SPACING | isotropic pixel/voxel spacing for shifts | | ||
| | `source` | SOURCE | reference to the file from which data came | | ||
|
|
||
| A utility function is also provided for generating projection matrices from these data. |
There was a problem hiding this comment.
What transformation are these proj matrices describing exactly?
There was a problem hiding this comment.
position in tomogram -> position in tilt image, one matrix per tilt image
There was a problem hiding this comment.
As in, if you apply this to the real object and project along z, you get the tilt image? I would add a small note for this for clarity!
There was a problem hiding this comment.
yes, if by z you mean the beam axis :)
| ROTATION_X = "rotation_x" | ||
| ROTATION_Y = "rotation_y" | ||
| ROTATION_Z = "rotation_z" | ||
| ROTATION = [ROTATION_X, ROTATION_Y, ROTATION_Z] |
There was a problem hiding this comment.
Should we maybe for consistency use actual Rotation objects internally?
There was a problem hiding this comment.
agree we want consistency but don't think a Rotation is simpler for this use case where a primary use case could be checking how much things have shifted from expected stage tilt angles -> I don't want to force understanding rotation decomposition on someone in that situation
There was a problem hiding this comment.
We can always provide utility functions... I mean, this still requires all the convention stuff from euler angles, so at least the Rotation moves the burden to the creation of the object, instead of both creation and utilisation. I just think consistency here would be nice to keep; and like with poses, it's just more convenient to work with single values rather than multiple things.
Either way, we should at least clarify in which order rotations happen, if they are intrinsic/extrinsicm, yada yada.
There was a problem hiding this comment.
note added explaining rotations!
Codecov Report
@@ Coverage Diff @@
## main #20 +/- ##
===========================================
- Coverage 75.65% 58.89% -16.77%
===========================================
Files 11 16 +5
Lines 267 343 +76
===========================================
Hits 202 202
- Misses 65 141 +76
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
|
thanks for the review, notes added! rotation object discussion can continue in #21 - will merge here |
No description provided.