About gsoc

[xiaoerlaigeid]

I have check this library and find in this library only have on function radon transform. I wonder what's the plan to add more new features? I am glad to help.

[timholy]

Do you have particular reconstruction algorithms you're interested in? Your stereo matching idea (JuliaImages/Images.jl#878) is a form of reconstruction, right? Are there any simpler ones you're interested in? For deconvolution there is https://github.com/computational-imaging/ThreeDeconv.jl; I haven't played with it, though.

Another way to get involved might be the ImageFeatures.jl package, especially if you'll need feature-correspondence for your matching work.

[xiaoerlaigeid]

@timholy Thanks for replay! Actually I also have done some CT reconstruction algorithm, I think Julia is a suitable tool to implement the reconstruction algorithm. I think I could try to add some classical reconstruction algorithms and basic util functions. For example sinogram, back-projection algorithm etc.

[kczimm]

@xiaoerlaigeid I appreciate your willingness to contribute to this repository! A great start might be to implement the algorithms in Kak and Slaney Chapter 3 and 6, 7, and 8. You could add @timholy implementation for the radon transform or you could implement the nice radon algorithm described in this paper called Fast parallel x-ray transform and its adjoint by Hao Gao.

[xiaoerlaigeid]

@kczimm I have been implemented a sinogram function with the help of @johnnychen94. https://github.com/xiaoerlaigeid/ImageReconstruction.jl In the next step, I plan to add @timholy implementation into this library. By the way, If I plan to implement some basic reconstruction algorithms including paper. Could this fit for the GSoC project workload?

[kczimm]

@xiaoerlaigeid great work so far. It looks like your sinogram function is another implementation of radon. So if you add @timholy implementation from Discourse we will have three unique implementations. This will be a theme in this package where functions will have possibly many different algorithmic implementations and we will need to come up with an API that can nicely accommodate this.

I’m not familiar with the workload for GSoC as I have no experience with the program. Perhaps @timholy or @johnnychen94 have insight into this.

The paper actually has several aspects which maybe some could be within scope but not all? The aspects can be broken down into 2D and 3D, pencil beam and finite beam, and CPU and GPU versions. For the finite beam, we will need to create some concept of the geometry of the imaging system (so we can have fanbeams as opposed to parallel beams). A good start may be just the 2D, pencil beam, CPU version. This would be yet another implementation of the radon function.

[johnnychen94]

we will need to come up with an API that can nicely accommodate this.

JuliaImages/juliaimages.github.io#113 (comment)

There're many in the wild, but here're packages I know that use the functor API:

• ImageBinarization
• ImageContrastAdjustment
• Distances/ImageDistances
• ImageQualityIndexes

Could this fit for the GSoC project workload?

If it's about adding algorithms into the current codebase, I think 3-5 non-trivial algorithms would be a fair workload. For example, https://medium.com/@manjunathbhat9920/gsoc19-final-summary-cfc4b0c2e680

[kczimm]

@johnnychen94 Thanks for linking to your previous comment. I couldn't remember where that was located.

Using a functor is fine for applying the implementation. I was wondering what the type hierarchy should be. For CT image reconstruction, I can roughly categorize them into analytical and iterative, raydriven and pixeldriven for example. We have already identified several different implementations for radon.