Technical Review: MPS (Miniscope Processing Suite)

Miniscope Processing Suite (MPS): Technical Review

Review date:July 01, 2026

Scope:MPS public source and documentation, the March 10, 2026 eLife Reviewed Preprint and public peer review, the installer documentation, and selected current implementation files. This is a source audit, not a fresh runtime benchmark.

Executive assessment

The Miniscope Processing Suite addresses a real problem in calcium-imaging practice. A scientifically capable algorithm is of limited value when laboratories cannot install it reliably, keep a multi-hour run alive, inspect intermediate results, or recover from a late-stage failure. MPS responds by putting an eight-stage one-photon calcium-imaging workflow behind a graphical interface, while retaining parameter controls, previews, checkpoints, logs, and automation.[^1]

The project is more than a graphical wrapper around an existing CNMF implementation. It combines preprocessing, recursive phase-correlation motion estimation, candidate generation from a custom nonnegative SVD workflow, watershed segmentation, temporal optimization, local multi-penalty nonnegative LASSO spatial updates, repeated filtering, and multi-format export. The current repository also contains command-line helpers for running individual steps or multiple analyses, so the software is not exclusively GUI-operated even though the GUI remains its primary product interface.[^2]

The central conclusion of this review is deliberately split in two:

>MPS has strong evidence that its workflow can complete very large one-photon datasets on a suitably provisioned workstation. It does not yet have equally strong evidence that its final neuronal population is more accurate than, or equivalent to, the populations recovered by established alternatives on common ground-truth data.

That distinction is also visible in the public eLife review. The Reviewed Preprint was assessed as valuable, with solid evidence for the software and performance contribution, while reviewers identified the absence of controlled ground-truth source-extraction benchmarking and direct contemporary comparisons as important limitations.[^3]

The review should therefore avoid two opposite mistakes. MPS should not be dismissed as “just a GUI,” because the workflow contains substantive algorithmic and systems-engineering work. It also should not be described as a validated accuracy replacement for CaImAn/CNMF-E, MiniAn, MIN1PIPE, Suite2p, or other pipelines, because that comparison has not yet been established.

1. Evidence hierarchy and current software state

Three evidence layers need to be kept separate.

First, the eLife Reviewed Preprint documents the authors' scientific and performance study. It is Version 1, dated March 10, 2026, and is markedNot revised. The public record therefore contains the original preprint, eLife's assessment, public reviews, and a provisional author response rather than a revised Version of Record.[^3]

Second, the current GitHub repository has continued to change. The repository now contains additional or revised processing stages, including an artifact-rejection quarantine step, reorganized source files, headless execution helpers, and recent changes to merging and memory handling.[^2]These features should not automatically be attributed to every analysis reported in the Reviewed Preprint.

Third, the installer is maintained in a separate repository and delivery path. The main analysis repository is namedMPS_1.0.0, but its GitHub release page currently says there are no releases. The installer repository has its own distribution artifacts and release history.[^4]For reproducible methods, “MPS 1.0.0” is not sufficiently precise by itself. A paper should record the exact analysis-repository commit, installer version, parameter file, and environment lockfile.

The current repository is active enough that it should not be treated as abandoned. At the same time, it remains a young scientific application with a modest development history, one currently listed issue in the analysis repository, documented workarounds, and no formal release in that repository.[^2][^4]A polished interface and a1.0.0label should not be used as substitutes for versioned scientific validation.

2. “No-code” is a workflow description, not a claim that expertise is unnecessary

MPS's normal interaction model is genuinely no-code. Users configure stages through the graphical interface, inspect diagnostic plots, save parameters, reload cached data, and run later stages automatically. That is a substantial accessibility improvement over asking every laboratory to maintain a Python notebook and resolve a large scientific dependency stack manually.[^1]

The installation claims are less consistent. The main README says that no Git or environment setup is required and that the installer provisions a self-contained Python 3.8 environment. The official installer page, however, currently instructs users to install Git, install Anaconda or Miniforge, runconda init, restart terminals, and then use the installer. It also recommends Mamba as an optional acceleration.[^1][^5]

