Half fan CBCT reconstruction

[Anshika1508]

Hi all,
I am attempting CBCT reconstruction using python TIGRE’s OSSART algorithm, but I am consistently getting a prominent ring artifact and a diagonal streak in the reconstructed images.

I am using the following geometry:

    geo= tigre.geometry_default(high_resolution=True)  # base`
    geo.DSO        = float(921)
    geo.DSD        = float(1690)
    geo.nDetector  = np.array([col_det,row_det],dtype=np.int32)
    geo.dDetector  = np.array([0.278,0.278], dtype=np.float32)
    geo.sDetector  = geo.nDetector * geo.dDetector
    geo.mode       = "cone"
    geo.angles     = angles
    n_proj = angles.size
    geo.nVoxel     = np.array([400,400,400], dtype=np.int32)
    geo.dVoxel     = np.array([1,1,1], dtype=np.float32)
    geo.sVoxel     = geo.nVoxel * geo.dVoxel
    geo.offOrigin = np.array([0, 0, 0], dtype=np.float32)
    geo.offDetector = np.array([-195,0])
    geo.rotDetector = np.array([0, 0, 0])
    geo.accuracy = 0.5
    geo.COR = `0``

Any guidance on how to refine the geometry setup or reconstruction parameters to reduce these streaks would be greatly appreciated.

[AnderBiguri]

Is this real data?

If it is: if you run the same code for the digital image that comes with TIGRE (but your geometry) does it also happen?

Trying to debug if this is a data problem or a TIGRE problem

[Anshika1508]

Hi Ander,
Yes, this is real data.
There’s no issue with the data itself, as I’m able to reconstruct it perfectly in RTK using the same data and geometry.

[AnderBiguri]

@Anshika1508 Sure, but can you try with the fake data of TIGRE? Can you try FDK too?

RTK is super finetuned for medical real data and has some heuristics to clean data that TIGRE sometimes misses. Of course, I would really like to fix that and add those things in TIGRE, but I don't know them all, so trying to figure out if it from data, or a specific bug of OSSART that only arises in your specific geometry case.

[sanchalitorpe-source]

This looks consistent with a half-fan CBCT setup (geo.offDetector ≠ 0).

In TIGRE, OSSART does not automatically apply redundancy (Parker) weighting or truncation compensation for half-fan scans. As a result, ring artifacts and diagonal streaks are expected if:

• projections are truncated,
• angular coverage is insufficient (typically < 360° + fan angle),
• or redundancy weighting is missing.

RTK includes several heuristics for real medical data (Parker weighting, normalization, truncation handling), which explains why it may reconstruct cleanly using the same raw data.

To diagnose this further in TIGRE, I would suggest:

1. Trying FDK with Parker weights enabled (if applicable),
2. Testing the same geometry with TIGRE’s simulated data,
3. Verifying angular coverage is sufficient for half-fan geometry.

If the simulated data reconstructs correctly, the issue is most likely related to projection truncation and missing redundancy weighting rather than a geometry error.

[AnderBiguri]

Thanks! @sanchalitorpe-source . As a note, its seems this is one of the few things that OS-SART in MATLAB has but not in Pythion. Mathematically only FDK requires Parker weights, but there is a paper showing that it helps iteratives. A user in the past added it to MATLAB (search for redundacy_weigthing), but it was never parsed to python, apparently.

[sanchalitorpe-source]

Thanks @AnderBiguri! I hadn’t realized that redundancy weighting was implemented in MATLAB OS-SART but not yet in Python. Adding support for Parker/redundancy weighting in Python could definitely help improve iterative reconstructions — might be worth a follow-up enhancement or PR.

[AnderBiguri]

@sanchalitorpe-source definetly would be useful. I am quite busy these days, but if you think its useful for you, do feel free to tackle it. The code for Parker weigths is in FDK anyway, so its mostly about adding an optional parameter to art_family_algos to turn it on/off and call the right function.

[sanchalitorpe-source]

Thanks @AnderBiguri! That makes sense. I’ll take a look at the existing FDK implementation and see if I can add an optional Parker weighting parameter to the ART family algorithms. I’ll open a PR once I have a working implementation.