Bug in `utils.compute_angle_weights_1d`

[ri-imaging]

Bug in `utils.compute_angle_weights_1d`

[paloha]

@paulmueller thank you for looking into this.

Yes, I disabled weighting. I just wanted to report the behavior I found odd when I was testing this function out.

In the point 1., I understand that 180° must be covered for a proper reconstruction, unfortunately, this is not what you can measure in a real microscope. Case 2. makes sense, OK. Case 3. looks like a bug indeed. Might be just solved by raising an error, because I also can not imagine a case where somebody would actually have coverage >180°. Cheers

[paulmueller]

Maybe the docs could also be clearer about point 1.

[paulmueller]

I will try to explain what is happening:

1. It is assumed that a full 180° must be covered for a proper reconstruction. The idea is to give each angle a weight that is proportional to the distance to its neighboring angles. Obviously, this idea does not work if the angles are strongly unevenly distributed (e.g. dense coverage from 0° to 90°, nothing between 90° and 180°). But it works for the example cases in the docs. This basically answers the behavior in case (1).

2. For case (2), this also makes perfect sense. If there are two angles at the same location, then the corresponding recordings only get half of the weight.

3. Case (3) might actually be a bug. The coverage of the weights is larger than 180° and this case is probably not treated well.

For your -60°/+60° case, you should probably disable weighting the angles (if they are evenly distributed). Otherwise, I would be open to introducing another keyword argument that defines the desired spread of the angles...

Cheers!