odlgroup/odl: ODL 0.7.0

Abstract

This release is a big one as it includes the cumulative work over a period of 1 1/2 years. It is planned to be the last release before version 1.0.0 where we expect to land a number of exciting new features. What follows are the <strong>highlights</strong> of the release. For a more detailed list of all changes, please refer to the release notes in the documentation. Native multi-indexing of ODL space elements The <code>DiscreteLpElement</code> and <code>Tensor</code> (renamed from <code>FnBaseVector</code>) data structures now natively support almost all kinds of Numpy "fancy" indexing. At the same time, the spaces <code>DiscreteLp</code> and <code>Tensorspace</code> (renamed from <code>FnBase</code>) have more advanced indexing capabilities as well. Up to few exceptions, <code>elem[indices] in space[indices]</code> is always fulfilled. Alongside, <code>ProductSpace</code> and its elements also support more advanced indexing, in particular in the case of power spaces. Furthermore, integration with Numpy has been further improved with the implementation of the <code>__array_ufunc__</code> interface. This allows to transparently use ODL objects in calls to Numpy UFuncs, e.g., <code>np.cos(odl_obj, out=odl_obj)</code> or <code>np.add.reduce(odl_in, axis=0, out=odl_out)</code> — both these examples were not possible with the <code>__array__</code> and <code>__array_wrap__</code> interfaces. Unfortunately, this changeset makes the <code>odlcuda</code> plugin unusable since it only supports linear indexing. A much more powerful replacement based on CuPy will be added in version 1.0.0. Integration with deep learning frameworks ODL is now integrated with three major deep learning frameworks: TensorFlow, PyTorch and Theano. In particular, ODL <code>Operator</code> and <code>Functional</code> objects can be used as layers in neural networks, with support for automatic differentiation and backpropagation. This makes a lot of (inverse) problems that ODL can handle well, e.g., tomography, accessible to the computation engines of the deep learning field, and opens up a wide range of possibilities to combine the two. The implementation of this functionality and examples of its usage can be found in the packages <code>tensorflow</code>, <code>torch</code> and <code>theano</code> in the <code>odl.contrib</code> sub-package (see below). New <code>contrib</code> sub-package The core ODL library is intended to stay focused on general-purpose classes and data structures, and good code quality is a major goal. This implies that contributions need to undergo scrutiny in a review process, and that some contributions might not be a good fit if they are too specific for certain applications. For this reason, we have created a new <code>contrib</code> sub-package that is intended for exactly this kind of code. As of writing this, <code>contrib</code> already contains a number of highly useful modules: <code>datasets</code>: Loaders and utility code for publicly available datasets (currently FIPS CT, Mayo clinic human CT, Tu Graz MRI and some image data) <code>fom</code>: Implementations of Figures-of-Merit for image quality assessment <code>mrc</code>: Reader and writer for the MRC 2014 data format in electron microscopy <code>param_opt</code>: Optimization strategies for method hyperparameters <code>pyshearlab</code>: Integration of the <code>pyshearlab</code> Python library for shearlet decomposition and analysis <code>shearlab</code>: Integration of the <code>Shearlab.jl</code> Julia shearlet library <code>solvers</code>: More exotic functionals and optimization methods than in the core ODL library <code>tomo</code>: Vendor- or application-specific geometries (currently Elekta ICON and XIV) <code>tensorflow</code>: Integration of ODL with TensorFlow <code>theano</code>: Integration of ODL with Theano <code>torch</code>: Integration of ODL with PyTorch Overhaul of tomographic geometries The classes for representing tomographic geometries in <code>odl.tomo</code> have undergone a major update, resulting in a consistent definition of coordinate systems across all cases, proper documentation, vectorization and broadcasting semantics in all methods that compute vectors, and significant speed-up of backprojection due to better axis handling. Additionally, factory functions <code>cone_beam_geometry</code> and <code>helical_geometry</code> have been added as a simpler and more accessible way to create cone beam geometries.