Add "additional origin"

[ashgillman]

This is a somewhat cheating method for the change of origin, where the origin isn't actually changed, but I add an additional vendor origin.

Its not really a solution to #244 as you can't read back from a NIfTI, but allows for consistent writing. It is also useful to have as a target to eventually have the STIR origin the same as the vendor origin.

Looks like a lot of commits, but actually only the last two. The rest are #236 #257 #260

[ashgillman]

@KrisThielemans I believe a solution more like this is appropriate.

It seems that the vendor origin moves, I have found in our data that it has changed a number of times. I am currently investigating what caused the change, but I guess certain kinds of maintenance - we have had detectors etc. replaced in the last year.

Anyway, this won't do as that means that the origin would be very specific to the scan, and every image loaded would need this information to go back to gantry coordinates.

This solution says lets keep the STIR origin the way it was, gantry based. But, lets define a new field for the image, the vendor origin, which allows vendor-reconstruction-consistent expression of geometry in LPS coordinates.

[ashgillman]

NB: #276

[KrisThielemans]

I haven't checked the code, but adding an "additional origin" (actually, should also allow for rotations, so will turn out to be a "transformation to LPS") seems to break too much stuff. I'd be reluctant to put something in place that only works for Interfile images saved by STIR.

It seems to me that images have to be in a coordinate system that is uniquely related to LPS, either directly in LPS, or (like our original plan and current code) by rotating stuff w.r.t. patient position. It's only once we start projecting that we need to know how to go from this coordinate system to gantry coordinates. That was our plan, and I still think it's the best.

This implies that someone knows how to do this transformation of course, which we hoped to be projection/listmode data.

May be better to continue the discussion at #223