{"id":"5bb3b3dd-55ff-4c17-aabc-4f26269452d9","arxiv_id":"2412.10129","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"low","formal_verification":"none","parameter_count":0,"one_line_summary":"This paper documents the TIGRE v3 iterative CT reconstruction toolbox and demonstrates it on medical, synchrotron, neutron, industrial, and proton CT datasets.","lead":"TIGRE v3 is an open-source toolbox for iterative computed tomography (CT) reconstruction, now offering Python and MATLAB interfaces, multi-GPU support, and loaders for several commercial scanners. The paper is a structured user guide with five worked examples on real and simulated CT datasets, aimed at helping non-experts deploy advanced iterative reconstruction algorithms.","discovery_kind":"review","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The correctness of vendor data-loaders and projectors is unverified; if the reverse-engineered Varian geometry in §2.6 is wrong, the §3 real-data reconstructions do not substantiate the 'real datasets' claim.","rationale":"The reader identified the same load-bearing assumption, and my stress-test agrees. The paper's own wording protects it from an overclaim of quantitative accuracy, which lowers the risk of rejection; the explicit statement in Section 3 that the only claim is that reconstructions are different means that a mild geometry error would not necessarily invalidate the paper's modest conclusion. However, the title, abstract, and Section 4 do make a concrete practical claim that real CT data from several manufacturers can be loaded and reconstructed. That claim is only as strong as the accuracy of the geometry extraction and the projector pair. The Varian footnote in Section 2.6 is an explicit admission of risk, and the absence of quantitative validation in Section 3 leaves the risk unresolved. A calibration-phantom test is inexpensive and would settle whether the loader geometry is correct. Because the reader already issued a CONDITIONAL verdict, my stress-test does not change that verdict; it reinforces the need for the stated conditions.","tokens_in":22850,"tokens_out":2795,"duration_ms":31290,"concrete_test":"On the Varian Edge scanner used in §3.1 (or a comparable clinical CBCT unit), acquire a scan of a geometric calibration phantom. Independently estimate the system geometry (source-detector distance, detector tilt, center of rotation, pixel pitch) using a published calibration method such as the one cited as [56], and compare these estimates with the geometry parameters returned by TIGRE's VarianDataLoader for the same raw file. If the maximum deviation exceeds one detector pixel or 0.1 degrees in any angular parameter, the loader geometry is not reliable for quantitative or clinical use; if all parameters agree within tolerance, the concern is resolved. As a secondary check, reconstruct a TomoBank dataset with known parallel-beam geometry and compare the result with an independent toolbox such as ASTRA or TomoPy to validate the projector pair.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central claim is that TIGRE v3 can load and reconstruct real CT data across five modalities. Every §3 example depends on the GPU projectors/backprojectors and the geometry definitions produced by the vendor loaders. Section 2.6 notes that the Varian loader is reverse engineered from domain knowledge and not verified against proprietary documentation, while Section 4 asserts that all seven loaders are 'verified on real scanners' without presenting any check. No ground-truth or independently calibrated geometry is provided for any of the five examples. If a loader mis-estimates even small geometry parameters (source-detector distance, detector tilt, center-of-rotation shift), the forward/backprojector pair models the wrong system matrix, and the displayed differences among algorithms could be driven by model error rather than by the algorithms themselves. Because the paper explicitly limits its scientific claim to 'reconstructions are different,' this concern does not overturn that modest conclusion, but it does undermine the title-level 'real datasets' guarantee and the reproducibility of the examples.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents TIGRE v3, an open-source GPU-accelerated iterative CT reconstruction toolbox, and describes its algorithmic contents, Python/MATLAB implementations, geometric flexibility, multi-GPU memory management, vendor data loaders, proton-CT preprocessing, and PyTorch bindings. The authors demonstrate the toolbox on five datasets (clinical Varian CBCT, synchrotron CT, simulated proton CT, neutron CT, and industrial helical micro-CT), each with code snippets. The authors explicitly limit the paper's scientific claim to the statement that reconstructions obtained using different algorithms are different, and that different algorithms may suit different downstream tasks.","tokens_in":22994,"tokens_out":5167,"duration_ms":51627,"significance":"If the toolbox functions as described, TIGRE v3 is a valuable open-source community resource that lowers the barrier to using iterative reconstruction on real CT data. The paper's strengths are its explicit, modest claim, the availability of the open-source code, and the inclusion of reproducible code snippets for all five examples. The descriptions cover a broad range of modalities and algorithms, and the self-citations point to prior peer-reviewed publications for the core methods. However, the demonstrations are entirely qualitative, and the correctness of the vendor data loaders, which is load-bearing for the 'real datasets' claim, is asserted rather than validated.","major_comments":[{"comment":"The correctness of the vendor data loaders and their derived geometries is load-bearing for every example in Section 3, but the paper does not validate them. Section 2.6 states that the Varian loader is reverse engineered from domain knowledge and not verified against proprietary documentation, while Section 4 asserts that all seven loaders are 'verified on real scanners' without showing any verification result. If a loader mis-estimates a geometric parameter such as source-detector distance, detector tilt, or center-of-rotation shift, the forward/backprojector pair models the wrong system matrix and the displayed algorithm differences could be driven by model error. The authors should either provide explicit validation (e.g., phantom scans with known geometry, comparison against vendor reconstruction, or quantitative geometry calibration) or temper the title-level and Section 4 claims about support for real datasets.","section":"§2.6, §4"},{"comment":"The five demonstrations are presented without any quantitative metrics. No residual norms, error norms with respect to a known phantom, or wall-clock timings are reported, so statements such as 'illustrate the performance of several of the available solvers' (Abstract) and 'highlighting the power of TIGRE to produce computationally fast results' (§3) are not directly supported by the data shown. The paper's disclaimer that it does not rank algorithms is reasonable, but a toolbox paper that emphasizes efficiency and usability should report at least objective convergence measures and timings for the examples shown.","section":"§3"},{"comment":"There is a reproducible-code inconsistency: Snippet 7 runs FISTA with 50 iterations, while the Figure 3 caption states 'FISTA (80 iterations)'. Since the paper's demonstrations are qualitative and the snippets are meant to reproduce the figures, the iteration counts must match exactly for the examples to be reproducible from the paper alone.","section":"§3.2, Figure 3, Snippet 7"},{"comment":"The neutron tomography example uses a TINTDataLoader that is not part of TIGRE (the snippet itself comments that this function is not in TIGRE), and Section 2.6 does not list TINT among the supported loaders. This undermines the claim that the examples showcase the toolbox's integrated data-loading pipeline and means that this particular example cannot be reproduced using the toolbox as described.","section":"§3.4, Snippet 9"}],"minor_comments":[{"comment":"The phrase 'Discrepancy Principe' should be 'Discrepancy Principle'.","section":"§2.2.3"},{"comment":"The text uses 'Gradient Descend' and 'Adaptative' where 'Gradient Descent' and 'Adaptive' are standard; these should be corrected.","section":"§2.1, Appendix A"},{"comment":"Section 2.6 lists six manufacturers (Philips, Varian, Comet Yxlon, Nikon, Bruker, Diondo) plus the DXChange format, whereas Section 4 says 'seven different manufacturers'; DXChange is a data format, not a manufacturer, so the count is inconsistent.","section":"§2.6 vs. §4"},{"comment":"The lens is referred to as a 'Nikkon 50-mm/f1.2'; the correct brand name is Nikon.","section":"§3.4"},{"comment":"The proton-CT example is a Monte Carlo simulation rather than a real acquisition, so the title-level phrase 'real datasets' should be qualified in the abstract or introduction to avoid overclaiming.","section":"§3.3"},{"comment":"The PyTorch wrapper section would benefit from a statement that the forward and adjoint operators were tested for gradient correctness (e.g., by finite differences), since the wrapper is offered as a differentiable operator for research use.","section":"§2.8"}],"recommendation":"major_revision","confidential_remarks":"The paper is within the scope of the journal and the open-source code is a genuine community asset. My main concern is the unvalidated vendor loaders, particularly the reverse-engineered Varian geometry in §2.6, because all real-data demonstrations depend on it. If the authors add validation or substantially qualify the 'verified on real scanners' claim, I would be willing to reconsider. The quantitative vacuum in §3 is also worth addressing, but it is secondary given the paper's explicitly modest claim."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nThe thing to know about this paper: it's a software release paper, not a science paper, and it is refreshingly honest about that. The authors explicitly limit their scientific claim to 'reconstructions obtained using different algorithms are different' (Section 3), and they don't pretend otherwise. Given that, the paper largely delivers what it promises.\n\nWhat's actually new since the earlier TIGRE papers: the Python implementation, the PyTorch bindings, the multi-GPU memory management (though that was described in 2020), the vendor data loaders, and the pCT preprocessing. The paper is a structured user guide with code snippets for all of those, and it shows five real-data examples spanning clinical CBCT, synchrotron, neutron, μCT, and (simulated) proton CT. That breadth is genuinely useful for practitioners.\n\nThe open-source code is public and the algorithms are standard, so the implementations are externally checkable. The self-citations are appropriate for a software description; I don't see a circularity problem.\n\nThe soft spots: there is no quantitative evaluation anywhere. Image quality is judged visually, and the paper's own 'different algorithms are different' claim is weak enough that it would be satisfied by almost any two methods. The reproducibility story is incomplete: no commit hash is pinned and the example data aren't all public (the Varian clinical data and the neutron data in particular). The stress-test concern about the Varian loader being reverse engineered without proprietary verification is real, and Section 4's assertion that all loaders are 'verified on real scanners' is not backed by any check presented here. That said, because the paper's claim is so modest, a loader geometry error would weaken the examples but not collapse the paper.\n\nOverall: this is a solid software-guide paper for the TIGRE community. It doesn't break new mathematical ground, but it's a useful snapshot and a practical resource. A serious referee could ask for a commit hash, a statement of data availability, and maybe one quantitative sanity check, but the paper deserves review. I'd bring it to a reading group as an example of honest software exposition.","headline":"A competent, honest software-guide paper for a widely used CT reconstruction toolbox; the new contribution is the Python/PyTorch ecosystem and data-loaders, not new math, and the lack of quantitative validation is a real but proportionate limitation given the paper's carefully limited claims.","tokens_in":23633,"tokens_out":2086,"would_cite":true,"duration_ms":19933,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"TIGRE v3 argues that one open-source GPU toolbox can run 23 iterative CT reconstruction algorithms on real clinical, synchrotron, proton, neutron, and industrial data, and that different algorithms yield genuinely different images.","keywords":["computed tomography","iterative reconstruction","open-source software","GPU computing","multi-GPU memory","cone-beam CT","proton CT","neutron tomography"],"falsifier":"Acquire a calibration phantom with known dimensions and attenuation on a supported clinical cone-beam CT scanner, load the raw data with the vendor loader, and compare the reconstructed geometry and values against the phantom's ground truth; systematic edge shifts, scale errors, or attenuation bias would show that the geometric model or loader is not faithful.","tokens_in":22635,"feed_emoji":"🩻","tokens_out":9736,"duration_ms":96910,"temperature":0.7,"pith_summary":"The paper presents TIGRE v3, an open-source toolbox for iterative computed tomography, and argues that it makes advanced reconstruction algorithms usable on real scanner data rather than only simulated data. It claims that one GPU-based codebase can handle clinical cone-beam, synchrotron parallel-beam, proton, neutron, and industrial micro-CT acquisitions through a common geometry model, vendor-specific data loaders, and multi-GPU memory management. The only evaluative claim the paper makes about the reconstructions themselves is that different algorithms produce genuinely different images, and that these differences can matter for different downstream tasks. A sympathetic reading is that if TIGRE v3 works as described, then iterative CT is no longer confined to specialists with proprietary pipelines, and algorithm developers and clinical users can share one platform.","feed_headline":"Iterative CT reconstruction works on a desktop, not just clusters","feed_subtitle":"An open-source toolbox runs 23 algorithms on hospital, synchrotron, proton, neutron, and industrial scans.","key_machinery":"The load-bearing mechanism is the discretized Radon-transform system matrix $A$ and its adjoint, implemented as GPU kernels for forward projection and backprojection; every iterative update in the toolbox, from row-action to Krylov-subspace to proximal methods, calls this pair. The geometry model is what gives the pair its reach: each projection can carry its own source-detector distance, detector rotation, center-of-rotation shift, and axis orientation, so one codebase covers circular, helical, curved-detector, laminography-style, and proton-CT geometries. Multi-GPU memory splitting then distributes these operations across devices and allows volumes larger than any single GPU's memory, with memory transfers overlapped with computation. Together these pieces turn the abstract equation $Ax + \\tilde{e} = b$ into a practical tool for real measurements.","core_discovery":"TIGRE v3 provides 23 standardized iterative algorithms built on GPU forward- and back-projection operators, a geometric model that allows per-projection variation (detector rotations, curved detectors, arbitrary rotation axes, center-of-rotation shifts, and helical trajectories), six vendor data loaders, a proton-CT preprocessing stage that rebins particle-track data into radiographs, and an optional binding to deep-learning libraries. The paper's demonstrations reconstruct a limited-arc clinical head scan, a noisy synchrotron time series, simulated proton CT of a phantom, a 10-projection neutron scan of a padlock, and a helical micro-CT scan of a battery, all on a desktop computer. The authors state explicitly that they make no claim about which algorithm is 'best'; the claim is that reconstructions obtained with different algorithms are different and may be of interest in different scenarios. If correct, this is the central fact that makes a multi-algorithm open toolbox valuable.","pith_inferences":["The paper's refusal to rank algorithms suggests a testable consequence it does not pursue: once many solvers run on the same data, the natural next step is task-specific benchmarking, where image quality is measured by the downstream task (segmentation, metrology, diagnosis) rather than by generic image metrics.","Because the clinical scanner loader is reverse engineered from domain knowledge and not verified against proprietary documentation, an unstated risk is that geometry errors in that loader would systematically distort clinical reconstructions; validating the loader against a calibration phantom would settle this.","The deep-learning binding, presented as a convenience for learned reconstruction, also makes TIGRE's geometric accuracy a determinant of learned-method performance: if the forward operator is slightly wrong, trained networks will absorb that bias.","If the multi-GPU splitting scales linearly as claimed, then the toolbox could become a de facto reference implementation for testing new iterative algorithms on industrially sized volumes, which would shift algorithm development from small simulated phantoms toward realistic large-scale data."],"forward_implications":["A clinical cone-beam reconstruction with 493 projections over a 200-degree arc can be produced in under five minutes on a personal desktop, with OS-SART or OS-ASD-POCS visibly less noisy than FDK.","Neutron tomography at a low-flux reactor can use 10 projections instead of 201 and still yield recognizable reconstructions, cutting acquisition time from around 14 hours to a fraction of that.","Proton CT data, once rebinned into optimized radiographs, flows through the same reconstruction algorithms as ordinary CT, so pCT development does not need a separate solver stack.","Images larger than the memory of a single GPU can be reconstructed by splitting the work across multiple GPUs and overlapping memory copies with computation.","A single line of loader code can bring raw scanner output from several manufacturers into a common geometry representation, removing a major barrier to trying iterative algorithms."],"supporting_citations":[{"why":"Original TIGRE publication; supplies the GPU forward/backprojector pair, geometric defaults, and the FDK/FBP and row-action solver implementations on which v3 builds.","marker":"[7]"},{"why":"Paper on Krylov methods for large-scale cone-beam CT; supplies CGLS, LSQR, LSMR, hybrid and TV-regularized variants and automatic regularization choice used in v3.","marker":"[45]"},{"why":"Describes the multi-GPU memory-splitting strategy that allows larger-than-memory reconstruction and linear scaling with GPU count.","marker":"[58]"},{"why":"Adds the proton-CT preprocessing and binning step, letting proton radiographs be reconstructed by ordinary CT algorithms.","marker":"[66]"},{"why":"Validates the clinical onboard-CBCT data loader and preprocessing pipeline on real scanner data, including preprocessing steps that TIGRE emulates.","marker":"[63]"},{"why":"Defines the scientific data-exchange schema used by the synchrotron loader for HDF5-based datasets.","marker":"[62]"},{"why":"Public data repository that supplies the synchrotron acquisition reconstructed in the parallel-beam example.","marker":"[69]"}],"fun_headline_variants":["Open-source CT toolbox now runs 23 algorithms on a desktop","23 iterative CT algorithms in one open-source GPU toolbox","Desktop CT: TIGRE v3 runs 23 algorithms on real scans","TIGRE v3: 23 CT algorithms for real scans on a desktop GPU","One open-source toolbox, 23 iterative CT algorithms for real data"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that the toolbox's GPU projectors, geometry definitions, and vendor-specific loaders faithfully represent each scanner's real imaging geometry, since every demonstrated reconstruction depends on that fidelity; the clinical loader in particular is reverse engineered from domain knowledge rather than verified against proprietary documentation.","fun_headline_variants_meta":{"raw":{"variants":["Open-source CT toolbox now runs 23 algorithms on a desktop","23 iterative CT algorithms in one open-source GPU toolbox","Desktop CT: TIGRE v3 runs 23 algorithms on real scans","TIGRE v3: 23 CT algorithms for real scans on a desktop GPU","One open-source toolbox, 23 iterative CT algorithms for real data"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000792,"raw_usage":{"total_tokens":3494,"prompt_tokens":951,"completion_tokens":2543,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":567,"completion_tokens_details":{"reasoning_tokens":2450}},"tokens_in":567,"tokens_out":2543,"duration_ms":18837,"temperature":1.0,"reasoning_tokens":2450,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-11T16:17:58.468110+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Acquire a calibration phantom with known dimensions and attenuation on a supported clinical cone-beam CT scanner, load the raw data with the vendor loader, and compare the reconstructed geometry and values against the phantom's ground truth; systematic edge shifts, scale errors, or attenuation bias would show that the geometric model or loader is not faithful.","supporting_citations":[{"cited_title":"TIGRE: a MATLAB- GPU toolbox for CBCT image reconstruction","cited_arxiv_id":null,"evidence_quote":"Original TIGRE publication; supplies the GPU forward/backprojector pair, geometric defaults, and the FDK/FBP and row-action solver implementations on which v3 builds."},{"cited_title":"On Krylov methods for large-scale CBCT reconstruction","cited_arxiv_id":null,"evidence_quote":"Paper on Krylov methods for large-scale cone-beam CT; supplies CGLS, LSQR, LSMR, hybrid and TV-regularized variants and automatic regularization choice used in v3."},{"cited_title":"Arbitrarily large tomography with iterative algorithms on multiple GPUs using the TIGRE toolbox","cited_arxiv_id":null,"evidence_quote":"Describes the multi-GPU memory-splitting strategy that allows larger-than-memory reconstruction and linear scaling with GPU count."},{"cited_title":"Extension of the open- source TIGRE toolbox for proton imaging","cited_arxiv_id":null,"evidence_quote":"Adds the proton-CT preprocessing and binning step, letting proton radiographs be reconstructed by ordinary CT algorithms."},{"cited_title":"TIGRE-VarianCBCT for on-board cone-beam computed tomography, an open-source toolkit for imaging, dosimetry and clinical research","cited_arxiv_id":null,"evidence_quote":"Validates the clinical onboard-CBCT data loader and preprocessing pipeline on real scanner data, including preprocessing steps that TIGRE emulates."},{"cited_title":"Scientific data exchange: a schema for HDF5-based storage of raw and analyzed data","cited_arxiv_id":null,"evidence_quote":"Defines the scientific data-exchange schema used by the synchrotron loader for HDF5-based datasets."},{"cited_title":"Tomobank: a tomographic data repository for computational x-ray science","cited_arxiv_id":null,"evidence_quote":"Public data repository that supplies the synchrotron acquisition reconstructed in the parallel-beam example."}],"review_version":1}