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.
@@ -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
+