The most accurate description is therefore:

>MPS provides a no-code analysis workflow after installation, but the current official installation path may still require Git and Conda-family tooling.

“No-code” also does not mean “no scientific judgment.” Users still need to decide whether preprocessing removed biological signal, whether motion estimates are plausible, whether rejected frames are behaviorally biased, whether candidate thresholds are appropriate, whether temporal traces are physiologically credible, and whether a final component is a believable neuronal source. The eLife reviewers explicitly raised the question of whether novice users can interpret the output reliably without stronger diagnostics and tutorials.[^3]

The current repository additionally suppliesrun_step.pyandrun_multiple.py, which support advanced, repeatable, and partly headless execution.[^2]This is useful for laboratories that begin with the GUI but later need scripted batch processing. It also means that “GUI application” is the product emphasis, not the complete technical boundary of the software.

3. Pipeline architecture

The current documented workflow is organized into eight major stages:

1.project and file configuration;

2.preprocessing, motion estimation, erroneous-frame handling, and validation;

3.cropping and NNDSVD initialization;

4.watershed candidate detection, merging, initial traces, and preparation;

5.noise estimation and CNMF validation;

6.initial temporal CNMF update and filtering;

7.local spatial refinement and merging;

8.final temporal update, cleanup, review, and export.[^1]

The most important architectural choice is that expensive source extraction is broken into visible checkpoints. Users can inspect motion, candidate maps, temporal projections, parameter suggestions, spatial footprints, and final traces rather than receiving one opaque result at the end. For multi-hour recordings, the ability to restart from saved intermediate states is operationally important.

The downside is that MPS is a long sequential pipeline. Every stage changes the data or component population presented to the next one. A poor background setting can alter motion estimates; a motion error can alter candidate initialization; a permissive watershed can increase merging burden; a restrictive temporal filter can remove weak neurons; and a spatial update can change the traces used in the final temporal pass. Checkpoints make these decisions visible, but they do not eliminate error propagation.

A methods section should therefore report more than “data were processed with MPS.” It should state which stages ran, which were repeated, which cached outputs were reused, which parameter suggestions were accepted or overridden, and which components were quarantined, removed, merged, or manually hidden.

4. Preprocessing, motion, and artifact handling

Preprocessing

MPS offers median, Gaussian, bilateral, and anisotropic denoising, together with top-hat or uniform background removal.[^1]This flexibility is useful because one-photon recordings differ in blur, shot noise, expression level, illumination, and diffuse background. It also creates a large parameter space in which different operators can generate different inputs for all later stages.

Preprocessing should be evaluated against the raw movie, not only against a visually pleasing processed projection. A good review should preserve or inspect raw and processed summary images, short movie excerpts, intensity distributions, edge behavior, and examples of weak cells before and after filtering. A smoother movie is not necessarily a more scientifically faithful movie.

Motion correction

The standard Step 2c GUI path calls recursive phase-correlation motion estimation with the selected dimension, normallyframe.[^6]The current Step 2c source does not expose or pass a mesh-size parameter. The README separately advertises a mesh-based non-rigid option in the underlying motion functionality.[^1]

The defensible interpretation is:

>Rigid recursive phase-correlation estimation is the clearly exposed standard GUI path. A mesh-based option is advertised in the documentation, but it is not clearly exposed through the current Step 2c GUI source and should not be treated as a routinely verified user-facing feature without confirming the exact execution path.

The documentation also warns that motion correction can require about three times the video size in RAM.[^1]That warning is important because it contradicts any blanket interpretation of MPS as uniformly out-of-core. Some stages are streamed or chunked; others can still require substantial working memory.

Erroneous-frame rejection

MPS can discard frames whose estimated motion exceeds a threshold expressed in standard deviations above the mean. This is useful when catastrophic movement would otherwise distort source extraction. It also creates a possible behavioral selection bias. If high-motion frames occur during a specific action, trial outcome, or arousal state, removing them can alter the biological sample. A rigorous report should preserve the removed frame indices and test whether frame rejection is associated with behavior.

