Feature Requests

[kylechampley]

I maintain a list the things I am working on in the Future Releases section on the main page.

But what sorts of features do our users want? Some example topics are: improve the build process, improve speed, new algorithms, improvements to the PyTorch interface, file I/O features to process data from various vendor systems, etc.? What is preventing you from using LEAP for your applications?

[hws203]

Below is my list of the items to be supported at leap package for the usual usage for tomography.

1. Geometry calibration algorithm for auto finding parameters of cone beam. I am using the sweep method of leap currently. But I hope a little more robust and fast one for this purpose.
2. motion correction(jitter correction) of projection image feature for the imperfect scanner H/W.
3. PyQT GUI for the visual and direct understanding of current geometry, parameters and projection simulation.
4. A little more independency of python library(like scipy) and more c++ or cuda code for faster running.
5. Ball phantom feature for the detail calibration.
6. Sinogram order recon supporting for the faster recon.
7. Offscan recon at concurrent recon from both left and right projection image.
8. Selectable bad pixel correction algorithm not by all area filtering.
9. Projection simulation feature from stl file and HU information.
10. beam hardening correction as you listed up for future release.

[ProjX0]

I am interested in the following topics and would appreciate if they could be considered for inclusion in the LEAP toolkit:

• Multi-energy CT reconstruction
• Three (or more) material decomposition (e.g., bone, fat, water)
• Katsevich algorithm for spiral CT reconstruction

[kylechampley]

Thanks for the list. I have some questions/ comments.

1. I have some ideas about what to add here.
2. This is not something I want to do. Hopefully someone else will step up and add this to LEAP.
3. Yep, this is my current priority. It's a lot of work, so it is taking more time than I first expected.
4. I'm not sure what "fact running" means. I am trying to keep Python dependencies to a minimum and trying to keep enough functionality in the C++ side so that people can use LEAP without Python, but Python is easier to write some algorithms, so I am trying to make the best compromise.
5. I don't know anyone who uses the term "jig". Most people use a ball phantom for calibration, and this is often just called "ball phantom calibration" or something similar to this. Anyway, if you check the list on the LEAP main page, this is on that list.
6. I gave a lot of thought of whether to use projection or sinogram order in LEAP. I still think I made the right decision by going with projection order, and most people use this order. Still, I do agree that sinogram order has some advantages. Adding this feature would be a huge undertaking and would mean that every time I add a new algorithm to LEAP, I'd have to make sure it supports projection AND sinogram ordering which would slow down future development. So, I'd say I might add this feature, but it is not very likely.
7. I don't understand this request.
8. Yes, I like this one and it would be easy to do. This would be similar to outlier correction, but done only on specified detector pixels. I recently added a low signal correction algorithm which is another flavor of this.
9. In my opinion this is beyond the scope of LEAP. There are other packages that do this, such as aRTist.
10. Yep, I'll do this after I complete the GUI.

[hws203]

4=> fact running => faster running. Current your compromise are good too. But I have to convert some function into c++ for my application.
7=> Offscan dual mode recon is a special feature which needs large or two detectors which capturing two samples at the same time at both right and left side of detector. So you can skip this feature, that is a special vendor dedicated feature.

[hws203]

2=> I have estimated some algorithm of motion correction with my own data sets, and I found that actually there are not much jitter factor at those image. So this item could be lower priority or can be skipped.

[kylechampley]

@ProjX0, I could easily do 3-energy decomposition and multi-material BHC for any number of materials. What is the purpose of the Katsevich algorithm? It is theoretically exact, but in practice WFBP (the algorithm implemented in LEAP) produces better results and is more "dose efficient". By dose efficient, the WFBP algorithm always uses data from all detector rows, but the Katsevich algorithm throws out some of the data.

[ProjX0]

@kylechampley

• Would you be willing to include three (or more) material decomposition (e.g., bone, fat, water) in the demo script of the LEAP toolkit?
• My purpose is simple. Just as the LEAP toolkit provides many reconstruction algorithms, I thought it would be nice to include the well-known Katsevich algorithm, which is one of the spiral reconstruction methods. If this falls outside the scope of LEAP and takes up too much of your time, I do not wish to pursue it.

[ProjX0]

I have confirmed that future releases include triple energy decomposition. Thank you.
Is it possible to easily perform three-material decomposition using dual-energy?

[kylechampley]

@hws203, what do you mean by HU information? Note that if you know something about the x-ray spectra you can convert your reconstructions into HU using the XrayPhysics package.

[hws203]

