box shape needs better definition

[KrisThielemans]

PETSIRD/model/GeometryInformation.yml

Lines 39 to 47 in edcd0af

	# A box-shape specified by 8 corners (e.g. cuboid, wedge, etc.)
	# TODO need to think about a clear definition of planes
	# We do not want to have to check about intersection planes
	# Potential mechanisms:
	# - lexicographical ordering of corner coordinates?
	# - first 4 coordinates give first plane, 5th and 6th need to define plane with first 2, etc.
	BoxShape: !record
	fields:
	corners: Coordinate*8

[MaxTousss]

After some reflection, I believe that it might be better to change the representation to be more restrictive in order to lighten the burden of defining how 8 vertices can produce what is needed for a projector. Here is my attempt to describe coherently what I believe might be a good enough description of a detection element for PET reconstruction.

Objective: Define a detector in the PETSIRD format

Context:

The definition will be used to describe the detectors as seen by the reconstruction engine, not the scanner.
Thus, it should provide easy access to the information needed by a given projector.

Requirements:

Information that can be needed by a given projector:

• Centroid (e.g., Siddon and Jospeh)
• Direction of the "Depth" (To take into account mean depth of interaction)
• Dimensions (e.g., multi-Siddon and Distance Driven)
• Unsure: The "front" face

Types of detectors to consider:

Different types of scanner detector

• A) Most typical geometry.
• B) Similar to A, except it is cut straight into one of its dimensions
  • The red lines are parallel.
• C) Prism-PET with optical prism on the "front" face (orange) and tapered end (green).
  • Both are most likely ignored in the modelisation process.
• D) Semi-monolithic that fills the gap induced by a scanner being polygon shaped in transaxial.
  • The virtual detectors used for reconstruction would be similar to either A or B.
• E) Detection material shaped into portions of a tube.
  • "Back" face is larger than the "front" face.
  • Curvature of the "front" and "back" face is most likely ignored in the modelisation process.
• F) Side-readout (TOF or light-based)
  • The virtual detectors for reconstruction would be similar to A.

Observations + decisions:

• All the faces can be assumed rectangles.
  • Curved in one direction for case E but might not be that relevant.
• "Front" face can be non-parallel to the "back" face. (Case B, D).
  • In that case, at least two of the "front" face segments are parallel to the "back" face. (See red line in case B).
• Normal of the "back" face is almost always perpendicular to the scanner axial direction
  • The half-sphere scanner is the only exception for clinical, I think?
• The "front" and "back" faces are always connected "directly" (in the sense of straight prism)
• "Back" face is equal or larger than the "front" face.
  • Only relevant for case E.
• Small cut-out and optical interfaces in case C are probably small enough that they can be ignored.

Proposal:

Attempt to describe the proposal using "accurate" geometric terms:

• Right square frustum but it can be cut along one direction for the front face.

Attempt to describe the proposal by how it is constructed:

• Two rectangles positioned such that...
  • , for at least one rectangle, the line starting from its centroid and going in the direction of its normal intersects the centroid of the other. (e.g., straight prism)
  • at least two segments of the first rectangle are parallel to two segments of the second. (i.e., not a twisted prism)
• The convex hull obtained from the vertices of both rectangles describes the detector’s volume.

Encoding:

Currently:

• 8 vertices:
  • 8 x 3 floats.
  • Note: ordering the vertices seems complex without a fixed reference.

Proposals:

• Centroid of the volume
• Depth direction with its norm being half the depth
• "Front" face and "back" face (relative to image FOV):
  • "Width" and "Height" direction to form the rectangle, with their norm being half the "width" and "height" of the faces

Advantages:

• 6x3 floats
• Depth direction is directly available
• Vertices are simply center +/- vec1 +- vec2 +/- vec3
• Detector size is 2 * ||vec_i||
• Save some computation, since only the center needs to be translated (if rotation is applied first in the current system?)

Notes:

• Could remove one direction and changes to a scaling factor, since we enforce partial parallelism between the two faces
• Most detectors are straight, we could have two types, where the basic one only needs 3 vectors.

Validations (Not finished)

