jwbuurlage
commented
5 years ago I have to think about this in more detail, but I will put some initial thoughts here.
The main reason for the cubic box is because of the way slice reconstructions work.
- There is no 'full' geometry made. Instead of taking the full geometry, we only define it for the central (axial) slice. In other words, the active ASTRA volume geometry is always one voxel high.
- If we want to reconstruct a different slice then the central one with an arbitrary orientation, we rotate the entire geometry so that this other slice gets transformed to the central slice. If we then run the algorithm to reconstruct the central slice, we are actually reconstructing the slice with the arbitrary orientation.
- This avoids having to reallocate memory, or changing geometry. The only thing we are doing is changing the vectors of the
ConeVecandParallelVecgeometry, which can be done cheaply. It does mean that the resolution (and shape) is fixed to the original resolution of the central slice.
However, this restriction is only put on the reconstruction side. In fact, there is already support in RECAST3D for non-cubic volumes. This is activated simply by sending a GeometrySpecificationPacket to RECAST3D. See GeometryProtocol::process in RECAST3D for details.
Currently, a data adapter sends such a package to SliceRecon, but SliceRecon does not send this through to RECAST3D (because we force cubic volumes for now). If you want to take a stab at this:
visualization_servershould send aGeometrySpecificationPacketto RECAST3D.- We should either have a convention for deciding which resolution slice to reconstruct for a given orientation, or be able to change the 'slice geometry' on the fly.
I'm not sure if this is an issue for SliceRecon or RECAST3D. RECAST3D draws a cubic box irrespective of the z-direction in the geometry packet specification.
This is not really a direct problem, as the remainder of the box is filled up with a blank slice, but would be nice to have!