Simon Biggs
> I guess the rule then, is that whenever we have public facing APIs that use dose, or gamma, or another 3D array we just always also require as a...
> * It's still useful to include both **orientation** and **coordinate system** Yup, I'm sold. > Moreover, I guess it's more memory efficient We could get the best of both...
Essentially the rule would be that we always provide the meshgrid or equivalent coords tuple (name it `grids`?) And we also pass around a named orientation object (an Enum containing...
Or, instead of a name for orientation, we could copy DICOM's orientation tuple? 6 numbers between 0 and 1.
...and we could get the best of both worlds by making a tuple based Enum where HFS actually corresponds to DICOM's equivalent orientation tuple.
Yup, oops, between -1 and 1 (inclusive). Yup tuple based Enum would work quite nicely I think...
So... Next question... Are we wanting to support a gamma function where the reference grid is one arbitrary orientation cosine tuple, and then the evaluation grid is potentially in another...
> And reject (in the code) if unsupported orientation combinations are detected... That would require that the orientation Enum for each dose grid is input into the function. If we're...
(contradicting my precious statement about requiring it everywhere) Edit: but doing so, so as to prod and probe the idea of, if we're not making use of orientation, and if...
I'm not sure why we're choosing [k, j, i] order. That has me a little confused. Potentially I'm missing something here. I'm also wondering if we in general support the...