• Before placement:
  • Straitghness:
    • The depth direction should be parallel to the vector connecting the centroid of the "front" and "back" faces.
    • The normal of the "back" face should be parallel to the depth direction.
  • Rectangle faces:
    • The two directions of the "front" and "back" faces should be parallel.
• Once placed:
  • Direction of the detector:
    • "Front" face should be nearer to the scanner center of mass than the "back" face.
    • The angle between the scanner’s axial direction and the depth direction should be less than 90 deg.
  • Not twisted:
    • at least one of the directions that defines the "Front" face is in the same direction as one of the directions that defines the "back" face.
    • The angle between the other direction of both faces should be less than 90 deg

Additional considerations:

• Defining the axial direction of the scanner would cost only 3 floats and simplify the geometric validations.
  • If the scanner three axes are provided, the scanner spatial definition could be encoded and thus used.
• The center of the scanner might also be of interest for motion correction.

[KrisThielemans]

Thanks @MaxTousss. Hopefully we will discuss this in our data elements group in 2 weeks.

[KrisThielemans]

Note that currently we usually have only 1 box (so its size is negligible), but a transform for every "element" in the module (4x3 floats) (and a transform for every module). The "within module" transform could be simplified if we allow only translation (and maybe 1 rotation), at the expense of a more complicated specification, but easier "understanding" of the geometry.

Also, a projector that needs some kind of "centre" could compute this once for the box, and then just transform it to different places.

[KrisThielemans]

Another alternative to current scheme with transforms, based on OBJ:

• supply a list of vertices (x,y,z)
• for every box, provide a list of vertices (8 uints)

This could for instance be used to create a "module" (as opposed to have a list of transforms of 1 box).

Advantage over current scheme:

• it's easier to figure out with uints which vertices are identical (i.e. which crystals are neighbours) than trying to check this from the transforms (and the box)
• uints will compress far better than floats.

Disadvantages:

• without compression, it seems to need a little more space (currently 4x3 floats (= 12x4 bytes) per "crystal" for the transform), vs in most cases 2x3 floats and 8 uints (= 12x4 bytes) for "internal" crystals which share all vertices with its 8 neighbours, but on average a bit more due to edges
• it would need more computations to figure out the centre of each crystal.

[MaxTousss]

I had never looked at the OBJ format until today, but it seems that it will bring more complexity than advantages.

If my understanding is correct, for a module with 4 x 8 detectors where we assume the gaps are negligible, you would need 5 x 9 x 2 vertices and 8 x 4 x 8 uints, which is not that bad. However, it requires the person creating the geometry to create those uints which can be done in several ways without changing the outcome. This does not seem to be a feature for the reconstruction people that want to use it after that.

For example, let's say that the first detector is defined by the uints 1 to 8. Then, he could write any permutations of 1 to 8 and the results would be the same, which add a layer of complexity to finding its neighbors. Thus, we would need to define THE way to set the uints, which brings us back to the current implementation problem: how should the 8 vertices be defined.

Also, it shares a potential pitfall with the previous definition: we call it "box" shape but both allow the creation of clear non-box-shaped objects.

[KrisThielemans]

Agreed that OBJ doesn't seem the way forward, but it was mentioned by Adam before, so I thought it'd warrant another look. The associated non-uniqueness (worse than in the correct proposal) seems to be a problem.

[MaxTousss]

Here is an updated version. Not sure if I should have simply modified the previous post, but it would mess the discussion history. Thus, I decided to use the Github "outdated" flag on the previous post so that future reader don't "waste" time with the previous version but that they can read it, if needed.

The new version simply add more context/details and a section about response to previous comments.

Objective: Define a detector in the PETSIRD format

Context:

The definition will be used to describe the detectors as seen by the reconstruction engine, not the scanner.
Thus, it should provide easy access to the information needed by a given projector.

Requirements:

Core: it must be...

• able to represent most types of detectors (as seen by the reconstruction process)
• (relatively) easy to define for the user
• straightforward to validate

Information that can be needed by a given projector:

