{"id":"37f44862-c882-48a0-be1a-4fdb6d598226","arxiv_id":"2509.07566","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"low","formal_verification":"none","parameter_count":0,"one_line_summary":"A new .brim file format plus open-source tools for Brillouin microscopy aims to standardize data storage and analysis for better reproducibility.","lead":"This paper introduces a standardized file format (.brim) and open-source software for storing and analyzing Brillouin microscopy data, which maps mechanical properties of cells and tissues. The goal is to make Brillouin datasets easier to share, compare, and reproduce across labs.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The broad multi-modality claim rests on an untested conversion path for non-imaging/higher-dimensional spectra; the PSD shape constraint in BrimConverter may flatten or lose extra parameter axes.","rationale":"The reader's weakest assumption correctly identifies schema completeness as the load-bearing condition. My read agrees but points to a more specific, testable mechanism: the BrimConverter's flattening to (z, y, x, f) appears to conflict with the advertised support for arbitrary multidimensional spectra. The paper's four example datasets are all spatial imaging datasets, so they do not exercise this mechanism. The concern does not overturn the paper's value as a software/standards proposal: the code is open, the examples exist, and extensibility is provided through subtypes and custom groups. However, the broadest sentence of the abstract—'supports data from the diverse range of Brillouin microscope implementations'—should be read as supported only for the demonstrated spatial-imaging cases until a round-trip test with a non-spatial extra axis is shown. This is the same conditional verdict the reader reached, so I would not change the overall verdict. The proposed test would settle whether the gap is merely a documentation issue or a structural limitation.","tokens_in":11007,"tokens_out":2837,"duration_ms":33899,"concrete_test":"Build a synthetic .brimX HDF5 file containing a PSD of shape (5, 512) for five angle-resolved spectra, with an 'Angle' attribute/axis group. Convert it to .brim and back using BrimConverter (brimX2brim, then brim2brimX). If the output cannot reproduce the (5, 512) shape and the angle values—e.g., the 5 becomes an image dimension, is silently dropped, or the round-trip requires external knowledge of which axis was angle—then the conversion path fails for non-spatial multidimensional data, and the multi-modality claim should be narrowed to the demonstrated imaging modalities.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim is that the framework supports spontaneous/stimulated, confocal/line-scanning, time-/frequency-domain modalities. That claim is supported by only four imaging datasets. The weakest condition is that the .brim PSD container and the .brimX/.brim conversion preserve arbitrary acquisition dimensions. The supplementary text says .brim PSDs 'can optionally store multidimensional spectra' (e.g., angle-resolved measurements), but the BrimConverter section states that HDF5_BLS arrays of arbitrary dimensions are 'reshaped into the array-structure enforced by Brimfile, e.g., an array containing PSDs should be of shape (z, y, x, f)'. If this constraint is enforced generally, then any measurement with an extra physical axis (angle, time delay, pump-probe phase) is either collapsed into the spatial dimensions or lost in the round-trip, and the 'multidimensional' guarantee is not realized. The paper provides no round-trip test or example with a non-spatial extra dimension, so the load-bearing assumption of schema completeness is unsupported exactly where the broadest claim is made. This is addressable rather than fatal; it limits what can currently be claimed as 'supported'.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes two standardized file formats for Brillouin microscopy data: .brim, a Zarr-based format for imaging data, and .brimX, an HDF5-based format for broader spectroscopy and multi-parameter experiments. It presents an open-source software stack including the brimfile Python library, the HDF5_BLS library and GUI, the BrimConverter library for .brim↔.brimX conversion, the BrimView browser-based visualization/analysis application, and a Napari plugin. The authors claim the framework supports the diversity of Brillouin microscope implementations — spontaneous and stimulated scattering, confocal and line-scanning modalities, and time- or frequency-domain detection — and illustrate this with four example datasets. The paper positions the work as a community standardization effort to improve FAIR data practices, reproducibility, and cross-laboratory comparability.","tokens_in":11277,"tokens_out":2281,"duration_ms":26576,"significance":"If the framework delivers on its claims, it would be a valuable contribution to the Brillouin microscopy community. The software is genuinely open-source, documented, and accompanied by public example datasets, which is a practical strength. The proposal addresses a real and increasingly urgent need for standardized data storage and metadata in a field where reproducibility is a known bottleneck. The use of Zarr for cloud compatibility and HDF5 for flexibility is reasonable, and the provision of GUI tools lowers adoption barriers for non-expert users. However, the paper's central breadth claim — support for all major Brillouin modalities — is only partially demonstrated, and the file-conversion design appears to impose shape constraints that may contradict the stated support for multidimensional spectra. The manuscript is best viewed as a promising standards proposal that needs additional validation and scoping before the broadest claims can be accepted.","major_comments":[{"comment":"The .brim specification states that the PSD array 'can optionally store multidimensional spectra', including angle-resolved measurements. However, the BrimConverter section states that HDF5_BLS arrays of arbitrary dimensions are 'reshaped into the array-structure enforced by Brimfile, e.g., an array containing PSDs should be of shape (z, y, x, f)'. If this constraint is enforced generally, then any measurement with an extra physical axis (angle, time delay, pump-probe phase) is either collapsed into the spatial dimensions or lost in round-trip conversion. The manuscript provides no round-trip test and no example with a non-spatial extra dimension. This is load-bearing because the paper's central claim is support for the full diversity of Brillouin implementations. Please either relax the shape constraint, define an explicit representation for parameter axes, or provide a concrete example","section":"SI, 'Brim file format for imaging data' and 'BrimConverter library'"},{"comment":"The paper claims support for 'the diverse range of Brillouin microscope implementations — including spontaneous and stimulated scattering, confocal and line-scanning modalities, and time- or frequency-domain detection'. The support is demonstrated with four imaging datasets only: one line-scanning spontaneous, one confocal spontaneous, one pulsed stimulated, and one full-field FTBM. All four are spatial-imaging datasets; none exercises a non-spatial extra parameter axis, a pure spectroscopy workflow, or a non-imaging acquisition. This makes the breadth claim stronger than the evidence. I recommend either adding at least one example that exercises the multidimensional/parameter-axis path or reformulating the claim to state explicitly that these modalities are supported for imaging data and that non-imaging and higher-dimensional cases are planned/partially supported.","section":"SI, 'Example .brim files' and Abstract"},{"comment":"The metadata schema (brim_file_metadata.md and attributes_v1.0.xlsx) is asserted to be sufficient for reproducible acquisition and processing, but the manuscript contains no systematic validation that the attribute set covers instrument-specific calibrations, arbitrary experimental conditions, or the variations described in the cited consensus statement (Ref. 11/8). The paper also notes that additional groups/attributes can be added without breaking compatibility, but such extensions are not readable by standard tools unless defined as subtypes. This is a correct design compromise, but the completeness of the core metadata schema remains untested. Please provide a validation table mapping the attributes used in the four example datasets to the schema, and state explicitly which metadata fields are required, recommended, or optional, so that the reproducibility claim is verifiable.","section":"SI, 'Metadata' and 'BrimX file format'"}],"minor_comments":[{"comment":"The BrimView URL appears corrupted in the manuscript text: 'https://biobrillouin.org/brihttps://github.com/prevedel-lab/BrimView'. Please correct this.","section":"Code availability"},{"comment":"The class name 'AnalysysResults' contains a typo; it should be 'AnalysisResults'. This affects the API documentation and code examples.","section":"SI, 'Brimfile Python library'"},{"comment":"The term 'multidimensional spectra' is used in the .brim specification but never formally defined. Please clarify whether it means multiple parameter axes, multiple spectral regions, or something else, and show how such data are dimensioned and interpreted in the file.","section":"General"},{"comment":"Supplementary Table 1 uses fill characters (stars, checks, circles) without a legend. Please make the table self-explanatory or add a legend.","section":"SI, 'BrimView'"},{"comment":"The statement 'Exemplary imaging data presented in figures are available upon request' is not consistent with the FAIR principles the paper advocates. If possible, provide persistent identifiers for the figure datasets as well.","section":"Data availability"}],"recommendation":"major_revision","confidential_remarks":"This is a standards proposal rather than a new physical result, and the refereeing bar should be applied accordingly. The software is real and publicly accessible, which is a strong point. The main risk is overclaiming: the multidimensional-spectra guarantee appears to conflict with the actual conversion code, and the breadth of modality support is demonstrated on only four imaging datasets. The authors can address this by adding a conversion round-trip test and a non-spatial-parameter example, or by scoping the claims. I see no ethical or novelty concerns; the conflicts of interest are properly disclosed."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Quick take: this is a real contribution. Brillouin microscopy needs a common data container, and the authors have shipped working code, a sensible schema, and four example datasets spanning several instrument types. If you work in this field, you should look at it. The weak spot is not the idea, it's the gap between the \"supports all modalities\" claim and what the conversion layer actually preserves.\n\nWhat's new: the .brim format (Zarr v3) with required PSD/Frequency/Scanning groups, the .brimX HDF5 wrapper, and the BrimConverter/BrimView/HDF5_BLS toolchain. Building on OME-Zarr and the recent consensus statement is the right move; the metadata recommendations are concrete and align with the field's push toward FAIR data. The code is open, documented, and the examples cover confocal, line-scan, stimulated, and FTBM modalities. That's real evidence of effort and partial support for the claim.\n\nSoft spots, in order of weight. First, the multidimensional claim. The spec says PSDs can be multidimensional (angle-resolved, etc.), but BrimConverter enforces shape (z, y, x, f) when converting from .brimX. There is no round-trip test and no example with a non-spatial extra axis. So the format may support such data in principle, but the main conversion path will flatten or drop those axes. That needs a clarifying statement and ideally a test case. Second, the evidence for completeness is four imaging datasets; there is no systematic test that the schema captures all essential metadata for every modality. The paper acknowledges it's a starting point, which is fair, but the abstract's \"diverse range\" phrasing overreaches. Third, figure data is \"available upon request\"—for a reproducibility-focused paper, that undercuts the message. And the BrimView URL in the code block is mangled. Minor, but sloppy.\n\nMy verdict: the central premise holds up. This is community infrastructure, not a physics breakthrough, and it should be judged as such. The issues are addressable with a revision that tightens the modality claims and adds a conversion test. I'd send it to peer review and ask for those changes.","headline":"A serious, well-executed standards proposal for Brillouin microscopy; the broad compatibility claim is ahead of the demonstrated conversion path.","tokens_in":11763,"tokens_out":1936,"would_cite":true,"duration_ms":20758,"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":"Two open file formats aim to make Brillouin microscopy data reproducible and comparable across labs.","keywords":["Brillouin microscopy","file format standardization","Zarr","HDF5","open-source software","reproducibility","biomechanical imaging"],"falsifier":"The claim would be falsified by an existing Brillouin modality whose raw data cannot be represented as a PSD array plus Frequency axis and Scanning group without loss or flattening—for example, a time-domain instrument with nonuniform sampling that requires per-pixel calibration metadata—such that faithful round-tripping through .brim and .brimX is impossible.","tokens_in":10937,"feed_emoji":"🔬","tokens_out":5096,"duration_ms":57159,"temperature":0.7,"pith_summary":"Brillouin microscopy maps the mechanical properties of living samples by measuring the tiny frequency shift of scattered light, but each lab currently stores and processes its data differently, making results hard to compare when the relevant differences are only a few percent. This paper proposes a standardized file format, .brim, built on Zarr v3, that stores raw spectra, the frequency axis, spatial scanning information, and analysis results together with their metadata. A complementary format, .brimX, stores whole multi-parameter experiments in HDF5, and the authors provide Python libraries, a browser-based viewer, a desktop GUI, and a converter so data from spontaneous or stimulated scattering, confocal or line-scanning systems, and time- or frequency-domain detection can share one analysis pipeline. The central claim is that adopting these formats would make Brillouin studies reproducible, shareable, and compatible with existing bioimaging tools, easing the field's transition from niche technique to mainstream bioimaging.","feed_headline":"One file format unifies Brillouin microscopy data","feed_subtitle":"New .brim and .brimX standards store spectra, metadata, and fits so results can be compared across labs.","key_machinery":"The PSD/Frequency/Spatial-scan triple: every Brillouin dataset is represented as a power spectral density array, a frequency axis, and a flexible Scanning group mapping spectra to voxel positions, while different fits live in separate Analysis_m groups. This canonical decomposition is what lets one set of tools ingest data from diverse instrument designs and keeps processing assumptions machine-readable.","core_discovery":"On the paper's own terms, the central contribution is a standardization scheme: every Brillouin measurement is reduced to a common pair of arrays, a power spectral density (PSD) and a frequency axis, plus a flexible Scanning group linking spectra to spatial positions and optional Analysis groups storing fitted quantities like shift and linewidth. The .brim format encodes this scheme in Zarr v3, chosen for cloud compatibility and parallel I/O, with defined metadata groups and extensible 'subtypes' for instrument-specific additions. A second format, .brimX, stores complete experiments in HDF5 with hierarchical attributes and a 'Brillouin_type' tag so any HDF5-compatible tool can read it. The a","pith_inferences":["Not in the paper: if the PSD/Frequency pair becomes the shared exchange representation, each new instrument type only needs one converter into the canonical pair, not bespoke analysis software; the paper demonstrates four such conversions but leaves this one-converter-per-modality principle implicit.","Not in the paper: machine-readable metadata and standardized array layouts would make pooled multi-lab datasets usable for training machine-learning spectral analysis models, an application the authors do not discuss.","Not in the paper: the framework's generality could be tested by saving a non-Brillouin hyperspectral dataset, such as Raman or fluorescence emission maps, in .brim; the paper notes this possibility in passing but does not perform the experiment."],"forward_implications":["Published Brillouin datasets would carry the optical configuration, calibration, and fitting model needed to reproduce reported shift and linewidth values.","Cross-lab comparisons become feasible even when the parameter changes of interest are only a few percent, addressing the reproducibility problem documented by the field's consensus statement.","Commercial Brillouin microscopes could export data that existing open-source viewers and pipelines read directly, lowering the barrier for new users.","Cloud storage plus a browser-based viewer enables sharing large datasets without requiring local software installation.","The same PSD/Frequency structure could extend to other hyperspectral imaging modalities and to correlating Brillouin with Raman or fluorescence measurements."],"supporting_citations":[{"why":"Documents that inconsistent data handling makes Brillouin results vary across labs; this is the problem the proposed formats are built to solve.","marker":"11"},{"why":"Establishes OME-Zarr and Zarr v3, the cloud-optimized container standard on which the .brim format is built.","marker":"12"},{"why":"Defines OME-TIFF, the export target for derived spatial maps so established image-analysis tools can open them.","marker":"13"},{"why":"Sets the FAIR data principles that the framework's metadata and storage design explicitly aims to support.","marker":"14"},{"why":"Provides the OME data model that the authors target for future integration with broader bioimaging standards.","marker":"15"},{"why":"Supplies the REMBI metadata recommendations that the proposed metadata schema is designed to align with.","marker":"16"}],"fun_headline_variants":["Standard file format unites Brillouin microscopy data","Open-source .brim format standardizes Brillouin microscopy","New file format for reproducible Brillouin analysis","Brillouin data gets a common open-source format"],"cache_read_input_tokens":2688,"weakest_assumption_plain":"The metadata schema and array structures are complete enough to represent every Brillouin modality without losing instrument-specific calibration details; the paper demonstrates this on four datasets but not on the full range of existing instruments.","fun_headline_variants_meta":{"raw":{"variants":["Standard file format unites Brillouin microscopy data","Open-source .brim format standardizes Brillouin microscopy","New file format for reproducible Brillouin analysis","Brillouin data gets a common open-source format"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000208,"raw_usage":{"total_tokens":1148,"prompt_tokens":562,"completion_tokens":586,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":306,"completion_tokens_details":{"reasoning_tokens":525}},"tokens_in":306,"tokens_out":586,"duration_ms":6211,"temperature":1.0,"reasoning_tokens":525,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-04T21:55:24.136075+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"The claim would be falsified by an existing Brillouin modality whose raw data cannot be represented as a PSD array plus Frequency axis and Scanning group without loss or flattening—for example, a time-domain instrument with nonuniform sampling that requires per-pixel calibration metadata—such that faithful round-tripping through .brim and .brimX is impossible.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Establishes OME-Zarr and Zarr v3, the cloud-optimized container standard on which the .brim format is built."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Defines OME-TIFF, the export target for derived spatial maps so established image-analysis tools can open them."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Sets the FAIR data principles that the framework's metadata and storage design explicitly aims to support."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Provides the OME data model that the authors target for future integration with broader bioimaging standards."},{"cited_title":"multidimensional","cited_arxiv_id":null,"evidence_quote":"Supplies the REMBI metadata recommendations that the proposed metadata schema is designed to align with."}],"review_version":1}