Option for reconstructions from a moving time window

[adriaangraas]

Currently the reconstructor starts building slices after receiving a full projection series of size --group-size, and then waits for the next full batch. It would also be nice to have a "continuous mode". The reconstructor should then builds slices after receiving each (or a given a mount of) new projection(s).

The nice thing is that we then have more reconstructions in time, which gives higher refresh rates, but it requires that data is acquired in a continuous fashion (no gaps in time).

[jwbuurlage]

I think this could be a nice addition. The modes have a number of parameters.

• group_size. How many projections should be processed together.
• update_every. The number of projection to process before the reconstruction is updated (currently identical to group_size.
• projection_count. The number of projections in the acquisition geometry.

The two modes should be the following two:

• Alternating. This is should be the default mode. There are two buffers. One buffer is used for reconstruction, while the other is used for partially received and processed projections. When a full projection set (of projection_count projections) has been received, the two buffers swap roles. This means that reconstruction is always from the most recent projection data corresponding to a full rotation.
• Continuous. There is a single buffer. Every time update_every projection have been received, a new reconstruction triggers. At any point in time, for each angle the most recently received projection is used for the reconstruction.

In either mode, incoming projections are queued until at least group_size have been received, which are then processed and uploaded together. For continuous, there should probably be a lock around all CUDA calls while a new group is being uploaded.

Currently, the mode is a hybrid version. During the first rotation we have a continuous mode, while after that it uses an alternating scheme.

To implement this:

• [ ] We would need to add a update_every flag to slicerecon::settings.
• [ ] Add a new enum slicerecon::mode with continuous and alternating variants.
• [ ] The behaviour in reconstructor::push_projection should depend on which mode is set.
• [ ] We would need more clear trigger points for notifying the visualization server that new data is available. Currently, this is done here when a group has been processed (should be done after upload_every), and here if we want to update the 3D preview as well.

[adriaangraas]

Okay, so this all is implemented in #8.

• Alternating mode is the default, --continuous has to be set to explicitly enable the continuous mode. If so, --update-every is in work, if unset it defaults to --group-size. If bigger than --group-size, the projections are processed every --group-size but not uploaded to the GPU.
• Continuous mode locks the GPU at upload times, with a mutex, to prevent reconstructions from happening while projections are written to memory.
• It makes sense to choose --update-every as a multiple of --group-size but this is not necessary.

The implementation seems reasonably stable to me, although the implementation gets a bit hairy with all the different indices and offsets. Might be convenient to write a good abstraction for this later.

Would you like to have a look at this?