REVIEW 3 major objections 5 minor 16 references
BIOMERO 2.0: end-to-end FAIR infrastructure for bioimaging data import, analysis, and provenance
T0 review · 3 major / 5 minor · reviewed 2026-08-03 · deepseek-v4-flash
Pith's one-line read BIOMERO 2.0 transforms OMERO into a provenance-aware, FAIR-compliant bioimaging platform by recording every import, metadata entry, and HPC analysis run.
desk verdict A useful, well-documented integration of OMERO import, metadata, and provenance that needs evaluation data and a candid discussion of its in-place import failure modes. read the letter →
The pith
A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.
The reading
What carries the argument
The load-bearing mechanism is BIOMERO.db, an event-sourcing database fed by all three subsystems, together with the symbolic-link in-place import. The importer uses OMERO's command-line import with a link-transfer flag so that OMERO references the original file on remote storage instead of duplicating it; the database records the order, user, preprocessing container, and resulting key-value metadata. The analyzer appends workflow events to the same database, and web dashboards render those events as live job status and provenance. OMERO.forms contributes versioned JSON-schema-based metadata forms whose submitted values are stored on the image objects themselves.
What would settle it
Move or unmount the remote storage that holds a linked image, or delete the underlying raw file, then open that image in OMERO and attempt to view or download it; if the image fails to load or the link is broken, the claim that in-place import ensures data integrity and durable access does not hold in that scenario.
Extended reading notes
Core claim
The central claim is that provenance can be embedded into every stage of an OMERO-based imaging workflow rather than bolted on afterward. In the implemented system, the BIOMERO.importer performs in-place imports by creating OMERO database entries and a symbolic link to the original file on remote storage, with each import order assigned a unique ID and optionally preceded by a containerized preprocessing step; OMERO.forms records structured metadata with immutable versioning; and BIOMERO.analyzer writes all workflow actions to an event-sourcing database from which dashboards and full provenance records are generated. Together these layers mean that every image and every derived result carrie
Load-bearing premise
The provenance and data-integrity promise rests on the in-place import's symbolic link remaining valid: OMERO stores a pointer to a file on remote storage, so that storage must stay mounted at the same path with the same permissions for as long as the image is referenced.
Editorial extensions
If this is right
- Large imaging datasets can be ingested without duplicating them on the OMERO server, reducing storage cost and removing the desktop-client dependency.
- Every analysis run can be audited: input images, workflow and container versions, parameters, and outputs are linked by a workflow UUID that is searchable in OMERO.
- Structured metadata entered through forms is versioned and attached to images, so experimental context survives even when images are shared or reanalyzed.
- Imports and analyses run asynchronously with dashboard monitoring, so users can close their browser and track progress later, which suits high-throughput experiments.
- Because the provenance is indexed and machine-readable, it supports reuse and integration with other FAIR-aligned tools and repositories.
Reading between the lines
- The in-place import strategy implies a hard operational dependency: if the remote filesystem is unmounted, repathed, or the linked file is deleted, the provenance record survives but the pixels become inaccessible; the paper's data-integrity claim therefore holds only while the external storage stays stable.
- The event-sourcing log could be exported in a standard provenance interchange format to make the history readable outside OMERO; the paper does not yet claim such an export.
- The importer/analyzer split appears domain-agnostic, so the same architecture could plausibly serve other scientific imaging repositories or non-image datasets, though the paper only demonstrates bioimaging.
- Provenance is complete only for actions that pass through the platform: direct edits to files on the remote storage, or analyses run outside BIOMERO, would be invisible to the recorded history.
Signed reviews
Editorial analysis
A structured set of objections, weighed in public.
Referee Report
Summary. The paper describes BIOMERO 2.0, an open-source extension of the OMERO bioimaging platform. It adds a web-based importer that performs in-place imports from remote storage via OMERO.cli with the 'transfer=ln_s' mode, optionally preprocessing data using Podman containers; an OMERO.forms plugin for JSON-schema-based structured metadata with versioning; a BIOMERO.analyzer component that coordinates containerized analyses on HPC clusters and logs events to a BIOMERO.db; and Metabase dashboards integrated into OMERO.web. The paper claims this end-to-end architecture makes bioimaging data FAIR-compliant, with full provenance from acquisition through import and analysis. The manuscript is predominantly a systems description supported by 21 supplementary screenshots and links to public code repositories.
Significance. If the described system works as claimed, it would be a useful contribution to the bioimaging community: it addresses a real gap in OMERO's web-based import and provenance capabilities, and it is designed to be modular and deployable in real labs. The strengths are that all code is publicly available under permissive/copyleft licenses, the architecture is described in enough detail to be reproduced, and the event-sourcing approach for tracking analyses is coherent. However, the manuscript does not provide any quantitative evaluation, stress testing, or end-to-end validation on a realistic dataset; the FAIR-compliance and data-integrity claims are therefore asserted rather than demonstrated. The central ideas are defensible, but the evidence provided is not yet at the level expected for a serious software-infrastructure paper.
major comments (3)
- [Results (all subsections); no evaluation section] The manuscript contains no evaluation section. Claims such as 'ensuring data integrity', 'real-time provenance', and 'scalability' (Architecture and design; BIOMERO.importer) are supported only by architecture diagrams and screenshots. There is no end-to-end test on a large or representative dataset, no import throughput or latency measurement, no comparison against OMERO.insight or BIOMERO 1.0, and no failure-injection testing. This is load-bearing for the paper's central claim that BIOMERO 2.0 is FAIR-compliant and provenance-aware in practice. The authors should add an evaluation with defined metrics, a realistic dataset, and failure scenarios; without it, the paper reads as a software announcement rather than a validated infrastructure study.
- [Results, BIOMERO.importer; Figure S1; Figure S7] Figure S7 shows imports performed with '--transfer=ln_s', and Figure S1 confirms that OMERO creates a symbolic link to the file on remote storage rather than copying it. The paper states this approach 'ensures data integrity by keeping raw data in its original storage location'. However, the same design means that every linked image in OMERO is only accessible as long as the remote filesystem remains mounted at the same absolute path with read/write permissions for the lifetime of the OMERO object. If the storage is unmounted, repathed, or the link target is moved, all linked images silently become broken references. The manuscript does not discuss this failure mode, nor does it describe any integrity checks, link verification, or copy-on-demand fallback. Since 'accessible' and 'reusable' are core FAIR principles, this is a structural premise of the provenance promise that must be tested
- [Introduction; Provenance across all subsystems; OMERO.forms] The provenance and immutability claims are stronger than what the described implementation appears to guarantee. The Introduction says OMERO.forms 'records form and input versions immutably', but the described mechanism is a versioned JSON-schema form stored in OMERO/BIOMERO.db; nothing in the paper establishes that records cannot be edited or deleted by someone with administrator rights, and 'immutably' is not defined or tested. Similarly, the event-sourcing log (BIOMERO.analyzer) records what containers report, but the system cannot detect a preprocessing container that writes incorrect output metadata. Since FAIR R1.2 provenance and reproducibility are the main claims, a concrete test (e.g., tamper with a log entry or have a container produce inconsistent metadata and show that the system detects or records this) is needed.
minor comments (5)
- [References] References 6, 7, and 9 are self-citations to the authors' own repositories and prior work. While relevant, please indicate versioned releases or commit hashes so readers can reproduce the exact state of the code described.
- [Figure S1] The caption states that if a link points to a locally converted file, 'it is redirected to the remote converted file, and the local copy is removed'. This is an important implementation detail; specify how the redirection is performed and what happens if the remote file is unavailable at that moment.
- [Provenance across all subsystems] The sentence 'All metadata fields are indexed and fully searchable within OMERO' is likely overbroad. OMERO natively indexes certain key-value pairs, but not necessarily all arbitrary metadata. Please clarify the searchability scope.
- [Figure S13/S14] The figures consistently refer to 'BIAFLOW' while the text uses 'BIAFLOWS'. Use a single spelling.
- [Concurrency] The paper mentions parallel worker threads for imports but does not discuss file-locking or race conditions when multiple imports target the same file or directory. A short note would help.
Circularity Check
No significant circularity: BIOMERO 2.0's claims rest on an openly released implementation and ordinary dependency attributions, not on a self-referential derivation.
full rationale
This is a systems/software paper rather than a derivation with equations or fitted parameters. The central claims—that BIOMERO 2.0 records imports, metadata forms, container versions, parameters, and analysis outputs for provenance—are supported by the described architecture and by public repositories cited for the analyzer, importer, OMERO.forms, preprocessing containers, and deployment configuration. The self-citations (refs 6, 7, 9) point to the authors' prior BIOMERO 1.0 paper and to their own code repositories; these are code-backed and externally runnable, so under the review rules they function as independent evidence rather than as a load-bearing circular argument. The closest self-referential element is that screenshots show the authors' own UI and provenance records, but this is implementation evidence, not a derivation that assumes its conclusion. The in-place import via OMERO.cli 'transfer=ln_s' (Fig. S7) and the claim that keeping raw data in place 'ensures data integrity' raise operational robustness concerns about symlink lifetime and storage availability, but that is a correctness/engineering risk, not circularity. No step reduces a claimed prediction to a fitted input, an imported uniqueness theorem, or a renamed existing result.
Assumptions & free parameters
assumptions (5)
- domain assumption OMERO server, BioFormats, OMERO.cli, and Glencoe's omero-zarr-pixel-buffer provide the base import/view capabilities BIOMERO 2.0 wraps.
- domain assumption Remote storage is mounted and path-stable on the host executing OMERO.cli for the lifetime of imported images (ln_s symbolic-link import).
- domain assumption An HPC cluster with a Slurm scheduler and a container runtime (Podman on the importer host) are available for the analyzer subsystem.
- ad hoc to paper Recording parameters, versions, and results in a custom BIOMERO.db event-sourcing schema constitutes FAIR R1.2 provenance.
- ad hoc to paper Converter containers follow the paper-defined JSON input/output contract and report their actions truthfully.
invented entities (2)
-
BIOMERO.db event-sourcing ledger (PostgreSQL + Metabase views)
independent evidence
-
OMERO.forms versioned JSON-schema metadata forms ('form and input versions immutably')
independent evidence
Cite this review
Pith. "Pith review of BIOMERO 2.0: end-to-end FAIR infrastructure for bioimaging data import, analysis, and provenance." pith.science (2026). https://pith.science/paper/3J2N5MLI
@misc{pith2026251113611,
author = {Pith},
title = {Pith review of: BIOMERO 2.0: end-to-end FAIR infrastructure for bioimaging data import, analysis, and provenance},
year = {2026},
howpublished = {\url{https://pith.science/paper/3J2N5MLI}},
note = {Machine review of arXiv:2511.13611}
}
read the original abstract
We present BIOMERO 2.0, a major evolution of the BIOMERO framework that transforms OMERO into a FAIR-compliant (findable, accessible, interoperable, and reusable), provenance-aware bioimaging platform. BIOMERO 2.0 integrates data import, preprocessing, analysis, and workflow monitoring through an OMERO.web plugin and containerized components. The importer subsystem facilitates in-place import using containerized preprocessing and metadata enrichment via forms, while the analyzer subsystem coordinates and tracks containerized analyses on high-performance computing systems via the BIOMERO Python library. All imports and analyses are recorded with parameters, versions, and results, ensuring real-time provenance accessible through integrated dashboards. This dual approach places OMERO at the heart of the bioimaging analysis process: the importer ensures provenance from image acquisition through preprocessing and import into OMERO, while the analyzer records it for downstream processing. These integrated layers enhance OMEROs FAIRification, supporting traceable, reusable workflows for image analysis that bridge the gap between data import, analysis, and sharing.
Reference graph
Works this paper leans on
-
[1]
Massei, R., Busch, W., Serrano-Solano, B., Bernt, M., Scholz, S., Nicolay, E.K., Bohring, H., and Bumberger, J. (2025). High-content screening (HCS) workflows for FAIR image data management with OMERO. Sci Rep 15, 16236. https://doi.org/10.1038/s41598-025-00720-0
-
[2]
https://www.go- fair.org/fair-principles/r1-2-metadata-associated-detailed-provenance/
R1.2: (Meta)data are associated with detailed provenance GO FAIR. https://www.go- fair.org/fair-principles/r1-2-metadata-associated-detailed-provenance/
-
[3]
Wilkinson, M.D., Dumontier, M., Aalbersberg, Ij.J., Appleton, G., Axton, M., Baak, A., Blomberg, N., Boiten, J.-W., da Silva Santos, L.B., Bourne, P.E., et al. (2016). The FAIR Guiding Principles for scientific data management and stewardship. Sci Data 3, 160018. https://doi.org/10.1038/sdata.2016.18. 15
-
[4]
Allan, C., Burel, J.-M., Moore, J., Blackburn, C., Linkert, M., Loynton, S., MacDonald, D., Moore, W.J., Neves, C., Patterson, A., et al. (2012). OMERO: flexible, model-driven data management for experimental biology. Nat Methods 9, 245–253. https://doi.org/10.1038/nmeth.1896
-
[5]
Import data using the Desktop Client — OMERO guide latest documentation https://omero- guides.readthedocs.io/en/latest/upload/docs/import-desktop-client.html
-
[6]
Luik, T.T., Rosas-Bertolini, R., Reits, E.A.J., Hoebe, R.A., and Krawczyk, P.M. (2024). BIOMERO: A scalable and extensible image analysis framework. Patterns 5. https://doi.org/10.1016/j.patter.2024.101024
arXiv 2024
-
[7]
(NL-BioImaging AM)
NL-BioImaging/OMERO.forms (2025). (NL-BioImaging AM)
2025
-
[8]
Russell, D.P.W., and Sorger, P.K. (2017). Maintaining the provenance of microscopy metadata using OMERO.forms software. Preprint at bioRxiv, https://doi.org/10.1101/109199 https://doi.org/10.1101/109199
Show all 16 references
-
[9]
(Cellular Imaging, Amsterdam UMC)
Cellular-Imaging-Amsterdam-UMC/OMERO.biomero (2025). (Cellular Imaging, Amsterdam UMC)
2025
-
[10]
(Glencoe Software)
glencoesoftware/omero-zarr-pixel-buffer (2025). (Glencoe Software)
2025
-
[11]
Sarkans, U., Chiu, W., Collinson, L., Darrow, M.C., Ellenberg, J., Grunwald, D., Hériché, J.-K., Iudin, A., Martins, G.G., Meehan, T., et al. (2021). REMBI: Recommended Metadata for Biological Images— enabling reuse of microscopy data in biology. Nat Methods 18, 1418–1422. htt...
2021 doi
-
[12]
experiment.db
Hosseini, R., Vlasveld, M., Willemse, J., van de Water, B., Le Dévédec, S.E., and Wolstencroft, K.J. (2023). FAIR High Content Screening in Bioimaging. Sci Data 10, 462. https://doi.org/10.1038/s41597-023-02367-w. Figure Legends Figure 1 – Schematic overview of the BIOMERO 2.0...
2023 doi
-
[13]
(Cellular Imaging, Amsterdam UMC)
Cellular-Imaging-Amsterdam-UMC/ConvertLeica-Docker (2025). (Cellular Imaging, Amsterdam UMC)
2025
-
[14]
(NL-BioImaging AM)
NL-BioImaging/biomero-converter (2025). (NL-BioImaging AM)
2025
-
[15]
General container requirements - biomero-converter https://nl- bioimaging.github.io/biomero-converter/container/
-
[16]
OMERO.biomero Plugin Administration — NL-BIOMERO latest documentation https://cellular-imaging-amsterdam-umc.github.io/NL-BIOMERO/sysadmin/omero- biomero-admin.html#configuration-file-management
Reviewed August 3, 2026 · model on record in the stance chip above.
Discussion (0). Continue with ORCID to comment.