The line-splitting detector is narrower than a general corrupted-frame detector. The documented implementation monitors the leftmost 20 pixels, computes their framewise mean, and flags values above the overall mean plus two standard deviations.[^1]It is a signature-specific heuristic for a known artifact pattern. It does not establish general detection of all line-splitting, codec, dropped-frame, or partial-frame corruption.

Current artifact quarantine

The current repository includes a Step 4h artifact-rejection stage that evaluates features such as size, skew, signal-to-noise, drift, and solidity. Flagged components are saved to a quarantine path rather than simply deleted; the code also contains a guard that prevents all components from being removed when every candidate is flagged.[^7]

This is sensible current behavior because it preserves questionable components for later review. It is also a post-preprint feature and should not automatically be described as part of every analysis in the Reviewed Preprint.

5. Cropping and NNDSVD initialization

Cropping is one of the most practical performance controls in MPS. Removing unused pixels before repeated motion, matrix, and spatial operations reduces storage, memory, and runtime. The documentation appropriately treats a tight field-of-view crop as important rather than cosmetic.[^1]

The NNDSVD stage needs more careful wording than the original review gave it.

MPS uses a custom randomized SVD and nonnegative initialization procedure. The current source can optionally subsample frames, but when subsampling is disabled it allocates a densefloat32array with shape(selected_frames, pixels), fills that array by computing Dask-backed frame slices, and then runs the randomized SVD on the in-memory matrix.[^8]The source explicitly logs the estimated full memory requirement and says “Loading data into memory.”[^8]

MPS is therefore not uniformly out-of-core at this stage. Dask controls how chunks are read, but the selected frame-by-pixel matrix is materialized before the factorization. Cropping and optional frame subsampling can make this tractable; they do not change the underlying memory boundary.

The first NNDSVD component is explicitly assigned asbandf, the background spatial and temporal factors.[^8]This is an implementation convention, not a demonstrated biological theorem that the leading singular structure must always be neuropil or background. In recordings dominated by global neuronal activation, bleaching, motion residuals, illumination changes, or other structured signals, the leading component may not be a pure background source. Users should inspect it.

The README also attributes compact or blob-like structure partly to nonnegativity. Nonnegativity alone does not impose compactness. The current source adds a separate spatial score that favors concentration near the maximum when choosing between positive and negative singular-vector parts.[^8]It is more accurate to describe compactness as arising from the custom thresholding and spatial-regularization logic, not from nonnegativity by itself.

The variance-explained display should also be interpreted carefully. High variance explained by a small number of components does not prove that weak cells have been captured. A small, behaviorally important neuron can explain little of the total pixel variance. NNDSVD is an initialization stage, not a validated neuron census.

6. Watershed detection, merging, and component attrition

Watershed detection converts the initialization maps into an intentionally permissive candidate population. This is a reasonable high-recall strategy: over-seed first, then use later temporal and spatial evidence to remove duplicates and artifacts.

The scientific risk is irreversible pruning. A real source removed during size filtering, temporal filtering, merging, artifact rejection, or final cleanup cannot contribute to the final population unless it is manually recovered later. The current pipeline contains many such decision boundaries.

The eLife figures report large changes in component count at several stages. In the reported dataset, an early temporal filtering stage rejected about 8.8% of components, spatial refinement reduced the population by about 50.8%, and final temporal filtering rejected about 55.1% relative to its reported input stage.[^9]These percentages are not a cumulative accuracy score and should not be added together. They show that the final neuronal population is heavily shaped by downstream filtering.

Component reduction is not itself proof of improvement. A removed component can be an artifact, a duplicate, a poor fit, a weak but genuine neuron, or a biologically real non-somatic source. The current evidence does not establish the truth status of every discarded component. Ground-truth ablation is therefore one of the most important next experiments for MPS.

