Editing STIR FAQ (section)

= What are good settings for the reconstruction programs?=
This is unfortunately a very hard question to answer. Look for some advice on the mailing lists. Note that the STIR defaults are not optimal, and neither are the sample .par files (and most definitely not the .par files in the recon_test_pack). A few things that seems pretty clear:

== Should I change the default projectors used by the reconstruction? ==
For STIR 2.x, the default for the iterative reconstructions was to use a ray tracing forward projector and an incremental interpolating backprojector. This turned out to be a bad choice as these projectors are not matched, which creates problems (even if the incremental backprojector does work on your system, see the known problems). It's probably best to use matched projectors, and the easiest way to do that is to use a "matrix". The fastest is the ray tracing matrix. This is the default projector since STIR 3.0.

However, this is still not ideal as this defaults to using only 1 ray per bin in the sinogram. This can create discretisation artefacts in high count situations. For the iterative algorithms, you should therefore probably use something like this in your .par file:
<pre>
projector pair type:= Matrix
Projector Pair Using Matrix Parameters:=
  Matrix type:= Ray Tracing
  Ray tracing matrix parameters:=
    number of rays in tangential direction to trace for each bin:= 10
  End Ray tracing matrix parameters:=
End Projector Pair Using Matrix Parameters:=
</pre>
For the analytic algorithms, using a ray tracer as backprojector can create (other) discretisation artefacts. You can alleviate this by using more rays, but in 3D, the ray tracing matrix doesn't take a Jacobian into account (as you don't have to for iterative reconstructions). Either stick to the default interpolating backprojector, or use its matrix equivalent. See the User's Guide.

== How many subsets should I use? ==
If you can afford to wait: 1. Otherwise as small as possible. However, because the STIR projectors use symmetries (unless you switch them off)
the number of subsets needs to divide ''number_of_views/x'' where ''x'' is 4,2 or 1
depending on which x gives you an integer number in the division (when using
all symmetries). For example, if you have  210 views, x=2, so you could use 1,3,5,7 and
their multiples that still divide 105.

== Which regularisation method should I use? ==
Kris Thielemans doesn't like "early stopping". Post-filtering is straughtforward (but you need to iterate longer than you think). You can use inter-iteration filtering or penalised reconstruction, but be aware that these create non-uniform resolution/regularisation. This is well-known in the literature, and can be fixed in STIR, but the relevant code is not yet available. (Remember also that OSL can diverge in noisy cases when the regularisation is too high).

In any case, you should normally not mix different regularisation methods (unless you know what you're doing of course).

== What "penalisation factor" should I use for a particular prior? ==
This is entirely prior and data dependent. Think about it this way. The
objective function is something like
<pre>
Log-Poisson-likelihood + penalisation_factor * prior
</pre>
where the prior is image-dependent.
The log-Poisson is proportional to the projection data, and so is the
(STIR-) reconstructed image.
=== Quadratic Prior===
The QP prior is essentially (image_differences)^2, therefore the prior is proportional to (projection_data)^2. This means that
if you want to have the QP to achieve count-independent
smoothing, you have to make the penalisation factor inversely-proportional to the counts.

One way to fix this is to use the "uniform resolution weights for the QP"
from Fessler et al. That's currently not distributed with STIR however. So,
I'm afraid you're down to tuning things for your data.

=== Median Root Prior ===
Although there is not really a prior function for MRP, its gradient is independent of the image-scale, and the gradient of the log-likelihood is independent of counts as well (after enough iterations). Therefore, the effect of MRP is not count dependent like QP. However, it does depend on sensitivity/attenuation etc. You can use the "multiplicative form" of the
update (see the User's Guide and http://dx.doi.org/10.1109/NSSMIC.2001.1008688) to avoid this (in which case 1 is a high
penalty), although the "additive form" of MRP is in principle better as it has higher influence where the sensitivity is lowest (note that MRP with large penalty is hampered by convergence problems when using OSL).