Representation of loaded transformations?

[SimonHeybrock]

Relating to the larger context of #232, #233, and scipp/essreduce#96, there is one further problem. We may have to deal with noisy motion logs that we want to treat as a static value (potentially after some processing). However, ScippNexus directly converts rotations (defined as axis angle angle) into a rotation matrix (probably quaternions?):

scippnexus/src/scippnexus/nxtransformations.py

Lines 94 to 95 in e33f2f4

	elif transformation_type == 'rotation':
	v = sc.spatial.rotations_from_rotvecs(v)

. Performing any kind of processing on this (e.g., determining if the time-dependence is just noise) is much harder and more error prone than in the angle-axis representation (where only the angle, a single number, will be time-dependent).

I am not sure what to do. Should the representation of the loaded transforms be changed? Should the loading be able to perform operations such as taking a mean before this happens? As snx.compute_positions currently tries to compute a time-dependent transform and position this will also have implications there, so this is a tricky decision.

As in other cases, I am feeling more and more that a better and cleaner separation of loading from transformations would be beneficial, but that would be a much larger effort.

[SimonHeybrock]

For components without pixels, processing such as averaging can be performed on the resulting positions instead of the transform. This is much easier and well defined. What remains is probably just the NXdetector case, where applying a time-dependent transform to all pixel offsets may not be feasible.