add new roadmap#31
Conversation
| ## v0.0.3 Backlog (Planned) | ||
|
|
||
| - [ ] Potential Arrow Flight handoff experiments. | ||
| - [ ] Cytomining V2 support. |
There was a problem hiding this comment.
| - [ ] Cytomining V2 support. | |
| - [ ] ome-arrow and iceberg-bioimage support. |
There was a problem hiding this comment.
we've moving away from calling it cytomining v2 (we still use as shorthand)
| - [ ] Support multi-channel image loading (lazily). | ||
| - [ ] Support loading of shapes, vectors, outlines, and contours. | ||
| - [ ] Integration with cloud storage solutions (e.g., AWS S3, Google Cloud Storage). | ||
| - [ ] Support with DeepProfiler image handoff (thin arrow flight, but simplified for the use case of image handoff). |
There was a problem hiding this comment.
We could define what this looks like as we go possibly.
| - [ ] Support with DeepProfiler image handoff (thin arrow flight, but simplified for the use case of image handoff). | |
| - [ ] Support DeepProfiler integration. |
|
|
||
| - [ ] Potential Arrow Flight handoff experiments. | ||
| - [ ] Cytomining V2 support. | ||
| - [ ] Support for additional image formats (e.g., TIFF, JPEG, OME-arrow). |
There was a problem hiding this comment.
| - [ ] Support for additional image formats (e.g., TIFF, JPEG, OME-arrow). |
Probably not? We'd likely have some preprocessing stage that will be broadly useful (not just inside zp)
There was a problem hiding this comment.
We could use OME-Arrow as a conversion point here during implementation. E.g. [tiff|zarr] --> ome-arrow --> numpy . Agree that it might not need explicit mention for now. I'm contradicting myself here a bit from the earlier comment outside of this thread(!), but in this case we sidestep choice by excluding the line item rather than saying we'll decide as a step.
| ## v0.0.2 Backlog (Planned) | ||
|
|
||
| - [ ] Nucleocentric featurization. | ||
| - [ ] Pick between pandas and polars for dataframe handling. |
There was a problem hiding this comment.
I'd encourage a choice within the roadmap here and now; a roadmap I feel should be decisive and somewhat firm, providing a "road" we can walk, run, or ride on to move the project forward. A decision point is instead like squishy peat that could trip us up. For this particular decision, other points in the roadmap likely become more clear, meaning we're overall less squishy and more firm, without being tightly coupled to anything in particular (because it's all just still a roadmap and not real code).
My personal vote is Polars for stronger data processing capabilities and strict data typing. You could go Narwhals if you wanted to abstract from any particular library, but abstraction comes with it's own costs that could complicate things - e.g. data types, missing methods, etc.
|
|
||
| - [ ] Potential Arrow Flight handoff experiments. | ||
| - [ ] Cytomining V2 support. | ||
| - [ ] Support for additional image formats (e.g., TIFF, JPEG, OME-arrow). |
There was a problem hiding this comment.
We could use OME-Arrow as a conversion point here during implementation. E.g. [tiff|zarr] --> ome-arrow --> numpy . Agree that it might not need explicit mention for now. I'm contradicting myself here a bit from the earlier comment outside of this thread(!), but in this case we sidestep choice by excluding the line item rather than saying we'll decide as a step.
| - [ ] Support multi-channel image loading (lazily). | ||
| - [ ] Support loading of shapes, vectors, outlines, and contours. | ||
| - [ ] Integration with cloud storage solutions (e.g., AWS S3, Google Cloud Storage). | ||
| - [ ] Support with DeepProfiler image handoff (thin arrow flight, but simplified for the use case of image handoff). |
There was a problem hiding this comment.
We could define what this looks like as we go possibly.
| - [ ] Support with DeepProfiler image handoff (thin arrow flight, but simplified for the use case of image handoff). | |
| - [ ] Support DeepProfiler integration. |
| - [ ] Support for additional image formats (e.g., TIFF, JPEG, OME-arrow). | ||
| - [ ] Support multi-channel image loading (lazily). | ||
| - [ ] Support loading of shapes, vectors, outlines, and contours. | ||
| - [ ] Integration with cloud storage solutions (e.g., AWS S3, Google Cloud Storage). |
There was a problem hiding this comment.
| - [ ] Integration with cloud storage solutions (e.g., AWS S3, Google Cloud Storage). | |
| - [ ] Integration with object storage solutions (e.g., AWS S3, Google Cloud Storage). |
| - [ ] Integration with cloud storage solutions (e.g., AWS S3, Google Cloud Storage). | ||
| - [ ] Support with DeepProfiler image handoff (thin arrow flight, but simplified for the use case of image handoff). | ||
| - [ ] Support for additional feature extraction methods (e.g., mesh, graph-based features, point-clouds, polygons). | ||
| - [ ] Feature-extraction time estimation and optimization. |
There was a problem hiding this comment.
Would this mean user-facing time estimations like progress bars? Perhaps optimization comes in a different checkbox, such as benchmarking / optimization (where we bench time).
| - [ ] Potential Arrow Flight handoff experiments. | ||
| - [ ] Cytomining V2 support. | ||
| - [ ] Support for additional image formats (e.g., TIFF, JPEG, OME-arrow). | ||
| - [ ] Support multi-channel image loading (lazily). |
There was a problem hiding this comment.
Loading and processing could be lazy - maybe processing needs a lazy step here too?
3 participants
Description
This PR updates the roadmap document. Please feel free to suggest anything that I might have missed.
What kind of change(s) are included?
Checklist
Please ensure that all boxes are checked before indicating that this pull request is ready for review.