bed positions and projection/detector/image coordinates

[KrisThielemans]

@rijobro and I had a look at incorporating horizontal bed position into STIR. The grand plan is simple:

• make sure that all projectors (and symmetries) etc find LORs/detectors coordinates using get_m or get_t
• take bed position into account in get_m/get_t, i.e. specify them to be in a coordinate system w.r.t. the bed) (get_m is currently zero in the centre of the scanner, but this would now only be true for the reference bed-position)
• image coordinates should use the same coordinate system

Aims:

• whatever the bed position, a direct LOR at m=0 intersects voxels at z=0, etc.
• if we know the patient orientation, we can figure out the LPS of each voxel, which should then correspond to what the manufacturer uses (in DICOM).

Complications:

• projection coordinates are currently returned in 2 coordinate systems, see remove obsolete functions in ProjDataInfoCylindrical and ProjDataInfoCylindricalNoArcCorr #105. Pending resolution of remove obsolete functions in ProjDataInfoCylindrical and ProjDataInfoCylindricalNoArcCorr #105, we'll have to apply the same bed-position shift in the obsolete functions (this seems a pity but easy)
• images (with z-offset=0) are currently always centered w.r.t. the scanner, see problems with ray tracing matrix when using non-default number of planes (or plane-spacing) #12. This is no longer sustainable (z-offset has to use the same coordinate system as get_m, at least up to a constant shift). Example: give a large whole-body image to the projector for a particular bed-position. It would be impossible to know what z-offset/bed-position to apply if this depends on the number of planes in the image.
• backwards compatibility (only for images with expected z-spacing/number of planes). Currently, images are written with offsets (e.g. in interfile they are specified as coordinates of first voxel) with z=0 for the first voxel the most common case. It'd be quite dramatic if forward projections of previously existing images wouldn't give the same projections anymore. Note however that currently bed position is not written/read, giving us some scope maybe.

Given that current get_m is 0 in the middle of the scanner, and image-z=0 in the centre of the first ring (for standard-sized images), it seems we need a shift:

new_get_m = current_get_m - bed_offset + (num_rings-1)/2*ring_spacing

It seems then that for backwards compatibility, we need a default bed_offset=(num_rings-1)/2*ring_spacing which is slightly weird.

Anyone any better ideas? @NikEfth, @ashgillman ?

Notes:

• we haven't thought hard yet about the sign of the bed_offset in the above eq. I guess that's pure convention.
• There's probably going to be a backward incompatibility for zoom_image when used with zoom arguments, as this currently tries to preserve the centre.

[ashgillman]

Trying to wrap my head around. Why are changes to get_t required? Is it not only transaxial?

What will z=0 mean? Does it make it easier to keep the numerous systems, but have them all move with the bed? So their position is defined w.r.t. the rings if z=0, but from this point move with the bed. This way, get_m will be the same if bed position is 0.

Backwards compatibility is tricky..
Perhaps if you want the same projection and your data has a bed offset you have to manually set it to 0.