• Centroid (e.g., Siddon and Jospeh)
• Direction of the "Depth" (To take into account mean depth of interaction)
• Dimensions (e.g., multi-Siddon and Distance Driven)
• Unsure: The "front" face

Concerns over the current definition:

• Too much liberty is provided in the definition of the detector vs what is used in the reconstruction process (Named a box but could be used to "draw" an octagon)
  • More rules are needed to ensure this does not happens
• The orientation of a detector relative to the scanner center is complex to extract (Currently, we need to know the positions of multiple detectors to get it?)

Types of detectors to consider:

• A) Most typical geometry.
• B) Similar to A, except it is cut straight into one of its dimensions
  • The red lines are parallel.
• C) Prism-PET with optical prism on the "front" face (orange) and tapered end (green).
  • Both are most likely ignored in the modelisation process.
• D) Semi-monolithic that fills the gap induced by a scanner being polygon shaped in transaxial.
  • The virtual detectors used for reconstruction would be similar to either A or B.
• E) Detection material shaped into portions of a tube.
  • "Back" face is larger than the "front" face.
  • Curvature of the "front" and "back" face is most likely ignored in the modelisation process.
• F) Side-readout (TOF or light-based)
  • The virtual detectors for reconstruction would be similar to A.

Observations + decisions:

• All the faces can be assumed rectangles.
  • Curved in one direction for case E but might not be that relevant.
• "Front" face can be non-parallel to the "back" face. (Case B, D).
  • In that case, at least two of the "front" face segments are parallel to the "back" face. (See red line in case B).
• Normal of the "back" face is almost always perpendicular to the scanner axial direction
  • The half-sphere scanner is the only exception for clinical, I think?
• The "front" and "back" faces are always connected "directly" (in the sense of straight prism)
• "Back" face is equal or larger than the "front" face.
  • Only relevant for case E.
• Small cut-out and optical interfaces in case C are probably small enough that they can be ignored.

Proposal:

Attempt to describe the proposal using "accurate" geometric terms:

• Right square frustum but it can be cut along one direction for the front face.

Attempt to describe the proposal by how it is constructed:

• Two rectangles positioned such that...
  • , for at least one rectangle, the line starting from its centroid and going in the direction of its normal intersects the centroid of the other. (e.g., straight prism)
  • at least two segments of the first rectangle are parallel to two segments of the second. (i.e., no twisted prism)
• The convex hull obtained from the vertices of both rectangles describes the detector’s volume.

Encoding:

Currently:

• 8 vertices:
  • 8 x 3 floats
  • Note: ordering the vertices seems complex without a fixed reference

Proposals:

• Centroid of the volume
• Depth direction with its norm being half the depth
• "Front" face and "back" face (relative to image FOV):
  • "Width / transaxial" and "Axial / the remaining one" direction to form the rectangle, with their norm being half the "width" and "height" of the faces

Advantages:

• Centroid is directly available (vs computing COM of the current definition)
• Depth direction is directly available
  • Position of the mean depth of interaction is also simple to get
• Vertices are straightforward to compute
  • center +/- vec1 +- vec2_{f/b} +/- vec3_{f/b}
• Detector size is 2 * ||vec_i|| in most cases
• Save some computation, since only the center needs to be translated (if rotation is applied first in the current system?)
• Validation of the geometry is kinda straightforward (see Validations section)
• 6x3 floats
  • 3x3 floats if box is considered enough

Potential simplification of the proposal:

• Could remove one direction and changes to a scaling factor, since we enforce partial parallelism between the two faces
• Most detectors are straight, we could have two types, where the basic one only needs 3 vectors.

Response to comments:

• Complexity for the user to use the proposal
  • If one knows the 8 vertices of a detector in their scanner, it is easier for them (vs the standard) to extract its directions
• Box is easy to visualize and can be easily interpreted in GATE
  • The current definition is not a box and GATE's box does not provide the detector orientation
• Restrictions on the geometry transform would make the current definition easier for the projector
  • The current proposal would make it trivial

Validations (Not finished)

• Before placement:
  • Straitghness:
    • The depth direction should be parallel to the vector connecting the centroid of the "front" and "back" faces.
    • The normal of the "back" face should be parallel to the depth direction.
  • Rectangle faces:
    • The two directions of the "front" and "back" faces should be parallel.
