impose restrictions on how we specify geometry?

[KrisThielemans]

Should we include some restrictions such as:

• gantry should be centred around 0,0,0 (in some vague sense, as scanner geometry can be weird)
• transforms should be in a certain order (e.g. translations over this axis, then that, then rotations in clockwise direction)

It makes it harder for somebody to write, but easier for somebody trying to make sense of the data (e.g. for interpolation etc)

[gschramm]

I would vote for encoding all transformations as 4x4 affine matrices (without scaling) which imo removes the "translation vs rotation first ambiguity" and makes combining transform easy.

[KrisThielemans]

I would vote for encoding all transformations as 4x4 affine matrices (without scaling) which imo removes the "translation vs rotation first ambiguity" and makes combining transform easy.

You might have misunderstood this issue. We already do what you recommend (ok 3x4 as opposed to 4x4 to avoid the 0,0,0,1 row):

PETSIRD/model/GeometryInformation.yml

Lines 19 to 24 in b3e635b

	# Rigid transformation, encoded via homogenous transformation
	# transformed_coord = matrix * [c, 1] (where [c,1] is a column vector)
	# with `c` of type `Coordinate`
	RigidTransformation: !record
	fields:
	matrix: float[3, 4]

I meant the order in which "elements" are in the "module" (and the "module" in the gantry)

[gschramm]

Ah ok. Sorry for the misunderstanding. I don't immediately see why the order is important, as long as we know where the elements are.

The only ambiguity I see is when building the combination of all elements in one module with all elements of the other module, to agree on which index runs fastest.

[KrisThielemans]

I don't immediately see why the order is important, as long as we know where the elements are.

It doesn't matter for most list-mode recon, but once you start to think about scatter, up/downsampling etc, having more restrictive specification would make things easier. (ATM, in the STIR reader, we have to try to infer the order from the transform fields. This was also the case for @yassirnajmaoui.)

The only ambiguity I see is when building the combination of all elements in one module with all elements of the other module, to agree on which index runs fastest.

There is no ambiguity in the current proposal as far as I can see. Location is uniquely defined via the transforms. (any order would do, as long as it's compensated for in the transforms and the detection_bin numbering)

[gschramm]

There is no ambiguity in the current proposal as far as I can see. Location is uniquely defined via the transforms. (any order would do, as long as it's compensated for in the transforms and the detection_bin numbering)

You are right. I was (incorrectly) thinking about the case where we have to back-project the (module pair) effs. into the sens image. There for a given module pair, I am not sure if the order is fixed. But this is more about agree on the ModulePairEffs.