[Bug] Ambiguity for layer stack coordinate positions

[csparker247]

Layer generation with vc_layers or vc_layers_from_ppm uses the LineGenerator class to compute a vector of intensities for each pixel in the PPM, then saves each slice along those accumulated vectors as a separate image. Assumably, one could reconstruct the original 3D coordinates corresponding to each voxel in the layer stack like so:

pt = ppm[y, x, :3]
n = ppm[y, x, 3:6]
offset = layer_idx - num_layers // 2
pos =  pt + offset * n 

However, this calculation is only accurate if the radius value for the neighborhood is an integer value. Consider layer stacks generated with a radius of 1.2 and 1.5 (assumed bidirectional sampling):

interval = 1.
for r in [1.2, 1.5]:
  # floor(r - -r / interval) + 1
  num_layers = floor(r + (r / interval)) + 1
  # offsets = min_r + idx * interval
  print([-r + idx * interval for idx in range(num_layers)])  # [-1.2, -0.2, 0.8]
                                                             # [-1.5, -0.5, 0.5, 1.5]

With these values, the algorithm above for reconstructing the original position would be incorrect voxel:

for num_layers in [3, 4]:
  print([i - num_layers//2 for i in range(num_layers)])  # [-1, 0, 1]
                                                         # [-2, -1, 0, 1]

The reconstruction code above will overestimate radius values with fractional part $\{r\} \in [0.5, 1)$ by $1 - \{r\}$, while $\{r\} \in (0, 0.5)$ will underestimate by $1 - \{r\}$.

Unfortunately, I don't think the 3D positions in a layer stack can be exactly reconstructed without also recording the radius value used when generating the layers. As this is sometimes auto-determined from the voxel size and estimated layer thickness, it's not guaranteed to be an integer value.

I'm not sure that this is exactly a bug, per se, but something that should be documented and improved. I do think it would be helpful if the surface voxel was always exactly recorded when doing bidirectional sampling, but that would likely mean adjusting the requested radius in order to maintain a uniform sampling interval. Maybe that's fine? That seems fraught when the sampling interval is also not an integer, though.

Anyway, I'm willing to take thoughts or suggestions on this topic. Since the error is so small and easily solved with some bookkeeping, I don't think this is a critical issue, and we have some time to think about implications.