• Once placed:
  • Direction of the detector:
    • "Front" face should be nearer to the scanner center of mass than the "back" face.
    • The angle between the scanner’s axial direction and the depth direction should be less than 90 deg.
  • Not twisted:
    • at least one of the directions that defines the "Front" face is in the same direction as one of the directions that defines the "back" face.
    • The angle between the other direction of both faces should be less than 90 deg

Additional considerations:

• Defining the axial direction of the scanner would cost only 3 floats and simplify the geometric validations
  • If the scanner three axes are provided, the scanner spatial definition could be encoded and thus used.
• The center of the scanner might also be of interest for motion correction

[KrisThielemans]

Not sure if I understand it yet, sorry. Centroid and direction are easy to understand, You then need to define 2 rectangles (or parallelograms I guess), which needs 2 unit vectors for each. Correct?

I'm not sure where the conceptual gain is here. Define the rectangle as 2 vectors or 4 vertices seems to have the same level of complexity. as the current proposal.
We could just as well say in the current proposal that the first 4 vertices specify the front face (i.e. closest to the scanner axis/centre), and the last 4 the back face (can impose some "clock-wise" order). That'd give you direction information as well. See below.

Also note that COM isn't necessarily a good value to use for projectors (it's off from "average detection position" for very long or very short crystals).

[MaxTousss]

My description might not be that clear, so do not hesitate!

The front and back faces would each be described as two vectors such that their norms give the size of the rectangles. The need for front vs back is to be able to represent case B, D and E.

The gain, in my view, is that it requires nothing else and to defines uniquely and almost explicitly the resulting volume. The current definition with 8 vertices allows too much freedom without any gain.

Indeed, we can add additional rules to the current definition to obtain equivalent results. However, it seems that it would be harder to validate. (You mention "see below", but I do not see anything. Is there something missing?)

I agree that "average detection position (ADP)" is better for the projector. However, said projector would be able to compute it from the COM + direction vectors. Well, I do not mind changing the centroid to ADP but we would need to add one or two floats. Also, the "box" shape definition has the same problem, albeit it requires more computing to get ADP.

[KrisThielemans]

ok, that helps. I think we're down to specifying how to represent these shapes.

Box proposal with specified order

• 8 vertices
• first 4 vertices specify the front face (i.e. closest to the scanner axis/centre), and could be required to be co-planar
• last 4 vertices specify the back face (i.e. furthest to the scanner axis/centre), and could be required to be co-planar
• actual shape to be considered convex hull of the 8 vertices (i.e., it's expected that other vertices are also co-planar, so we could require this as well, in which case we're really down to a box)
• direction can be infered from "centre of front face" to "centre of back face"
• first order average detection position (ADP) for orthogonal rays can be inferred from "centre of front face" + average_DOI * direction
• order of vertices within a face: clock-wise (around "direction" axis).
• first vertex of back face has to be the one closest to the first vertex of the front face

Still need to define what the first vertex is. I think this would be easiest to do together with the "transforms" (i.e. impose an order on the transforms of the "box" to place all of them within a "module"). This could use a similar order definition as the vertices: 3 (not orthogonal) axes are defined by vertex1 - vertex0, vertex3 - vertex0, direction. Transforms should be lexicographical order in this coordinate system. Can require that the transforms are "positive" , e.g. first vertex has to be (0,0,0), others have to be in the "right orthant" in that coordinate system. (or we can fix the COM to be at (0,0,0), of course)

validation

tricky, but this is our business, not the user's.

easy of use

I don't see a problem

Monte Carlo translation

seems obvious

[KrisThielemans]

Alternative using some vectors

in terms of above vertices

• define origin somehow
• 5 vectors needed: v0->v1, v0->v3, v0->v4, v4->v5, v4->v7

Note: more restrictive than "box" as v2 = v0 + (v1-v0) + (v3-v0), but I think this is what @MaxTousss has

No need to define COM and direction separately (the latter is similar to v0->v4, although not quite the same).