Reporting of phantom spatial sampling in obj.info structure.

[curtcorum]

Feature Request

Based on discussion from #319 and #311 issues can arise due to artifacts of Cartesian sampling on phantom and (especially) Cartesian sampling of spoiled steady state gradient echo sequences.

Providing information about the spatial resolution of the phantom can help users to choose simulation parameters that can avoid artifacts.

...we could have a dictionary where we can put relevant information for the phantom (obj.info similar to seq.DEF). Those parameters in obj.info should be optional, and not be necessarily defined in every phantom. For example, if the sampling is not cartesian the resolution variable could not make sense.

[curtcorum]

@cncastillo

After a bit of looking and thinking...

It seems like there are some issues to discuss and decide, current or potential.

Right now the phantoms are isotropic and homogeneous, i.e. one sampling parameter for 2 or 3 dimensions and the same parameter everywhere the phantom is defined (rho > 0).

The phantom structure implicitly allows anisotropic and inhomogenous sampling:

KomaMRIBase/src/datatypes/Phantom.jl

since the coordinates are an array of 2d or 3d points.

Adding two phantoms together could lead to an inhomogeneous phantom, where the sampling is different in different parts of the FOV. The combined phantom could have the larger sampling parameter (lower resolution) or an array, or list of parameters.

The phantoms could be allowed to be anisotropic and probably it is worth supprting anisotropic data for import, as well as for sub-sampling and up-sampling. Anisotropic sampling could speed up simulation when the sequence has anisotropic resolution, such as 2d multi-slice with thick slices and 3d anisotropic sequences 1x1x1.5 mm etc.

[curtcorum]

PR #342 adds the default and raw file sample spacing to the docstrings for brain_phantom2D(), pelvis_phantom2D(), and brain_phantom3D() functions.