Merging has the same ambiguity. Spatial overlap and temporal correlation are evidence that two components may represent one source, but neighboring neurons can genuinely overlap and co-activate. A merge threshold is a scientific parameter, not merely a cleanup control.

7. Temporal model and output semantics

A, C, and S

MPS uses the familiar CNMF-style notation, but the arrays should be interpreted as model outputs rather than direct biological measurements.

-Ais an estimated spatial fluorescence footprint. It is not a binary cell membrane or an independently verified anatomical boundary.

-Cis a denoised model-derived calcium component. It is not the raw ROI fluorescence trace.

-Sis a sparse deconvolved event or activity estimate under the selected autoregressive model and sparsity penalty. It is not a direct electrophysiological spike train.

The README currently callsSinferred spike times and amplitudes. The scientifically safer term isinferred event activityunless the output has been separately calibrated against simultaneous electrophysiology for the relevant indicator, frame rate, preparation, and noise regime.[^1]

AR order changes the assumed calcium dynamics. AR(2) can represent more complex temporal behavior than AR(1), but it does not guarantee resolution of closely spaced action potentials and can also fit noise or artifacts more flexibly. Sparse penalties and zero thresholds alter the event population. These are model choices, not purely numerical settings.

What YrA currently computes

TheYrAterminology in MPS is particularly important to correct. The README describes Step 6YrAas the raw projection of the video onto each spatial footprint and explicitly says it is not variance explained.[^1]The current Step 6a source computes, in frame chunks, approximately:

\[

Y A^T - f\,(A b),

\]

when background subtraction is enabled.[^10]

The current Step 8a source uses the same streamed projection structure with the refined spatial components.[^11]

This is a background-adjusted component projection. It isnota full residual trace obtained after subtracting all other neuronal contributions and then projecting the remaining movie. In particular, the visible Step 8a computation does not subtract the completeA Ccontribution of neighboring components before forming the projection.[^11]

The review should therefore avoid alternating between “raw projection,” “residual after removing every other component,” and “variance explained.” The most defensible current description is:

>MPS YrA is a spatial-footprint projection of the movie, optionally adjusted for the rank-one background term, used as input to temporal optimization.

BecauseAcan be normalized by maximum, L1 norm, L2 norm, or not normalized, the amplitude scale of its corresponding temporal projection depends on the chosen normalization. This must be preserved in the methods record.

Cross-session amplitude comparability

The README states that using identical Step 8 parameters makes calcium traces mathematically comparable on an absolute scale across sessions, provided expression and optics are stable.[^1]That claim is too strong.

Identical optimization parameters improve procedural consistency, but they do not remove:

-the scale ambiguity betweenAandCin matrix factorization;

-differences introduced by spatial normalization;

-session-specific background and noise estimates;

-indicator expression changes;

-illumination, gain, focus, bleaching, and field-of-view differences;

-different recovered footprint supports;

-preprocessing and motion-correction differences.

Raw trace amplitude may be comparable in a tightly controlled experiment after empirical validation, but parameter equality alone does not establish an absolute common biological unit. The corrected recommendation is to validate amplitude stability using controls, reference signals, or an explicit normalization strategy rather than treating identical Step 8 settings as sufficient proof.

8. Multi-penalty LASSO spatial refinement

MPS's most distinctive source-extraction stage is its local spatial update. Components are grouped into nearby clusters, local bounding regions are constructed, and only the relevant pixels and temporal regressors are considered together. This reduces a global pixels-by-components problem to a collection of smaller local regressions.

The current spatial-update utility implements a nonnegative LASSO objective of the form:

\[

\frac{1}{2T}\lVert y-Xa\rVert_2^2 + \alpha\lVert a\rVert_1,

\qquad a\ge 0.

\]

Largeralphavalues apply stronger L1 shrinkage and generally encourage fewer or smaller nonzero coefficients, all else equal.[^12]

The final footprint is not simply the solution at one chosen penalty. The code solves a range of penalties, calculates residuals, assigns inverse-residual weights, and combines the coefficient maps before thresholding and denormalization.[^12]The phrase “higher penalty creates a compact footprint” is therefore directionally reasonable for an individual LASSO solution but incomplete as a description of the final multi-penalty output.

