FDK for V-offset missing

[scf819]

I am trying to do CBCT reconstruction. There is a detector offset in the Z-axis, namely geo.offDetector = [0; -120]; % Offset of Detector (mm) which leads to insufficient data on both sides of the Z-axis and obvious artifacts. Is there any good way？ #151 @dyycy

Actual Behavior

Pocs-tv algorithm is used by me to increase the number of reconstructed image layers, but Now I try to use FDK algorithm to do it. There are x-FDK, HD-FDK, V-FDK and other algorithms maybe improve image.

[AnderBiguri]

Hi @scf819! Can you share the full geometry? As you know, this artifacts are normal, as imat some point you won't have enough info in the z direction. As you say there may be algorithmic ways to improve it a bit, but offset in V direction is much more limiting than in U direction, due to rotation direction of the machine.

I have never heard of those variations of FDK, can you share some papers? If they are easy maybe we can implement them into Tigre.

[scf819]

Hi!> Can you share the full geometry?> As you know, this artifacts are normal, as imat some point you won't have enough info in the z direction. As you say there may be algorithmic ways to improve it a bit, but offset in V direction is much more limiting than in U direction, due to rotation direction of the machine.> > I have never heard of those variations of FDK, can you share some papers? If they are easy maybe we can implement them into Tigre.

hi，there is full geometry.and geo.nVoxel=[512;512;236]; Increase the utilization of Z-axis data. %% geo geo.DSD = 1139; % Distance Source Detector (mm)
geo.DSO = 708; % Distance Source Origin (mm) %Detector parameters geo.nDetector=[1536 ; 144]; % number of pixels (px) geo.dDetector=[0.53; 0.53]; % size of each pixel (mm) geo.sDetector=geo.nDetector.geo.dDetector; % total size of the detector (mm) % Image parameters geo.nVoxel=[512;512;236]; % number of voxels (vx) geo.dVoxel=[0.66;0.66;0.33]; geo.sVoxel=geo.nVoxel.geo.dVoxel; % total size of the image (mm) % Offsets ？？ geo.offOrigin =[0;0;-74.5]; % Offset of image from origin (mm)
geo.offDetector=[0; -120]; % Offset of Detector 2.04 (mm) % Auxiliary ？？ geo.accuracy=0.5;

papers： Plan a：The missing data was compensated by three-dimensional weighted backprojection 1: x-fdk Cone-beam CT image reconstruction with extended z range doi：10.1118/1.3148560

2: fafdk Modified FDK Algorithm for Cone-Beam Reconstruction with Efficient Weighting Scheme doi: 10.1109/WCICA.2006.1713887

3:weighted-fdk Compensating the intensity fall-off effect in cone-beam tomography by an empirical weight formula doi.org/10.1364/AO.47.006033

Plan b:The projected data is rearranged， Convert to a parallel beam 1：V-FDK Filtering path variable FDK (v-FDK) reconstruction algorithm for circular cone-beam CT doi：10.1117/12.2551371 However, for V-FDK,when the cone beam is transformed into a parallel beam, the image resolution will be reduced, especially in the case of large cone Angle。

thank you.

[AnderBiguri]

Thanks a lot!

My answer is that this sounds like a thing TIGRE should have in the FDK (which one of the 4, no idea! maybe all of them?). However, I don't currently have the time to implement and test these, so the current answer is that you can't do them with TIGRE now.

If you or anyone else wants to implement them, I'd me more than happy to help and add them to TIGRE!

[scf819]

i try to implement them,however,i need help,I'll email you back later.

[yidu-bjcancer]

@scf819 Your problem is a classic problem of "long objection reconstruction". My answer is NO. The data are seriously missing, so it is impossible to deliver reasonable results with FDK. Either is iterative algorithm, unless you have some significant constraints.

[AnderBiguri]

I agree with @dyycy. Those FDK algorithms will help get a better image, but it won't be significantly better, your image Z is much larger than the projection, you are simply missing lots of info (not measuring it). and if the info it's not measured, it can't be recisntruted.

TV algorithms cheat this a bit by knowing that the sample should be smooth, thus giving you something better with the little information you measured, but your FDK alternatives will likely not. The image will be better than TIGREs FDK, but I seriously doubt it will be better than the iterative recon results.

[scf819]

hi，@dyycy
As shown in the figure below, A (blue part) has sufficient data, >360 Angles, and C (red part) with serious data missing cannot be reconstructed, while B (green part) should be able to add weight and other methods to effectively reconstruct the image, and then I try to reconstruct the green part with high quality. In fact, I used an iterative algorithm, and the green part could not be completely reconstructed. 图片：https://github.com/scf819/demo/blob/main/z.bmp

[yidu-bjcancer]

hi，@dyycy As shown in the figure below, A (blue part) has sufficient data, >360 Angles, and C (red part) with serious data missing cannot be reconstructed, while B (green part) should be able to add weight and other methods to effectively reconstruct the image, and then I try to reconstruct the green part with high quality. In fact, I used an iterative algorithm, and the green part could not be completely reconstructed. 图片：https://github.com/scf819/demo/blob/main/z.bmp

I think you kind of misunderstood the issue of data sufficiency in CBCT, but anyway, it's not important here. As per the problem you want to solve, to my knowledge, it's impossible to deliver reasonable results with FDK and its derivatives. You can try iterative algorithms, but as I put previously, the results may be as lame as FDK unless some prior-knowledge of the object is added to IR as significant constraints. Personal advice: change the scan geometry.

[scf819]

@dyycy Uh.. You're right，It's really difficult to solve this problem