Possibility to cache projection data?

[kohr-h]

I'm currently playing around with FBP stuff, reconstructing only single arbitrary slices. To speed up computations, it would be nice if a backprojector could cache projection data in ASTRA memory via an extra option. The suggested implementation would be dead simple, namely

• exposing the feature only in RayBackProjection (off by default)
• storing the data ID from the ASTRA memory manager after the first call, not deleting it
• storing a reference to the data in the last call
• in the next call, if x is stored_x then use the existing memory, else delete the object and store new. Kind of a LRU cache
• add a method to clear the cache

Thoughts on that?

[ozanoktem]

In usual CT applications the FBP/FDK reconstructions are processed as soon as data starts streaming in, so one essentially has a 3D reconstruction when the data acquisition is finished. For adaptive CT where the geometry is to be adapted, I guess such treatment is a necessity.

[kohr-h]

In usual CT applications the FBP/FDK reconstructions are processed as soon as data starts streaming in, so one essentially has a 3D reconstruction when the data acquisition is finished.

That would be a cool feature, but we don't have support for streaming protocols in ODL. So we always have a dataset when we start reconstructing.

For adaptive CT where the geometry is to be adapted, I guess such treatment is a necessity.

Yes, so at the current stage it's mainly a tool for experimenting, basically to test how fast you can get with single slice reconstructions. I'm testing it on FBP but nobody says you can't use the same approach for iterative or variational methods.

[adler-j]

I feel that this should not go into RayTransform, but it would do very fine when we at some point implement "AstraRayTransform" according to #152.

Edit: Posted too soon.

Reasoning behind this is that this is a very specific feature that will be hard to keep updated and working for all cases. It would be much easier to keep this in a low level interface. Also, the doc would become worse than it is currently.

[adler-j]

With regards to AstraRayTransform, PR #802 implements something just like this and may be a good place to start.

[adler-j]

Will this ever be done?

[kohr-h]

How badly do we need it? I have the feeling that "cache everything in GPU memory" doesn't cover that many use cases where speed is an issue. Everything has to fit, which is limiting.

In the long run, wouldn't a memory pointer and ASTRA's Gpulink interface be the best way to handle this?