A reproducible report should preserve:

-the full penalty range and spacing;

-trace and regressor normalization;

-pixel variability threshold;

-local cluster membership and bounding boxes;

-coefficient threshold;

-inverse-residual weighting rule;

-smoothing and overlap handling;

-exact source commit.

A compact spatial footprint is not automatically more biologically correct. It may reduce contamination, or it may exclude real fluorescent pixels. Conversely, a broad footprint may capture true signal or absorb neuropil and neighboring sources. The correct target depends on whether the analysis requires anatomical morphology, clean temporal demixing, or both.

9. Memory, parallelism, and scaling evidence

MPS combines several sound systems techniques:

-Dask workers and explicit memory limits;

-Zarr-backed intermediate storage;

-float32processing in expensive stages;

-frame chunking for projection and temporal operations;

-local spatial regions;

-checkpointable outputs;

-early cropping;

-optional NNDSVD frame subsampling.

The currentYrAsource is a good example of effective streaming: the full frame-by-pixel video is not materialized for that multiplication; the movie is read in frame chunks while the much smaller spatial matrix is held in memory.[^10][^11]

Other stages are not similarly bounded. Motion correction is documented as requiring roughly three times the video size in RAM, and NNDSVD explicitly materializes the selected frame-by-pixel array.[^1][^8]“Memory-aware, chunked, and checkpointable” is therefore more accurate than “uniformly out-of-core” or “memory-bounded at every stage.”

Published scale result

The authors processed 28 sessions totaling 77 hours and 7.26 TB in 55.6 hours, averaging about 0.72 minutes of processing per recorded minute. The reported system used an Intel Xeon w7-3455 workstation, eight Dask workers with two threads per worker, and a Dask memory cap of about 200 GB.[^13]

This is strong evidence that the complete workflow can process large, multi-hour recordings on one high-memory workstation. It does not establish the same throughput on a 16 GB, 32 GB, or ordinary laptop configuration.

The project's official hardware guidance is internally inconsistent. The installer page lists 16 GB minimum and 32 GB recommended, while the main README lists 32 GB minimum, 64 GB or more recommended, and 128 GB or more for large datasets. The pipeline's default configuration also lists a 200 GB Dask memory limit.[^1][^5]Hardware claims should therefore be expressed as tested configurations and stage-specific requirements, not one universal “standard workstation” promise.

The 10–20× claim

The manuscript says that MPS is 10–20 times faster than traditional pipelines.[^13]The public reviewers correctly questioned this general multiplier because the paper does not present a controlled benchmark in which named current alternatives process the same input on the same hardware under comparable quality and operator criteria.[^3]

The 55.6-hour absolute result is defensible. The broad 10–20× comparative claim should remain an author-reported estimate until a controlled head-to-head benchmark is available.

10. Scientific validation

MPS's strongest published evidence concerns workflow completion, runtime, memory-aware processing, stage behavior, installation intent, and component refinement. The Reviewed Preprint documents the pipeline operating across 28 long sessions and reports the effects of several processing stages.[^13]

The evidence is weaker for the central biological question: which retained components correspond to true neurons, which rejected components were true neurons, and how accurately the final temporal signals recover the underlying calcium activity.

The public reviews identified several related gaps:[^3]

-no common ground-truth source-extraction benchmark against established pipelines;

-limited direct comparison of accuracy and resource use under equivalent conditions;

-insufficient evidence for the broad speed multiplier;

-uncertainty about how well parameters generalize beyond the controlled dataset;

-concern that novice users may complete a pipeline without recognizing scientifically poor output.

The reported sessions came from a controlled acquisition domain. That is valuable for demonstrating internal consistency but does not establish generalization across brain regions, indicators, scopes, laboratories, expression levels, motion regimes, and surgical preparations.

