[SciPy-Dev] Contribution: Estimating the overlap of a ray with volume-cells (voxels) for e.g. tomography

[Matteo Ravasi]

Hi Sebastian,
I also looked into your package, ans I agree it would be a very nice addition to scipy.

Just one question: in tomography it is common to know the start and end points of a ray and they may lie somewhere inside the grid extent. In your library I seem to be able to only have rays that cross straight through the grid as they can only be parametrized by only their support and angle. While this parametrization can be inferred from start-end point, being able to have rays within (but not all the way through the grid) would definitely make your routine more general and applicable to various problems - then more suited to scipy.

Am I missing anything? Or do you think this feature could be easily added without changing the current code base too much?

Thank you!
iMR

> On 15 Oct 2019, at 15:51, Ralf Gommers <ralf.gommers at gmail.com> wrote:
> 
> 
> 
> 
>> On Mon, Oct 14, 2019 at 1:45 PM Sebastian A. Mueller <sebastian-achim.mueller at mpi-hd.mpg.de> wrote:
>> On 2019-10-12 17:53, Ralf Gommers wrote:
>> > Hi Sebastian,
>> > 
>> > On Tue, Oct 8, 2019 at 1:33 PM Sebastian A. Mueller
>> > <sebastian-achim.mueller at mpi-hd.mpg.de> wrote:
>> > 
>> >> Dear scipy,
>> >> 
>> >> I wrote a package to estimate the distances a ray overlaps with
>> >> volume-cells in three dimensions. This is needed to estimate
>> >> system-matrices in tomography. The interface is only one function.
>> >> It
>> >> takes the ray's support and direction vectors, and the bin-edges for
>> >> the
>> >> space partitioning. It returns the overlaps of the ray and the
>> >> voxels.
>> >> The space-partitioning must be rectangular, but it does not need to
>> >> be
>> >> equally spaced. In combination with scipy.sparse, it can efficiently
>> >> 
>> >> create system-matrices for iterative, tomographic reconstructions.
>> >> The
>> >> algorithm uses oct-tree-traversal for efficiency.
>> >> 
>> >> On pypi:
>> >> https://pypi.org/project/ray-voxel-overlap/0.0.2/
>> >> 
>> >> On github:
>> >> https://github.com/cherenkov-plenoscope/ray_voxel_overlap
>> >> 
>> >> I would like to contribute this to scipy. It addresses multiple
>> >> fields
>> >> in science such as medicine, biology, microscopy, physics,
>> >> astronomy,
>> >> geo-earth, image-processing.
>> >> At its core, it is pure linear algebra. My package contains a pure
>> >> python-implementation for development and testing, and a (much
>> >> faster)
>> >> C-implementation wrapped in cython.
>> >> 
>> >> Do you think such a tool belongs into scipy? If not, where else
>> >> should
>> >> it go?
>> > 
>> > It could fit in the scope of SciPy. We don't have much other
>> > functionality like it though.
>> 
>> Maybe it fits into scipy.spatial, next to functions such as 
>> scipy.spatial.distance_matrix. This one has also a compact interface, 
>> and also solves a spatial problem.
>> 
>> > My first thought was that it perhaps
>> > fits better in scikit-image, which already has a 2-D radon transform:
>> > https://scikit-image.org/docs/dev/auto_examples/transform/plot_radon_transform.html.
>> > Does that make sense?
>> 
>> Yes, the 2-D radon-transform in scikit-image is related to this. But the 
>> spatial overlap of a 3-D ray with volume-cells in a 3-D grid is more 
>> general than just tomography. The compact interface might allow users 
>> outside the tomographic-mindset to reuse it for non tomographic purpose. 
>> So what about adding estimate_overlap_of_ray_with_voxels() to 
>> scipy.spatial?
> 
> Looking at it again, I think a ray-voxel-overlap function could fit. Your code is pretty complex though for a single function. It seems to me that a lot of this complexity comes from the octree data structure. That's something we don't have in scipy.spatial, and has much wider applicability that just ray-voxel overlap. It would fit quite nicely next to cKDTree. 
> 
> The best looking octree implementation in Python I can find so quickly is https://github.com/mhogg/pyoctree. How does your implementation compare to that? If the latter is faster or more general, would you be able to build on top of it?
> 
> Cheers,
> Ralf
> 
> 
> 
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20191016/7f79ef04/attachment.html>