Darker center part in reconstructed image using projections with displaced detector

[theysp]

I used the following configuration of CBCT device

1. Source to detector distance 1450mm (SDD)
2. Source to rotation axis 1000mm (SID)
3. Detector of dimension 43cm x 43cm displaced about 40%, left a 3cm redundant part of the detector

I tried the iterative FDK reconstruction, set displacement filter on, I got a reconstructed image with a darker central hole. Truncation Correction from 0.0 to 1.0 has been tried as well as various Air Threshold for the averaged scatter preprocessing and Hann Cut Frequency. The darker central hole varies from dark hole to a not so dark hole with a shining halo around it.

Since the code of displacement has not been changed for a long time, could it be improved if I use other weighting strategy?

Thank you very much.

update on 2022-06-29 I have tried simulation on a CT data of a phantom of chest, generated DRRs using siddon method with 40% offset geometry settings. And reconstructed it using iterative fdk reconstruction. Still the dark hole in the center appears.

As I reviewed a lot of papers, no such obvious artifacts has been reported.

[SimonRit]

I don't think the problem is in the dispaced detector weighting. You can validate this with a simulation. The problem is most likely that your input dataset is imperfect (calibration, scatter, etc.) and these imperfections are enhanced by the displaced detector weighting, a known side effect of this strategy. I'm closing the issue but you can re-open it if you still have the issue with simulations.

[theysp]

Thank you, I will try simulation. And let you know if things goes well. Would ART reconstruction suffer less than FDK from the imperfection of data?

[SimonRit]

It is always hard to fully anticipate but I think that the problem will also be here with iterative algorithms.

[theysp]

Thanks. In another word, image post processing is always mandatory. Correct?

[SimonRit]

Or adequate pre-processing of the projections

[theysp]

Dear Simon,

I have tried simulation on a CT data of a phantom of chest, generated DRRs using siddon method with 40% offset geometry settings. And reconstructed it using iterative fdk reconstruction. Still the dark hole in the center appears.

As I reviewed a lot of papers, no such obvious artifacts has been reported.

I can share the simulation data where you want. Would you please leave a email address? So I can send the link to the original DRRs as projection images.

[theysp]

I don't think the problem is in the dispaced detector weighting. You can validate this with a simulation. The problem is most likely that your input dataset is imperfect (calibration, scatter, etc.) and these imperfections are enhanced by the displaced detector weighting, a known side effect of this strategy. I'm closing the issue but you can re-open it if you still have the issue with simulations.

I can not re-open this by myself, because you have more privilege on it than me.

[SimonRit]

Please provide a set of rtk command line to reproduce the issue or a geometry file and one projection header. That should be enough. I'll have a look next week.

[theysp]

Please provide a set of rtk command line to reproduce the issue or a geometry file and one projection header. That should be enough. I'll have a look next week.

Thank you, here are the items you may need:

the cmdline: rtkiterativefdk.exe --verbose --geometry=_geom.xml --output=rec.tif --hardware=cuda --positivity --pad=0.3 --hann=0.8 --hanY=0.0 --fp=CudaRayCast --path=XXXX --regexp=.*\.tif --lowercrop=4,4,0 --uppercrop=4,4,0 --airthres=32000.0 --iO=65536 --idark=0 --origin=-200,-130,-200 --dimension=400,260,400 --spacing=1.0,1.0,1.0 --direction=1.0,0.0,0.0,0.0,1.0,0.0,0.0,0.0,1.0

the geometry file: _geom.zip

the projection file header:

- dimensions: 896x896
- spacing: 0.483x0.483
- origin: 0.0  0.0

[theysp]

Dear Simon

I have found the reason caused this artifact.

By default, the cuda based iterative fdk reconstructor turns the pad of displacement off. I turn it on by m_DisplacedDetectorFilter->SetPadOnTruncatedSide(true); And this shadow hole went away.

Would you please confirm this? maybe set the pad on truncated side on by default. If possible, would you please have a simple explain about this phenomenon?

Thank you very much.

[theysp]

The problem caused by code in "RTK/include/rtkIterativeFDKConeBeamReconstructionFilter.hxx" line 55

m_DisplacedDetectorFilter->SetPadOnTruncatedSide(false);

it should be turned on.

Or, the rampfilter should be revised to get used to unpadded image.

[SimonRit]

Thanks for your tests. The ramp filter works as expected and there is no reason to revise it as far as I know. You can validate it with test straight FDK, not the iterative version. However, I agree with our suggestion. Can you please make it a pull request? If you prefer, I will do it myself.

[theysp]

I'd love to make it a pull request. 10 minutes

[SimonRit]

Closed with #501

[jxhno1]

@theysp how to use this filter to do the recon process, may you share your demo?

[jxhno1]

You used the exe.