A decisive validation should include both synthetic and experimental data. A physically motivated simulator can provide exact spatial footprints, temporal traces, motion, and detectability. Experimental data can provide realistic complexity, expert consensus, and—where possible—dual-color, electrophysiological, or other independent reference information. Neither source is sufficient alone.

11. Reproducibility, environment, and licensing

Parameter files are necessary but not sufficient

MPS saves parameters, logs, cached arrays, coordinates, and exports in several formats. These are useful reproducibility features. The README's statement that a timestamp and all processing parameters “ensure full reproducibility,” however, goes beyond what those records establish.[^1]

A complete analysis record should also preserve:

-analysis-repository commit and installer version;

-environment lockfile or hash;

-operating system;

-input file list, order, and checksums;

-video decoding and downsampling details;

-crop and mask geometry;

-removed frame indices and reasons;

-random states and sampled-frame choices;

-exact component mappings after every merge, quarantine, and reindexing step;

-accepted parameter suggestions and manual overrides;

-Data Explorer hides or exclusions;

-solver versions and tolerances;

-Dask worker and memory configuration;

-hardware and storage device;

-output checksums.

Pickle files are convenient Python objects, but they are not a durable language-neutral archival format and can be unsafe to load from untrusted sources. Zarr, NumPy, and JSON each preserve different parts of the result; none automatically guarantees a complete provenance record.

Python 3.8

The pinned environment currently uses Python 3.8.[^1]CPython 3.8 reached end of life on October 7, 2024.[^14]Pinning an older environment can help reproduce a known software stack, but it also creates maintenance pressure around operating-system compatibility, security updates, package availability, and future migration. The environment should be treated as a reproducibility snapshot that needs an explicit modernization plan.

Installation and license inconsistencies

The main analysis repository carries an Apache-2.0 license.[^15]The installer website also states Apache-2.0, but the installer repository'sLICENSEfile contains the GNU Affero General Public License text.[^5][^16]This is an official documentation inconsistency. The maintainers should identify the intended license for each repository and align the website, source files, and distribution artifacts. This review does not attempt to resolve the legal effect of the mismatch.

Current bugs and maturity signals

The current README documents a Step 4b workaround in which an option must be toggled to ensure that newly suggested watershed settings are applied. The analysis repository has also carried an issue concerning a Step 8c error.[^1][^17]Publishing workarounds and issue reports is good practice, but these details should be considered when selecting software for a large longitudinal project.

The main analysis repository currently has no formal GitHub release.[^4]Reproducible studies should therefore cite a commit rather than relying on the repository name or the1.0.0label alone.

12. Appropriate use and next benchmarks

MPS is a particularly reasonable candidate when a laboratory needs:

-multi-hour one-photon processing;

-a visible, restartable workflow;

-a GUI for stagewise parameter selection;

-Dask/Zarr-based handling of large intermediates;

-command-line helpers after the workflow is established;

-detailed inspection of candidate, temporal, and spatial stages.

It should be piloted cautiously when:

-hardware memory is limited;

-the preparation differs substantially from the authors' datasets;

-weak or atypical neurons are scientifically important;

-automated merging or filtering could alter population statistics;

-absolute trace amplitudes will be compared across sessions;

-longitudinal cell identity is required.

MPS exports can support later longitudinal analyses, but the current pipeline should not be described as providing native cross-session cell registration merely because the README lists longitudinal studies as a downstream use. Cross-session identity requires a separate registration or joint-extraction method.

The most useful next benchmark would process the same datasets with MPS, current CaImAn/CNMF-E, MiniAn, MIN1PIPE, Suite2p, and other relevant methods. It should measure:

-ROI precision, recall, and F1;

-one-to-one footprint similarity;

-false split and false merge rates;

-trace reconstruction and contamination;

-deconvolved-event recovery with matched semantics;

-motion error and downstream recovery;

-component survival at every MPS filtering stage;

-runtime, peak resident memory, temporary storage, and I/O;

-operator time and intervention count;

-parameter sensitivity;

-reproducibility across analysts and software versions.

