number of views in subsets can be very unbalanced

This was originally https://github.com/CCPPETMR/SIRF/issues/214. See there for more info.

When you run OSMAPOSL, STIR will check that subsets are balanced (in terms of #views only of course, not stricly in terms of equal subset-sensitivities). For other algorithms, this is not a requirement, so it won't do that check (I believe STIR writes a warning). @mehrhardt, I'm guessing that your algorithms doesn't need balanced subsets...

The subset scheme in STIR was developed for when the number of subsets does divide the number of views. With default settings for the projector, it's actually a bit more complicated, as it puts views that are related by symmetry inside the same subset. This means that usually you have that num_subsets needs to divide num_views/4.

I have never spend any time on checking what happens with the subsets for other cases. I know the code doesn't fall over, but that's about it! The actual code is here.

Clearly, what you see is not desirable, but this code is really is basic as it gets. I guess therefore that the effect that you see is due to surprises with the symmetries.

I'm not sure what we could do to resolve this.

Start with src/recon_buildblock/find_basic_vs_nums_in_subset.cxx and the original issue 214. Investigate how non-divisible view counts and projector symmetries produce unequal subsets, then establish the expected behavior for algorithms other than OSMAPOSL. Done requires an agreed resolution and corresponding implementation for the imbalance.