General inquiry

[Dale-Black]

This package already looks impressive, so I was wondering your goals for this sort of package? I work with CT imaging physics for my Ph.D. and if this is something you plan on spending a lot of time on, I would be interesting in collaborating wherever possible.

I am very interested in having something like KomaMRI.jl for CT and this seems like a good starting point - and maybe something like https://github.com/xcist/main could be useful for that goal.

Do you have any larger goals like that for this package?

[roflmaostc]

Hi!

Thanks for reaching out!

I'm using this package for Tomographic Volumetric Additive Manufacturing and definitely will keep maintaining it for the next time.

I also pitched this package once to @tknopp and @JeffFessler who are both also working with Julia and CT datasets.

For me most important was the attenuated Radon transform which models that a beam in the back projection gets attenuated.

Given its simplicity it's cool to see that with cuda it has descent performance.
However, torch-radon is much faster but not as flexible as this package.

So is there anything where I can support your application? I also tried to make the API flexible such that we can potentially include different geometries easily, but I like also this lightweight and simple API it currently offers.

[tknopp]

Hi, I currently don't have time to actively contribute to the CT packages but I have two comments:

• It would be cool if Sinograms.jl and RadonKA.jl could share a similar high-level interface such both could be exchange. Alternatively, one might want to consolidate at some point and make single strong package. In any case, it would be nice to share geometry structs and interfaces.
• @nHackel is currently making great progress in making RegularizedLS, LinearOperators, LinearOperatorCollection and MRIReco/MPIReco aware of GPU computing. Not just CUDA but also AMD and hopefully also Metal. Some background information is here Add GPU support to MRIReco.jl MagneticResonanceImaging/MRIReco.jl#182 From my point of view, this already looks very, very good, since the infrastructure is super flexible and you can combine many iterative algorithms and regularization terms freely. Having said that: It would be absolutely awesome, to get a CT linear operator. I know @roflmaostc you had this in some example. Would be really cool if that would be implemented. Probably as a package extension.