Question: cone beam to cone-parallel rebinning

[ProjX0]

Hello!! I am not familiar with rebinning, so I have a question.

I have reviewed a demo script for cone beam to cone-parallel rebinning, and it works well with the provided demo script. However, it does not work with my own data, which includes off-set data or half-beam data. Is this a normal issue with my data?

And, cropping only the central cone-beam region using my own data and applying parallel rebinning also doesn't work. Is this a normal issue?

Is there any way to address this issue...? Thank you

[hws203]

I did test cone-parallel feature with my own data too, and I can see that my own data also works with this feature too. But I can not adjust the tilt of detector feature which needs to correct fine slice at my case with this cone-parallel. So I removed it at my code.

[kylechampley]

@ProjX0 I spent a lot of time testing the cone-parallel projectors, but I was hasty when it came to the rebinning code and so it had some bugs in it. I just fixed the issue and merged the changes into the main branch (and recreated the v1.17 release binaries).

Still the rebinning code is not able to rebin from modular-beam at this time which is how one models detector tilt. It also does not handle Quarter Detector Offset (QDO) or Flying Focal Spot (FFS). I'll add these features in a later release.

Cone-parallel coordinates are mostly used by medical CT vendors which usually have a very tightly control manufacturing process which does not have detector tilts. The main use the cone-parallel is that is give more uniform resolution and noise across the field of view. In addition, most medical CT FBP algorithms were design from this coordinate system. It is actually easy to adapt cone-parallel FBP algorithm to cone-beam, but I don't see this much in the literature. Maybe I'll post a paper on the arXiv about this if I have time.

Anyway, I added cone-parallel in LEAP because I think it is a feature that a lot of people want, but I personally think rebinning to cone-parallel is a waste of time.

[ProjX0]

@kylechampley Thank you for your detailed response and for addressing the bug fix.

I verified the cone-parallel rebinning by comparing the differences between projections facing each other through a demo script. It was confirmed that there was no difference between the left and right sides based on the image. Is it also possible to perform rebinning for the top and bottom?

[ProjX0]

@kylechampley I am encountering an error with the function leapct.rebin_parallel() when using my offset geometry and data. Could you please check this for me? I sent the data and code via email.

[kylechampley]

It is not possible to rebin cone-beam to parallel-beam. One can only rebin each detector row to parallel-beam, but the rays will always diverge in the cone angle direction. That is why they call is cone-parallel- it is a mix of parallel-beam in one dimension and a diverging cone-beam in the other.

[kylechampley]

Ya, I see your problem. I wrote the rebin_parallel assuming a positive angular range. This should be an easy fix. I'll have it completed by tomorrow.

[ProjX0]

Thank you for letting me know. I appreciate you taking the time to fix it. I will patiently wait for the update by tomorrow.

[kylechampley]

The bug is fixed on the champley_dev branch.

[ProjX0]

Thank you for fixing the bug. I will try it and let you know.

[ProjX0]

The image at 0 degrees was processed using leapct.rebin_parallel(g, order=6). It appears that the image is cut off starting from the 600th horizontal pixel. On the other hand, in views from different angles, there is no cutoff, but rebinning does not seem to have been performed.

This is the difference image between the mirror images facing each other in the cone beam area (overlap area) before and after rebinning.

Is this a normal phenomenon in offset scanning, or is it a bug?

[kylechampley]

Really sorry about that; it's been fixed. Please pull again from the champley_dev branch.

[kylechampley]

I forgot to mention something. Your data has less than 360 degrees of angular coverage, so one cannot perform offsetScan reconstruction for this case. Also, if you have less than 360 degrees of angular coverage, the rebin_parallel function will change (reduce) the number of projections. The LEAP CT geometry parameters are updated accordingly, and the last projection angles will be blank. These blank projections won't affect any of the LEAP algorithms, but you can resize the data (numpy array/ torch tensor) if you wish.

[ProjX0]

Could I understand your mention as follows? For example, regarding the mention of "less than 360 degrees of angular coverage" if the x-ray beam coverage ratio of the detector is 60%, then the angle required to achieve 100% coverage would be 360 degrees * (40% /100%) = 144 degrees. Therefore, in this case, it means that a total rotation of 504 degrees (360 degrees +144 degrees) would be necessary to cover the entire angular range.

[kylechampley]

I don’t follow your thinking. Angular coverage just applies to the rotation of the x-ray source around the object (or for industrial CT the rotation of the stage).

[ProjX0]

If angular coverage simply means the angle at which the X-ray source rotates around the object, then in my data, the projection numbers starting from 45 to 708 cover the full 360 degrees from 0 to 360 degrees.

And the images below show the offset reconstruction before and after rebinning (same slice). The image quality and geometry after rebinning do not seem to match. Is this phenomenon due to the fact that, as you mentioned above, offsetScan reconstruction cannot be performed for this case?

[kylechampley]

Agh! I made another mistake. This is getting embarrassing! The angular range in the code, due to roundoff error, was 359.9999 and I was interpreting this as not a full scan. I fixed this issue and tested your script. Now the reconstruction looks very similar whether you rebin to cone-parallel or not. Please pull from champley_dev and try again. Sorry.

[ProjX0]

@kylechampley Thank you for fixing the bug. I will try it and let you know.

[ProjX0]

Here is the image after rebinning. Has the bug been fixed?

[kylechampley]

I think it has. Basically, it should look almost identical to the reconstruction that does not use rebinning.

[ProjX0]

Okay, I will keep trying with my data for now. You can close this. Thank you very much.

[kylechampley]

I added cone-parallel coordinate to LEAP because many medical CT data sets are in these coordinates and thus will be useful for many users. However, if you are just trying to get better results from your CT data, I don't think it will help.

Radiologists are very picky in the appearance of the images. The resolution and noise level will vary slightly over the field of view when reconstructing in cone-beam coordinates. Reconstructing with cone-parallel coordinates results in a more uniform resolution and noise across the field of view. To the untrained eye, one will not see a difference between reconstructions in native coordinates and cone-parallel coordinates.