Repository navigation
Reference Frame Coordinate Transformations #379
Description
Part of #373 Live plotting:
Implement coordinate transformation mathematics to align and translate different reference frames (e.g., optical webcam, sample stage motor limits, reconstructed ptychography) into a universal reference frame.
Goals
Acceptance criteria : What journeys should the user be able to complete to consider your feature done
Be as specific as you can, check them off once they work. Add more if you find more requirements during development. Issue should only be considered done after all of them are checked
- Spatial Alignment: Multi-layered scans, camera feeds, and stage limits overlay with perfect spatial overlap.
- Consistent Calibration: Transforming physical stage movements into pixel coordinates and vice versa produces accurate mapping for visualisation and future scans definition.
Tasks
base on the goals, deduce the tasks required. check them off once they're done
Caution
Decision needed
- Universal Frame definition: Define the a reference frame (X-ray beam frame) as the single source of truth coordinate system.
- Transformation: Implement translation, scaling, and rotation matrices to map external coordinate spaces to the reference frame.
Activity
[-]Universal Beam Coordinate System, establish the X-ray beam frame as the single source of truth coordinate system?[/-][+]Reference Frame Coordinate Transformations[/+]DanPorter commentedon Sep 16, 2026
An example set of transformations might look like:
Back end
Pass to front end
NKatti2011 commentedon Sep 16, 2026
Notes from a meeting with David Burn & @EmsArnold, 15/09/2026.
Summary
The model is a series of transformation matrices. Each layer corresponds to a
stage or to a drift factor, and a coordinate is expressed by choosing how far down that
series you go. A reference frame is chosen per measurement, and the UI should let
the user toggle between frames, sample coordinates vs motor coordinates, for example.
Commissioning needs to expose more depth in the matrix series than a normal experiment does.
change. The centre of that rotation is not necessarily inside the region of interest.
stability was tried and did not work, so the design instead accepts wobble and corrects
for it.
Drift factors include temperature, time, rotation and translation. The correction is a
product of matrices. Users should not be doing drift correction by hand during an
experiment; it is intended to run as a feedback loop.
Origin
Users start with a dummy coordinate system. A user will define an origin at least once
per sample, and plausibly more often than that.
Where the maths lives.
The same transformation maths is needed in at least three places, at three very
different rates:
interferometers, PandABoxes and motion controllers. A transformation matrix is fixed
here during commissioning.
offsets become real-space transformations and motor moves.
after processing, in order to find the ROI. This is the "alignment" stage.
This means the maths package cannot be bolted onto the Davidia server.
It needs to be a standalone library that controls, the UI and
the processing pipeline can all consume. Which individual matrices sit in hardware and
which sit in software is unresolved, and a follow-up meeting with low-level controls is
needed to settle it.
Architecture sketch from the meeting
Also wanted
reportedly already has a pixel-to-real-stage-position function worth looking at. This
may deserve its own issue.
factor, driven by a software feedback loop. A virtual device already exists. Software
feeds it scan positions; the hardware side does a substantial amount of coordinate
transformation.
Scope to define
maths can reproduce them. We need to confirm with whoever owns the metadata what that record
should look like, and whether Tiled is the right home for it (likely).
with low-level controls
pixel-to-real-stage-position function to look at)
DAQ config server. We need to decide what else besides stage configuration lives there.
the same package
DanPorter commentedon Sep 16, 2026
Thanks @NKatti2011, that's great.
Was there any discussion about where the transformation matrices would be stored? The commissioning transformations may be hard-coded into the controllers, but anything like M_sample and M_temp will be defined during the experiment but need to be persistent between users. One option could be to store these in tiled or another one to store the data in a specific database service (which we would need to make or request).
Either way, it is related to #389
NKatti2011 commentedon Sep 16, 2026
@DanPorter No this hasnt been decided yet and probably needs to be hashed out in this next meeting or in a further meeting with people for controls and analysis. Likely Tiled but writing in data in the shape we want is something that is being developed by Core within Nexus-writer.