HU information means that Hounsfield unit as like water is 0HU, air is -1000HU. Yes, I checked the XrayPhysics and Virtual X-Ray Imaging Library package, then listed up above 9'th item. I hope that if one reference sample is reconstructed perfectly, then that can be used as like a new phantom to project new images at different cone beam parameters, which can be useful for AI training or DRR method geometry calibration.

[kylechampley]

The Future Releases section has been modified.

@hws203, I still don't understand you comment about converting to HU. You can do this with the XrayPhysics packages like this:
f = f * 1000.0 / physics.mu('water',effectiveEnergy) - 1000.0
where "effectiveEnergy" is the effective energy of your total system spectral response in keV.

[hws203]

my converting means that most tissues(-100HU~100HU), and dense bone(2000) set at each stl object and combined into one for the converting of projection image simulation. for this operation, each stl object should have HU value for attenuation weight. I mean that point. Your updated future release looks better for me.

[elliotaldarson1717]

@kylechampley
May be this suggestion is not Overall useful but in My Application(Single material with some inclusions and cracks only) 8 bit image/slice output is more than enough and desirable.. right now output images are in 32bit float ..

[kylechampley]

Yes, this is a common feature in many CT reconstruction software packages. It is built into the DICOM and DICOS formats. It is a good idea to store the slope and offset numbers in the file header so that the data can be mapped back to its original floating-point values.

My hope is that someone from the LEAP community could add this feature for me, so I can focus my time to implementing tomography algorithms. You may be able to use dxchange to do this for you.

[hws203]

@kylechampley , Did you go back to old future release list at your readme file ? Now it is updated,,,,

[kylechampley]

Yes, I updated the Future Releases section of the readme file based on the feedback on this discussion. I plan to continuously update this section as the plans change.

[hws203]

I see, your updating will be expected by me and others.

[kylechampley]

A beta version of the GUI has been released.

[kylechampley]

Ball phantom calibration function has been released in v1.22.

[hws203]

Is there any technical manual about this ball phantom usage ?

[kylechampley]

No, but there is a sample script here.

[zhangr05]

Hi Kyle, it would be great if you could add more documentation to the leaptorch section. Does leaptorch support curvedetector, shift_detector, set_rampFilter, etc. ?
Thanks!

[kylechampley]

They are already supported because the tomographicModels class (the class in leapctype.py) is a member variable of the Projector class. For example, you can do:

proj = Projector(...)
proj.leapct.set_curvedDetector()
proj.leapct.shift_detector(...)
proj.leapct.set_rampFilter(...)

[zhangr05]

Thanks, I realized that after the post. I was looking at the BaseProjector class definition and didn't see these options. I guess we should just use leapct.tomographicModels.set_conebeam() and manually allocate projections instead of using set_conebeam()

[hws203]

@kylechampley As you know, current leapct use the float type projection data as like float *g. But most x-ray detector device makes unsigned short type data, so I have to convert it into float data which consumes more memory and cpu resource.
So I hope that leacpct can support 16bit type projection data directly on cuda smearing function(SF or eSF) which can save cuda memory too(float output = float weight x short PrjVal).

[kylechampley]

Yes, most x-ray detectors have 14 to 16 bits of accuracy which, as you say, are usually stored as unsigned 16-bit integers. For CT algorithms to work, you must use floating point numbers which can be 16, 32, or 64-bit. LEAP uses 32-bit float. Switching to 16-bit float would be a HUGE task that I am not up for. Moreover, using 16-bit floats will incur a lot of roundoff error and in my opinion is only appropriate for small data sizes.

Recently releases of LEAP are much more memory efficient; have you tried this?

In addition, LEAP does support saving data as 8 or 16 bits. See the set_fileIO_parameters function.

[hws203]

@kylechampley Ring artifact removing algorithm upgrading.

I know leapct supports some ring artifact removing features, and I tested these ones and I could see some needs too much time and some is showing too weak removed result. So I hope that leapct supports more robust and fast ring removing algorithm. Please check the reference site as like https://github.com/nghia-vo/sarepy. I hope that you can adapt some feature into your leapct's kernel codes.

[kylechampley]

I have been working on improving the ring removal algorithms in LEAP lately. I'll have an update in a couple of weeks.

Yes, I am aware of ring removal algorithms by Vo. I have actually seen him give a talk on his method. I've never tried out his method myself, but from the results it look extremely effective. Unfortunately, I don't understand how it works and I only like using algorithms I understand. But if you like the method, why not just use it?

[hws203]

I am using his method currently by using native c++ cpu code. And as you guess, it show good result.
Below is my result.