LOR randomization in SAFIR input file format

[jafische]

Dear Kris, dear all,
I have add a little feature to the SAFIR listmode input with the virtual scanner. With the new feature, endpoints of the LORs can be randomized with a Gaussian random number. This makes the image quality much better and the class actually much more useful. A lot of geometric artifacts vanish if this randomization is employed. I think it would make a good addition to the class also in the official STIR repo.
Kind regards
Jannis

[jafische]

Two builds are failing because I use C++11 functionality. What is the current policy on that?

[KrisThielemans]

Our announced policy is that C++11 is for STIR 5.0. However, I think that'll come really quickly, so I'm happy to switch off those Travis jobs once 4.0.0 is out.

[jafische]

@KrisThielemans OK, great. Let's do it as you said.

[KrisThielemans]

@jafische could you merge master? Should now be C++11

[jafische]

@KrisThielemans: Done. Let's see, what Travis says.
You also mentioned we could add this feature to a more generalized place in the code. My impression is, that it might make sense to add it there, where the ray tracing with several parallel rays per LOR is done. We could randomize the start and end points of these rays.

[jafische]

@KrisThielemans: The g++5 builds still fail. I suppose, they need compiler flags -std=c++11

[KrisThielemans]

@jafische could you update this PR again? should work now I hope.

Does this interfere with #577 ?

The problem with LOR randomisation is that it will break symmetries, so enlarge the projection matrix, in most cases to unmanagable dimensions, such that caching has to be switched off. This currently probably doesn't have a large impact on run-time, unless you start using more LORs. But of course, it could be an interesting option to add. It's going to be a bit harder than hoped, as there's currently no mechanism to find detector locations in Scanner, so ProjMatrixUsingRayTracing currently has to compute this itself, which leads to ugly code.

[jafische]

@KrisThielemans, sorry for the delay, a lot on my plate recently. Anyhow, addressing your questions in the last comments:

• This should not interfere with block and generic scanner geometry  #577 and also not with the symmetries as it is, because this merely randomizes a coincidence event (i.e. the endpoints of a single event LOR). This is then sorted in the virtual cylindrical scanner projection data, which is perfectly symmetric.
• If we generalize this and do it in the ray tracer, this will certainly break symmetry. I have no immediate smart idea on how to solve this.
• Maybe this can be done on projection data level, not physical space? If the bin size is sufficiently small, the following might work: decide by drawing a random number to use a neighboring LOR for calculating a certain event. No additional rays to be traced and symmetries still hold.

[KrisThielemans]

@jafische sorry, forgot to ask if you could add 1 line in release_5.0.htm. Ideally you also 1 line in the copyright headers (it still says 2015 ETC).. Please commit with [ci skip] in the first line of the message.

[jafische]

@KrisThielemans Done.

[KrisThielemans]

great. ok to squash-merge? (this is problematic if you've used this branch somewhere else already)

[jafische]

@KrisThielemans : Squash-merge is OK for me.