{"id":"f6d2877d-d380-4eac-89aa-1a74bf4730be","arxiv_id":"2505.20160","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"DeepInverse provides a PyTorch-based unified framework for deep learning in imaging inverse problems, from physics operators to solvers and training.","lead":"DeepInverse is a new open-source Python library that unifies forward operators, reconstruction models, losses, and training tools for imaging inverse problems. It is designed to help researchers and practitioners build, train, and evaluate deep learning-based image reconstruction across MRI, tomography, astronomy, and more.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The central unification claim lacks supporting evidence: the paper does not show that the shared Reconstructor/Trainer abstractions express all listed solver families without per-method workarounds.","rationale":"The reader's weakest assumption—that the unified abstractions can express all listed methods without workarounds—is the same load-bearing concern I identify, so I agree with the reader's conditional verdict. The paper makes a strong architectural claim, but the evidence provided is mostly descriptive: method lists and design philosophy (Sections 3–7) rather than demonstrations that the abstractions are sufficient and efficient. The check I propose would settle the concern by exercising the public API across every claimed method family and measuring overhead; if it passes, the central claim is materially supported, and if it fails, the paper's strongest claim should be downgraded. The library benefits from credible independent signals: it is open-source, has unit/integration/performance tests, extensive documentation with doctests, and a large author community. These support the existence of a functional package, but they do not by themselves establish the 'unifies all solvers' claim. No code link or commit hash in the manuscript makes independent verification harder, but this is fixable and secondary. The current conditional verdict remains the right calibration: accept the software paper once the repository and a small demonstration benchmark or feature matrix are provided. I do not see an internal inconsistency or fatal flaw in the design as described, so rejection is not warranted.","tokens_in":10937,"tokens_out":4889,"duration_ms":51767,"concrete_test":"Download DeepInverse v0.3.0 from the authors' repository and implement one representative from each of the six Table 2 families (FISTA, PnP with a pretrained DnCNN, a 10-step unrolled network, DPS diffusion, a conditional GAN, and a simple foundation model) using only the public Reconstructor/Trainer APIs. Record whether each needs subclass override, monkey-patching, or direct manipulation of internals, and compare wall-time and GPU memory against standalone PyTorch reference implementations. If any family cannot be written through the public abstractions, or has substantial overhead for the same reconstruction quality, the unification claim should be weakened.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central contribution is that DeepInverse provides a unified framework for imaging inverse problems (Section 1, Eq. 2). The strongest version of this claim—that the listed solver families in Section 3 are all covered by common abstractions (Reconstructor, Physics, Trainer) without leaky special cases—is asserted but not demonstrated. Three concrete spots make this nontrivial: (i) Section 3.3, Eq. 6 defines unconditional generative reconstruction as an inner optimization over latent code z, which is not a single forward call like other methods; (ii) Section 3.2 defines sampling methods as Markov chains/SDEs, requiring iterative stochastic execution rather than a simple network evaluation; (iii) Section 4 lists supervised, self-supervised, regularization, and adversarial losses, where self-supervised splitting and SURE losses have structurally different training loops. The paper provides no feature matrix, no minimal working examples showing these in the public API, no benchmarks of runtime or memory, and no repository URL or commit hash. If any family requires bypassing the base classes, 'unifies' becomes an architectural aspiration rather than a demonstrated property. This is an evidence gap, not an internal contradiction.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"This paper presents DeepInverse, an open-source PyTorch library for imaging inverse problems. The library provides forward operators (MRI, tomography, blur, etc.), noise models, solvers spanning optimization-based, sampling-based, and non-iterative methods, training losses (supervised, self-supervised, adversarial), datasets, and evaluation metrics. The paper describes the design choices and claims that DeepInverse is the only library with a strong focus on learning-based reconstruction and that it unifies the wide variety of solvers through common abstractions. It is a snapshot of release v0.3.0 and contains no benchmark results, code listings, or repository link.","tokens_in":11108,"tokens_out":5025,"duration_ms":47599,"significance":"If the claims are accurate, DeepInverse could be a genuinely useful community resource: it would lower the barrier to entry for practitioners, provide realistic operators across many imaging modalities, and improve reproducibility through shared abstractions and test-driven development. The paper's strengths are its broad scope, the explicit coverage of both classical optimization and modern deep learning methods, and the integration of self-supervised and adversarial losses. However, the central claim of unification is not evidenced in the manuscript, and the absence of a repository URL or commit hash prevents independent verification. The value of the library is plausible but not yet demonstrated in the paper.","major_comments":[{"comment":"The central claim that DeepInverse 'unifies the wide variety of solvers' is asserted without demonstration. The method families listed in Table 2 have structurally different execution patterns: unconditional generative reconstruction (Eq. 6) requires an inner optimization over latent code z, sampling methods (Section 3.2) require iterative stochastic Markov-chain execution, and deep equilibrium models (Section 3.1) require implicit differentiation of a fixed point. The paper provides no feature matrix, no minimal code examples, and no runtime or memory benchmarks to show that the Reconstructor/Trainer abstractions express all of these families without per-method workarounds. This is an evidence gap in the paper's main claim, not an internal contradiction.","section":"Section 3 and Table 2"},{"comment":"The manuscript never gives a repository URL, DOI, or commit hash, despite claiming in the Abstract that the library is open-source and in Section 8 that the paper is a snapshot of v0.3.0. Without a persistent link and version identifier, readers cannot verify any of the described functionality, and the paper's reproducibility claims (Section 1) are not actionable. Please add a permanent identifier (e.g., Zenodo DOI) and the exact commit or release.","section":"Abstract and Section 8"},{"comment":"The loss framework is said to unify supervised, self-supervised, regularization, and adversarial losses, but these categories have structurally different training loops. For example, splitting losses require operator-specific masks, SURE losses require noise-level handling, and adversarial losses require discriminator updates. The paper does not show how the Trainer class accommodates these differences, or whether doing so requires subclassing or bypassing the base class. A short API example or a table listing each loss family and its required arguments would make this claim credible.","section":"Section 4.1, Eq. (7)"}],"minor_comments":[{"comment":"The forward operation is described as 'x = physics(y, **params)', which inverts the mapping in Eq. (1); it should be 'y = physics(x, **params)' (or an equivalent form).","section":"Section 2, Eq. (1)"},{"comment":"The text references 'Table 2' for forward operators, but the forward operators appear in Table 1; Table 2 is the reconstruction-methods table.","section":"Section 2"},{"comment":"The hyperlinks labeled 'user guide' and 'quickstart' are empty in the manuscript; include the URLs.","section":"Section 7.2"},{"comment":"Reference [17] is cited as an operator norm and condition number estimator, but [17] is the LSQR paper; please verify and correct the citation.","section":"Section 2"},{"comment":"The claim that DeepInverse is 'the only one with a strong focus on learning-based methods, providing a larger set of realistic imaging operators' would be more convincing with a small comparison table against SCICO, Pyxu, ODL, and CIL listing supported operator families and training utilities.","section":"Section 1"},{"comment":"A single basic usage example (e.g., defining a Physics, building a Reconstructor, and running Trainer.train for one epoch) would greatly help readers evaluate the API design claims.","section":"Sections 3 and 4"}],"recommendation":"major_revision","confidential_remarks":"This is a software-description paper whose central selling point is the breadth and unification of its abstractions. I could not verify that breadth because the paper contains no repository link or code samples. I would not reject on that basis alone—the library may well be as described—but the revision must provide a persistent link and concrete evidence for the unification claim. If the authors can supply those, the paper would be acceptable for the venue."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"You should know two things. First, DeepInverse describes a real, substantial software artifact with unusually broad coverage of learning-based imaging inverse problems, and the operator parameterization feature (ξ) is a genuinely distinctive contribution. Second, the paper as written doesn't give you enough to check that claim: no repository URL, no commit hash, no benchmarks, no feature matrix. That makes the central \"unifies the wide variety of solvers\" assertion an architectural promise rather than a demonstrated property.\n\nCredit where it's earned. Section 2's forward-operator framework with matrix-free linear operators, adjoints, pseudoinverses, and parameterized physics (angles, blur kernels, masks) is well designed. Section 3 covers optimization, PnP, unrolled, DEQ, diffusion, Langevin, and generative methods; Section 4 lists supervised, self-supervised (splitting, SURE, nullspace), and adversarial losses. The dataset and evaluation sections are useful. The test-driven development and documentation claims (Sphinx-Gallery, doctest) are the right practices for a software paper. The citation pattern is normal; self-citations point to work the library builds on.\n\nSoft spots, in proportion. The claim that this is the only learning-focused library with a larger set of realistic operators is asserted with a qualitative comparison to SCICO, Pyxu, CUQIpy, TIGRE, ODL, and CIL. It may be true, but it deserves a feature matrix. The unification claim has load-bearing details: Section 3.2 defines sampling as Markov chains, and Section 3.3 defines unconditional generative reconstruction as an inner optimization over latent codes. Neither obviously fits a plain `model(y, physics)` call unless the base abstractions handle special cases. The paper never shows a minimal working example or test proving these families work through the same Reconstructor/Trainer interface without workarounds. That is an evidence gap, not an internal contradiction. And for a software paper, omitting the repository URL or commit hash is the equivalent of omitting a proof; it prevents independent verification from the text alone.\n\nNone of this is fatal. The library exists, has a large author base, and is already used in the community. The paper is a snapshot of v0.3.0, which is honest. The missing verification can be fixed with a reproducibility section, a feature matrix, and a small benchmark suite. Send it out. A serious referee should engage, and I would conditionally accept after requesting those artifacts.","headline":"A genuinely useful library paper whose strongest unification claim is asserted but not yet verified; it deserves peer review with requests for the missing repo link and feature matrix.","tokens_in":11735,"tokens_out":2181,"would_cite":false,"duration_ms":28088,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"DeepInverse claims that one unified PyTorch-based framework can cover every major step of learning-based imaging inverse problems—forward operators, solvers, and training—in a single open-source library.","keywords":["inverse problems","image reconstruction","deep learning","software library","forward operators","self-supervised learning","plug-and-play priors","diffusion models"],"falsifier":"Implement a representative method from each family—an unfolded MRI network, a plug-and-play ADMM solver, and a diffusion posterior sampler—twice, once with DeepInverse and once in native code, and compare wall-clock time, memory, and reconstruction quality on identical data. If any listed method cannot be expressed through the public interfaces, or runs with substantially degraded efficiency, the unification claim fails.","tokens_in":10751,"feed_emoji":"🖼️","tokens_out":4944,"duration_ms":48898,"temperature":0.7,"pith_summary":"This paper presents DeepInverse, an open-source Python package for solving imaging inverse problems with deep learning. Its central claim is that one shared set of abstractions—a physics object for the forward measurement model, a reconstructor object for the solver, and a trainer object for learning—can cover the full pipeline of image reconstruction, from realistic optics, MRI, and tomography operators to variational optimization, plug-and-play priors, unfolded networks, diffusion sampling, and generative models. The authors argue that this unification speeds up research, lowers the entry barrier for practitioners, and improves reproducibility by replacing bespoke per-domain code with interoperable components. The package also emphasizes parameterized forward operators, which enable blind inverse problems, system calibration, and joint design of acquisition and reconstruction.","feed_headline":"One package unifies deep-learning image reconstruction across domains","feed_subtitle":"MRI, CT, optics, and radio astronomy share one interface for operators, solvers, and training.","key_machinery":"The central object is the Physics class, which wraps the forward model $A_\\xi$ and noise model $\\mathcal{N}_\\sigma$ behind a single callable, together with the Reconstructor and Trainer classes. The forward model is parameterized by $\\xi$ (projection angles, blur kernels, MRI masks), and the library supplies matrix-free implementations, adjoints, pseudoinverses, proximal operators, and norm estimators so that solvers and gradients can be computed without forming dense matrices. This parameterization is the load-bearing mechanism: it lets the same training loop handle blind deblurring, system calibration, acquisition-design optimization, and robust training, and it is what lets solvers transfer across imaging modalities.","core_discovery":"The claimed discovery is that the diversity of modern learning-based image reconstruction can be organized around three compact interfaces: writing the forward model as $y = \\mathcal{N}_\\sigma(A_\\xi(x))$, writing any reconstruction method as $\\hat{x} = R_\\theta(y, A_\\xi, \\sigma)$, and writing any training loss as $\\ell = \\mathcal{L}(\\hat{x}, x, y, A_\\xi, R_\\theta)$. Everything in the library—matrix-free linear operators, adjoints, pseudoinverses, proximal operators, denoisers used as priors, diffusion samplers, GANs, and self-supervised losses—is expressed through these interfaces, so that a method developed for one imaging modality can be dropped into another by swapping the physics object. The authors further assert that this learning-focused scope and the range of realistic operators distinguish DeepInverse from existing computational imaging libraries, which they characterize as optimization-only, tomography-only, or uncertainty-quantification-only.","pith_inferences":["If the unified abstractions hold at scale, the practical bottleneck in computational imaging could shift from re-implementing baseline methods to designing new physics and priors, because comparison across methods becomes nearly free.","The parameterized-operator design may make co-design workflows routine: jointly optimizing acquisition parameters and network weights could become the default way to build new imaging systems.","A concrete testable extension is a benchmark that measures wall-clock time, memory, and reconstruction quality of methods implemented in DeepInverse against hand-written native implementations; low overhead would strengthen the unification claim.","Because the library bundles both distortion metrics (PSNR, SSIM, LPIPS) and no-reference perceptual metrics, it could push the field to report the perception-distortion tradeoff more explicitly in every imaging task."],"forward_implications":["A solver written for one modality, such as MRI, can be evaluated on another, such as tomography or optics, by swapping the Physics object, because the reconstructor interface does not depend on the operator's internals.","Parameterized forward operators make blind inverse problems, system calibration, and joint acquisition-reconstruction design expressible in the same training pipeline as ordinary reconstruction.","The included self-supervised losses—splitting losses, SURE-type estimators, and nullspace losses—allow training without ground-truth images on measurement data alone, directly matching operators such as MRI undersampling masks.","Reproducibility is supported by a common dataset interface, seeded random generation, and automatically tested documentation examples, so published methods can be re-run without reimplementation."],"supporting_citations":[{"why":"Supplies the automatic-differentiation deep-learning framework that every module in the package builds on.","marker":"[1]"},{"why":"Compared as an optimization and plug-and-play-only library that DeepInverse claims to extend with training tools and a wider solver range.","marker":"[2]"},{"why":"Compared as a variational-only library lacking trainers, custom loss functions, and non-optimization solvers.","marker":"[3]"},{"why":"Compared as a Bayesian uncertainty-quantification library that does not focus on learning-based reconstruction.","marker":"[4]"},{"why":"Compared as a tomography-focused library without deep-learning pipelines for inverse solvers.","marker":"[6]"},{"why":"Compared as a tomography-focused library without deep-learning pipelines for inverse solvers.","marker":"[7]"},{"why":"Establishes plug-and-play priors, one of the reconstruction families the library unifies under a single solver interface.","marker":"[33]"},{"why":"Supplies the self-supervised-loss benchmarking that the library's loss module consolidates across inverse problems.","marker":"[53]"}],"fun_headline_variants":["Three interfaces unify deep-learning imaging reconstruction","Python package links deep learning to every imaging inverse problem","One library, every modality: deep-learning image reconstruction","Deep learning for imaging inverse problems, unified in Python","Swap physics, keep the network: DeepInverse unifies reconstruction"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The claim that the library unifies all these methods rests on the assumption that its three shared interfaces can express each listed solver without significant workarounds or hidden performance penalties.","fun_headline_variants_meta":{"raw":{"variants":["Three interfaces unify deep-learning imaging reconstruction","Python package links deep learning to every imaging inverse problem","One library, every modality: deep-learning image reconstruction","Deep learning for imaging inverse problems, unified in Python","Swap physics, keep the network: DeepInverse unifies reconstruction"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000171,"raw_usage":{"total_tokens":1196,"prompt_tokens":795,"completion_tokens":401,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":411,"completion_tokens_details":{"reasoning_tokens":324}},"tokens_in":411,"tokens_out":401,"duration_ms":22227,"temperature":1.0,"reasoning_tokens":324,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-07T13:57:06.472983+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Implement a representative method from each family—an unfolded MRI network, a plug-and-play ADMM solver, and a diffusion posterior sampler—twice, once with DeepInverse and once in native code, and compare wall-clock time, memory, and reconstruction quality on identical data. If any listed method cannot be expressed through the public interfaces, or runs with substantially degraded efficiency, the unification claim fails.","supporting_citations":[{"cited_title":"Ehrhardt, Gre- gory R","cited_arxiv_id":null,"evidence_quote":"Compared as a tomography-focused library without deep-learning pipelines for inverse solvers."},{"cited_title":"Core Imaging Library-part I: a versatile python framework for tomographic imaging","cited_arxiv_id":null,"evidence_quote":"Compared as a tomography-focused library without deep-learning pipelines for inverse solvers."},{"cited_title":"Cuqipy: I","cited_arxiv_id":null,"evidence_quote":"Compared as a Bayesian uncertainty-quantification library that does not focus on learning-based reconstruction."}],"review_version":1}