An ablation study is equally important. It should determine what each major MPS contribution—NNDSVD, watershed initialization, temporal-first optimization, local multi-penalty LASSO, artifact quarantine, and final cleanup—adds to biological recovery, rather than only to runtime or visual appearance.

Overall conclusion

MPS is a thoughtful response to a genuine bottleneck in experimental neuroscience. Its contribution is not simply that it hides Python behind buttons. It reorganizes a one-photon source-extraction workflow around stagewise inspection, restartability, local computation, chunked storage, parameter suggestions, and a GUI that makes complicated operations available to non-programmers.

The project's best evidence is currently operational. MPS has completed 77 hours and 7.26 TB of imaging data in 55.6 hours on one high-memory workstation. Its checkpoints, parameter files, logs, Zarr outputs, command-line helpers, and visible intermediate stages are meaningful engineering strengths.

The remaining question is biological accuracy. The present paper and public repository do not yet establish how many true neurons are removed or merged during the filtering cascade, whether final temporal estimates are superior to established alternatives, or how robust the chosen parameters are across laboratories and preparations. The current code has also evolved beyond the Reviewed Preprint, making commit-level reporting essential.

The most defensible final assessment is:

>MPS is a promising, actively developed, no-code-first and automation-capable platform with strong large-data workflow evidence. Its source-extraction accuracy, filtering decisions, cross-domain generalization, and analyst-to-analyst reproducibility still require controlled ground-truth validation.

Primary sources

[^1]: MPS main repository and current pipeline guide: https://github.com/ariasarch/MPS_1.0.0/blob/main/README.md

[^2]: MPS repository tree, current source, and headless helpers: https://github.com/ariasarch/MPS_1.0.0 ; https://github.com/ariasarch/MPS_1.0.0/blob/main/run_step.py ; https://github.com/ariasarch/MPS_1.0.0/blob/main/run_multiple.py

[^3]: Peden-Asarch A, Weinstock M, Coffey KR, Neumaier JF.Miniscope Processing Suite: An Intuitive, No-Code, Scalable Pipeline for Long-Duration Calcium Imaging. eLife Reviewed Preprint v1, March 10, 2026, and public reviews: https://elifesciences.org/reviewed-preprints/109858 ; https://elifesciences.org/reviewed-preprints/109858v1/reviews

[^4]: Main analysis repository release page: https://github.com/ariasarch/MPS_1.0.0/releases

[^5]: Official installer instructions and requirements: https://ariasarch.github.io/MPS_Installer/installation.html

[^6]: Current Step 2c GUI source: https://github.com/ariasarch/MPS_1.0.0/blob/main/steps/step2c_motion_estimation.py

[^7]: Current artifact-quarantine stage: https://github.com/ariasarch/MPS_1.0.0/blob/main/steps/step4h_artifact_rejection.py

[^8]: Current NNDSVD source: https://github.com/ariasarch/MPS_1.0.0/blob/main/steps/step3b_svd.py

[^9]: MPS Reviewed Preprint figures and component-count analyses: https://elifesciences.org/reviewed-preprints/109858/figures

[^10]: Current Step 6aYrAsource: https://github.com/ariasarch/MPS_1.0.0/blob/main/steps/step6a_yra_computation.py

[^11]: Current Step 8aYrAsource: https://github.com/ariasarch/MPS_1.0.0/blob/main/steps/step8a_yra_computation.py

[^12]: Current spatial-update implementation: https://github.com/ariasarch/MPS_1.0.0/blob/main/utils/spatial_update_utils.py

[^13]: Reviewed Preprint performance report: https://elifesciences.org/reviewed-preprints/109858

[^14]: Python Developer's Guide, status of Python versions: https://devguide.python.org/versions/

[^15]: Main analysis-repository license: https://github.com/ariasarch/MPS_1.0.0/blob/main/LICENSE.txt

[^16]: Installer-repository license file: https://github.com/ariasarch/MPS_Installer/blob/main/LICENSE

[^17]: MPS Step 8c issue record: https://github.com/ariasarch/MPS_1.0.0/issues/2