cellcoloc 0.0.1__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- cellcoloc-0.0.1/CHANGELOG.md +72 -0
- cellcoloc-0.0.1/CITATION.cff +28 -0
- cellcoloc-0.0.1/CODE_OF_CONDUCT.md +92 -0
- cellcoloc-0.0.1/CONTRIBUTING.md +160 -0
- cellcoloc-0.0.1/LICENSE +674 -0
- cellcoloc-0.0.1/PKG-INFO +316 -0
- cellcoloc-0.0.1/README.md +283 -0
- cellcoloc-0.0.1/cellcoloc/__init__.py +111 -0
- cellcoloc-0.0.1/cellcoloc/analysis.py +1163 -0
- cellcoloc-0.0.1/cellcoloc/config.py +280 -0
- cellcoloc-0.0.1/cellcoloc/filtering.py +392 -0
- cellcoloc-0.0.1/cellcoloc/io.py +397 -0
- cellcoloc-0.0.1/cellcoloc/roi.py +169 -0
- cellcoloc-0.0.1/cellcoloc/runtime.py +162 -0
- cellcoloc-0.0.1/cellcoloc/schemas.py +143 -0
- cellcoloc-0.0.1/cellcoloc/segmentation.py +589 -0
- cellcoloc-0.0.1/cellcoloc/visualization.py +440 -0
- cellcoloc-0.0.1/figures/CellColoc_2.png +0 -0
- cellcoloc-0.0.1/prototype/annabell__czi.py +919 -0
- cellcoloc-0.0.1/pyproject.toml +61 -0
|
@@ -0,0 +1,72 @@
|
|
|
1
|
+
## CellColoc Changelog
|
|
2
|
+
|
|
3
|
+
This file documents notable user-facing releases of CellColoc.
|
|
4
|
+
|
|
5
|
+
Repository releases:
|
|
6
|
+
[https://github.com/FabrizioMusacchio/CellColoc/releases](https://github.com/FabrizioMusacchio/CellColoc/releases)
|
|
7
|
+
|
|
8
|
+
Zenodo archive:
|
|
9
|
+
[https://doi.org/10.5281/zenodo.18030883](https://doi.org/10.5281/zenodo.18030883)
|
|
10
|
+
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
## 🚀 CellColoc v0.0.1
|
|
14
|
+
|
|
15
|
+
June 21, 2026
|
|
16
|
+
|
|
17
|
+
First public main release of **CellColoc**.
|
|
18
|
+
|
|
19
|
+
This initial release provides:
|
|
20
|
+
|
|
21
|
+
- the reusable `cellcoloc` Python package for interactive, segmentation-based colocalization analysis in microscopy images
|
|
22
|
+
- stepwise user-script workflows for VS Code interactive window and notebook-like execution
|
|
23
|
+
- OMIO-based microscopy loading with `TZCYX` handling
|
|
24
|
+
- automatic 2D versus 3D detection from the raw z dimension
|
|
25
|
+
- voxel-size resolution from explicit user input or OMIO metadata, with fallback to `(1.0, 1.0, 1.0)` when necessary
|
|
26
|
+
- channel-wise segmentation method selection with support for:
|
|
27
|
+
- `cellpose`
|
|
28
|
+
- `otsu`
|
|
29
|
+
- `li`
|
|
30
|
+
- `percentile`
|
|
31
|
+
- optional ROI drawing in napari
|
|
32
|
+
- optional whole-image analysis as one single ROI
|
|
33
|
+
- optional reuse of previously saved ROI masks
|
|
34
|
+
- per-cell overlap analysis and marker-positivity classification
|
|
35
|
+
- standardized detailed, summary, and overview result tables
|
|
36
|
+
- standardized export into a `results/` subfolder next to the raw dataset
|
|
37
|
+
- occupancy metrics for every segmented channel
|
|
38
|
+
- optional third-channel segmentation and occupancy quantification
|
|
39
|
+
- optional third-channel cell-positivity analysis and double-positive reporting
|
|
40
|
+
- optional global z cropping for internal analysis
|
|
41
|
+
- optional global z projection using:
|
|
42
|
+
- `max`
|
|
43
|
+
- `mean`
|
|
44
|
+
- `median`
|
|
45
|
+
- `std`
|
|
46
|
+
- `var`
|
|
47
|
+
- optional anisotropy handling for true 3D Cellpose runs
|
|
48
|
+
- optional `flow3d_smooth` support for Cellpose
|
|
49
|
+
- optional image prefiltering with:
|
|
50
|
+
- `gaussian`
|
|
51
|
+
- `median`
|
|
52
|
+
- `laplacian_of_gaussian`
|
|
53
|
+
- ordered prefilter chains
|
|
54
|
+
- optional label postfiltering with:
|
|
55
|
+
- `min_intensity`
|
|
56
|
+
- `local_contrast`
|
|
57
|
+
- `bright_pixel_support`
|
|
58
|
+
- ordered postfilter chains
|
|
59
|
+
- fast Cellpose cache-based refinement using stored network outputs
|
|
60
|
+
- optional manual napari mask editing followed by table recomputation
|
|
61
|
+
- reusable visualization helpers with selective layer refreshing in napari
|
|
62
|
+
- runtime fallback handling for cache and config directories when desktop libraries cannot write to default locations
|
|
63
|
+
- packaging metadata for installation via `pip`
|
|
64
|
+
|
|
65
|
+
Packaging notes:
|
|
66
|
+
|
|
67
|
+
- PyPI package name: `cellcoloc`
|
|
68
|
+
- import name: `cellcoloc`
|
|
69
|
+
- optional interactive extra: `cellcoloc[interactive]`
|
|
70
|
+
- optional tested Cellpose 3 extra: `cellcoloc[cellpose3]`
|
|
71
|
+
|
|
72
|
+
---
|
|
@@ -0,0 +1,28 @@
|
|
|
1
|
+
cff-version: 1.2.0
|
|
2
|
+
message: "If you use CellColoc in your research, please cite it using the metadata below."
|
|
3
|
+
title: "CellColoc: A Python package for interactive segmentation-based colocalization analysis in microscopy images"
|
|
4
|
+
version: 0.0.1
|
|
5
|
+
date-released: 2026-06-21
|
|
6
|
+
|
|
7
|
+
authors:
|
|
8
|
+
- family-names: Musacchio
|
|
9
|
+
given-names: Fabrizio
|
|
10
|
+
orcid: https://orcid.org/0000-0002-9043-3349
|
|
11
|
+
|
|
12
|
+
repository-code: https://github.com/FabrizioMusacchio/CellColoc
|
|
13
|
+
doi: 10.5281/zenodo.18030883
|
|
14
|
+
license: GPL-3.0-or-later
|
|
15
|
+
|
|
16
|
+
keywords:
|
|
17
|
+
- microscopy
|
|
18
|
+
- bioimaging
|
|
19
|
+
- colocalization
|
|
20
|
+
- segmentation
|
|
21
|
+
- cellpose
|
|
22
|
+
- napari
|
|
23
|
+
- OMIO
|
|
24
|
+
- OME
|
|
25
|
+
- CZI
|
|
26
|
+
- OME-TIFF
|
|
27
|
+
- Python
|
|
28
|
+
- scientific software
|
|
@@ -0,0 +1,92 @@
|
|
|
1
|
+
|
|
2
|
+
# Contributor Covenant 3.0 Code of Conduct
|
|
3
|
+
|
|
4
|
+
## Our Pledge
|
|
5
|
+
|
|
6
|
+
We pledge to make our community welcoming, safe, and equitable for all.
|
|
7
|
+
|
|
8
|
+
We are committed to fostering an environment that respects and promotes the dignity, rights, and contributions of all individuals, regardless of characteristics including race, ethnicity, caste, color, age, physical characteristics, neurodiversity, disability, sex or gender, gender identity or expression, sexual orientation, language, philosophy or religion, national or social origin, socio-economic position, level of education, or other status. The same privileges of participation are extended to everyone who participates in good faith and in accordance with this Covenant.
|
|
9
|
+
|
|
10
|
+
## Encouraged Behaviors
|
|
11
|
+
|
|
12
|
+
While acknowledging differences in social norms, we all strive to meet our community's expectations for positive behavior. We also understand that our words and actions may be interpreted differently than we intend based on culture, background, or native language.
|
|
13
|
+
|
|
14
|
+
With these considerations in mind, we agree to behave mindfully toward each other and act in ways that center our shared values, including:
|
|
15
|
+
|
|
16
|
+
1. Respecting the **purpose of our community**, our activities, and our ways of gathering.
|
|
17
|
+
2. Engaging **kindly and honestly** with others.
|
|
18
|
+
3. Respecting **different viewpoints** and experiences.
|
|
19
|
+
4. **Taking responsibility** for our actions and contributions.
|
|
20
|
+
5. Gracefully giving and accepting **constructive feedback**.
|
|
21
|
+
6. Committing to **repairing harm** when it occurs.
|
|
22
|
+
7. Behaving in other ways that promote and sustain the **well-being of our community**.
|
|
23
|
+
|
|
24
|
+
|
|
25
|
+
## Restricted Behaviors
|
|
26
|
+
|
|
27
|
+
We agree to restrict the following behaviors in our community. Instances, threats, and promotion of these behaviors are violations of this Code of Conduct.
|
|
28
|
+
|
|
29
|
+
1. **Harassment.** Violating explicitly expressed boundaries or engaging in unnecessary personal attention after any clear request to stop.
|
|
30
|
+
2. **Character attacks.** Making insulting, demeaning, or pejorative comments directed at a community member or group of people.
|
|
31
|
+
3. **Stereotyping or discrimination.** Characterizing anyone’s personality or behavior on the basis of immutable identities or traits.
|
|
32
|
+
4. **Sexualization.** Behaving in a way that would generally be considered inappropriately intimate in the context or purpose of the community.
|
|
33
|
+
5. **Violating confidentiality**. Sharing or acting on someone's personal or private information without their permission.
|
|
34
|
+
6. **Endangerment.** Causing, encouraging, or threatening violence or other harm toward any person or group.
|
|
35
|
+
7. Behaving in other ways that **threaten the well-being** of our community.
|
|
36
|
+
|
|
37
|
+
### Other Restrictions
|
|
38
|
+
|
|
39
|
+
1. **Misleading identity.** Impersonating someone else for any reason, or pretending to be someone else to evade enforcement actions.
|
|
40
|
+
2. **Failing to credit sources.** Not properly crediting the sources of content you contribute.
|
|
41
|
+
3. **Promotional materials**. Sharing marketing or other commercial content in a way that is outside the norms of the community.
|
|
42
|
+
4. **Irresponsible communication.** Failing to responsibly present content which includes, links or describes any other restricted behaviors.
|
|
43
|
+
|
|
44
|
+
|
|
45
|
+
## Reporting an Issue
|
|
46
|
+
|
|
47
|
+
Tensions can occur between community members even when they are trying their best to collaborate. Not every conflict represents a code of conduct violation, and this Code of Conduct reinforces encouraged behaviors and norms that can help avoid conflicts and minimize harm.
|
|
48
|
+
|
|
49
|
+
When an incident does occur, it is important to report it promptly. To report a possible violation, **please report it by email to Fabrizio Musacchio at fabrizio.musacchio@dzne.de. All reports will be handled confidentially.**
|
|
50
|
+
|
|
51
|
+
Community Moderators take reports of violations seriously and will make every effort to respond in a timely manner. They will investigate all reports of code of conduct violations, reviewing messages, logs, and recordings, or interviewing witnesses and other participants. Community Moderators will keep investigation and enforcement actions as transparent as possible while prioritizing safety and confidentiality. In order to honor these values, enforcement actions are carried out in private with the involved parties, but communicating to the whole community may be part of a mutually agreed upon resolution.
|
|
52
|
+
|
|
53
|
+
|
|
54
|
+
## Addressing and Repairing Harm
|
|
55
|
+
|
|
56
|
+
****
|
|
57
|
+
|
|
58
|
+
If an investigation by the Community Moderators finds that this Code of Conduct has been violated, the following enforcement ladder may be used to determine how best to repair harm, based on the incident's impact on the individuals involved and the community as a whole. Depending on the severity of a violation, lower rungs on the ladder may be skipped.
|
|
59
|
+
|
|
60
|
+
1) Warning
|
|
61
|
+
1) Event: A violation involving a single incident or series of incidents.
|
|
62
|
+
2) Consequence: A private, written warning from the Community Moderators.
|
|
63
|
+
3) Repair: Examples of repair include a private written apology, acknowledgement of responsibility, and seeking clarification on expectations.
|
|
64
|
+
2) Temporarily Limited Activities
|
|
65
|
+
1) Event: A repeated incidence of a violation that previously resulted in a warning, or the first incidence of a more serious violation.
|
|
66
|
+
2) Consequence: A private, written warning with a time-limited cooldown period designed to underscore the seriousness of the situation and give the community members involved time to process the incident. The cooldown period may be limited to particular communication channels or interactions with particular community members.
|
|
67
|
+
3) Repair: Examples of repair may include making an apology, using the cooldown period to reflect on actions and impact, and being thoughtful about re-entering community spaces after the period is over.
|
|
68
|
+
3) Temporary Suspension
|
|
69
|
+
1) Event: A pattern of repeated violation which the Community Moderators have tried to address with warnings, or a single serious violation.
|
|
70
|
+
2) Consequence: A private written warning with conditions for return from suspension. In general, temporary suspensions give the person being suspended time to reflect upon their behavior and possible corrective actions.
|
|
71
|
+
3) Repair: Examples of repair include respecting the spirit of the suspension, meeting the specified conditions for return, and being thoughtful about how to reintegrate with the community when the suspension is lifted.
|
|
72
|
+
4) Permanent Ban
|
|
73
|
+
1) Event: A pattern of repeated code of conduct violations that other steps on the ladder have failed to resolve, or a violation so serious that the Community Moderators determine there is no way to keep the community safe with this person as a member.
|
|
74
|
+
2) Consequence: Access to all community spaces, tools, and communication channels is removed. In general, permanent bans should be rarely used, should have strong reasoning behind them, and should only be resorted to if working through other remedies has failed to change the behavior.
|
|
75
|
+
3) Repair: There is no possible repair in cases of this severity.
|
|
76
|
+
|
|
77
|
+
This enforcement ladder is intended as a guideline. It does not limit the ability of Community Managers to use their discretion and judgment, in keeping with the best interests of our community.
|
|
78
|
+
|
|
79
|
+
|
|
80
|
+
## Scope
|
|
81
|
+
|
|
82
|
+
This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public or other spaces. Examples of representing our community include using an official email address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
|
|
83
|
+
|
|
84
|
+
|
|
85
|
+
## Attribution
|
|
86
|
+
|
|
87
|
+
This Code of Conduct is adapted from the Contributor Covenant, version 3.0, permanently available at [https://www.contributor-covenant.org/version/3/0/](https://www.contributor-covenant.org/version/3/0/).
|
|
88
|
+
|
|
89
|
+
Contributor Covenant is stewarded by the Organization for Ethical Source and licensed under CC BY-SA 4.0. To view a copy of this license, visit [https://creativecommons.org/licenses/by-sa/4.0/](https://creativecommons.org/licenses/by-sa/4.0/)
|
|
90
|
+
|
|
91
|
+
For answers to common questions about Contributor Covenant, see the FAQ at [https://www.contributor-covenant.org/faq](https://www.contributor-covenant.org/faq). Translations are provided at [https://www.contributor-covenant.org/translations](https://www.contributor-covenant.org/translations). Additional enforcement and community guideline resources can be found at [https://www.contributor-covenant.org/resources](https://www.contributor-covenant.org/resources). The enforcement ladder was inspired by the work of [Mozilla’s code of conduct team](https://github.com/mozilla/inclusion).
|
|
92
|
+
|
|
@@ -0,0 +1,160 @@
|
|
|
1
|
+
# How to Contribute
|
|
2
|
+
|
|
3
|
+
Thank you for your interest in contributing to OMIO. This project welcomes improvements to the code, documentation, tests, and overall usability. The goal of OMIO is to provide a robust, transparent, and reproducible interface for reading, standardizing, and converting microscopy image data, with a strong focus on OME-compatible metadata handling and downstream interoperability.
|
|
4
|
+
|
|
5
|
+
## Before you start
|
|
6
|
+
Please check the GitHub issue tracker to see whether your idea, bug report, or enhancement has already been discussed:
|
|
7
|
+
|
|
8
|
+
[https://github.com/FabrizioMusacchio/omio/issues](https://github.com/FabrizioMusacchio/omio/issues)
|
|
9
|
+
|
|
10
|
+
* If a related issue exists, comment there to indicate your interest or to add relevant technical details.
|
|
11
|
+
* If no issue exists, open a new one with a short description of:
|
|
12
|
+
* what you would like to change or add
|
|
13
|
+
* why it is useful in the context of OMIO
|
|
14
|
+
* any thoughts on implementation, edge cases, or testing
|
|
15
|
+
|
|
16
|
+
For small fixes such as typos or minor documentation improvements, opening a pull request directly is fine.
|
|
17
|
+
|
|
18
|
+
## Development environment
|
|
19
|
+
OMIO requires **Python 3.12 or newer** and builds on standard scientific Python packages commonly used in microscopy workflows, including NumPy, tifffile, zarr, and related libraries for metadata handling.
|
|
20
|
+
|
|
21
|
+
A typical development setup using `conda` looks like this:
|
|
22
|
+
|
|
23
|
+
```sh
|
|
24
|
+
git clone https://github.com/FabrizioMusacchio/omio.git
|
|
25
|
+
cd omio
|
|
26
|
+
|
|
27
|
+
conda create -n omio-dev -c conda-forge python=3.12
|
|
28
|
+
conda activate omio-dev
|
|
29
|
+
|
|
30
|
+
pip install -e .
|
|
31
|
+
````
|
|
32
|
+
|
|
33
|
+
To install optional development dependencies such as testing and linting tools:
|
|
34
|
+
|
|
35
|
+
```sh
|
|
36
|
+
pip install -e ".[dev]"
|
|
37
|
+
```
|
|
38
|
+
|
|
39
|
+
## Making changes and opening pull requests
|
|
40
|
+
All code contributions should be submitted as pull requests (PRs) against the `main` branch of the repository.
|
|
41
|
+
|
|
42
|
+
A recommended workflow:
|
|
43
|
+
|
|
44
|
+
1. Create a new feature branch:
|
|
45
|
+
|
|
46
|
+
```sh
|
|
47
|
+
git checkout -b feature/my-feature
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
2. Implement your changes. New functions or modules should include clear docstrings explaining:
|
|
51
|
+
* their purpose
|
|
52
|
+
* expected inputs and outputs
|
|
53
|
+
* any assumptions or limitations
|
|
54
|
+
3. Add tests for new functionality or bug fixes where appropriate.
|
|
55
|
+
4. Push your branch and open a pull request that includes:
|
|
56
|
+
* a concise and descriptive title
|
|
57
|
+
* a brief explanation of what was changed and why
|
|
58
|
+
* references to related issues (for example “Closes #12”)
|
|
59
|
+
|
|
60
|
+
Draft pull requests are welcome if you would like feedback during development.
|
|
61
|
+
|
|
62
|
+
## Commit conventions
|
|
63
|
+
Clear and consistent commit messages help keep the project history readable. Prefixes inspired by Conventional Commits are encouraged:
|
|
64
|
+
|
|
65
|
+
* `feat:` new functionality
|
|
66
|
+
* `fix:` bug fixes
|
|
67
|
+
* `docs:` documentation changes
|
|
68
|
+
* `refactor:` internal code restructuring without behavior changes
|
|
69
|
+
* `test:` adding or modifying tests
|
|
70
|
+
* `chore:` maintenance tasks or tooling updates
|
|
71
|
+
|
|
72
|
+
Example:
|
|
73
|
+
`fix: handle paginated TIFF files with mixed photometric interpretations`
|
|
74
|
+
|
|
75
|
+
## Testing
|
|
76
|
+
OMIO uses `pytest` for automated testing. To run the full test suite locally:
|
|
77
|
+
|
|
78
|
+
```sh
|
|
79
|
+
pytest
|
|
80
|
+
```
|
|
81
|
+
|
|
82
|
+
If you add new features or fix bugs, please extend the test suite accordingly.
|
|
83
|
+
|
|
84
|
+
Tests should remain small and self-contained. Large microscopy datasets should not be added to the repository. Whenever possible, use synthetic arrays or minimal example files generated during the test run.
|
|
85
|
+
|
|
86
|
+
|
|
87
|
+
## Notes for JOSS-related contributions *(new)*
|
|
88
|
+
OMIO is developed with the requirements of the *Journal of Open Source Software (JOSS)* in mind. Contributions should therefore respect the following principles, which are routinely evaluated during JOSS review:
|
|
89
|
+
|
|
90
|
+
* **Reproducibility**
|
|
91
|
+
Behavior should be deterministic given identical inputs and parameters. Any non-deterministic behavior must be explicitly documented.
|
|
92
|
+
* **Test coverage**
|
|
93
|
+
New functionality should be accompanied by tests that fail without the change and pass with it. Tests should target observable behavior rather than internal implementation details.
|
|
94
|
+
* **Documentation consistency**
|
|
95
|
+
Public-facing functions must be documented in a way that is consistent with their actual behavior. Silent assumptions or undocumented side effects are discouraged.
|
|
96
|
+
* **Minimal scope changes**
|
|
97
|
+
Pull requests should focus on a well-defined change. Large refactors or conceptual redesigns should be discussed in an issue before implementation.
|
|
98
|
+
* **Explicit limitations**
|
|
99
|
+
Known limitations or unsupported cases should be documented rather than implicitly ignored.
|
|
100
|
+
|
|
101
|
+
Following these guidelines helps ensure that OMIO remains reviewable, maintainable, and suitable for long-term archival publication.
|
|
102
|
+
|
|
103
|
+
|
|
104
|
+
## OME policy decisions and design constraints
|
|
105
|
+
OMIO makes a number of explicit policy decisions when reading and converting microscopy data to OME-compatible representations. These decisions are intentional and are meant to favor robustness and downstream interoperability over implicit heuristics.
|
|
106
|
+
|
|
107
|
+
Key principles include:
|
|
108
|
+
|
|
109
|
+
* **Canonical axis normalization**
|
|
110
|
+
OMIO internally normalizes image data to the canonical OME axis order `TZCYX`. Missing axes may be inserted with length 1, but ambiguous or non-OME axis labels are not silently reinterpreted.
|
|
111
|
+
* **Single-series default behavior**
|
|
112
|
+
For multi-series TIFF files, OMIO currently processes only the first series by default. This behavior is recorded in the output metadata and is considered a policy decision rather than a technical limitation.
|
|
113
|
+
* **Metadata preservation over inference**
|
|
114
|
+
Existing OME-XML and ImageJ metadata are preserved wherever possible. OMIO avoids inventing or guessing metadata fields that are not present in the source file.
|
|
115
|
+
* **Explicit handling of unsupported metadata**
|
|
116
|
+
Metadata fields that are detected but not yet supported are reported explicitly rather than silently ignored. This is intended to make limitations visible and reproducible.
|
|
117
|
+
|
|
118
|
+
Contributions that alter or extend these policy decisions should be discussed in an issue before implementation, as such changes may affect reproducibility, compatibility with downstream tools, or consistency with existing datasets.
|
|
119
|
+
|
|
120
|
+
|
|
121
|
+
## Reporting bugs
|
|
122
|
+
Please report bugs via the GitHub issue tracker:
|
|
123
|
+
|
|
124
|
+
[https://github.com/FabrizioMusacchio/omio/issues](https://github.com/FabrizioMusacchio/omio/issues)
|
|
125
|
+
|
|
126
|
+
Include the following information if possible:
|
|
127
|
+
|
|
128
|
+
* OMIO version (`pip show omio`)
|
|
129
|
+
* Python version
|
|
130
|
+
* Operating system
|
|
131
|
+
* Minimal steps or code snippet to reproduce the issue
|
|
132
|
+
* If applicable, a small synthetic or cropped example file illustrating the problem
|
|
133
|
+
|
|
134
|
+
## Requests for new file formats and reader extensions
|
|
135
|
+
In addition to direct code contributions via pull requests, users are encouraged to request support for additional microscopy file formats or format variants that are not yet covered by OMIO.
|
|
136
|
+
|
|
137
|
+
Such requests should be submitted via the GitHub issue tracker and include:
|
|
138
|
+
|
|
139
|
+
* a clear description of the file format or variant in question
|
|
140
|
+
* how the file differs from formats already supported by OMIO
|
|
141
|
+
* which part of the reader pipeline fails or behaves unexpectedly
|
|
142
|
+
* if available, relevant OMIO output such as warnings, parsed metadata, or axis interpretations
|
|
143
|
+
|
|
144
|
+
Support for new formats or variants can only be added if a **representative example file** is made available. This is essential to ensure correct parsing, reproducibility, and long-term test coverage.
|
|
145
|
+
|
|
146
|
+
Example files can be shared via:
|
|
147
|
+
* temporary download links (for example institutional web shares or cloud storage)
|
|
148
|
+
* publicly accessible repositories or archives
|
|
149
|
+
* other means that allow the developers to locally inspect and test the data
|
|
150
|
+
|
|
151
|
+
Without access to an example file, reader extensions are generally not feasible, as OMIO deliberately avoids speculative or heuristic-based format inference.
|
|
152
|
+
|
|
153
|
+
If sharing full datasets is not possible, users are encouraged to provide the smallest possible cropped or anonymized file that still reproduces the issue.
|
|
154
|
+
|
|
155
|
+
|
|
156
|
+
## License and contributions
|
|
157
|
+
By submitting a pull request, you agree that your contributions will be released under the project’s license as specified in the repository.
|
|
158
|
+
|
|
159
|
+
If you are unsure how to begin or would like to discuss a potential contribution, feel free to open an issue to start a conversation.
|
|
160
|
+
|