Ticket #16 (closed task: wontfix)
Opened 2010-02-16T21:57:58-06:00
Last modified 2011-02-23T14:22:05-06:00
Adapt ImageProcessor subclasses to use imglib
| Reported by: | curtis | Owned by: | aivar |
|---|---|---|---|
| Priority: | blocker | Milestone: |
|
| Component: | Legacy Compatibility | Version: | |
| Severity: | non-issue | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: |
Description
As part of our goal to maintain backwards compatibility with the current version of ImageJ, we plan to keep the existing ImageJ API intact (ij.*) but begin delegating logic to a new API (imagej.*). The first step in such delegation is to link up the current ImageJ data model, the ij.process.ImageProcessor and subclasses thereof, with the proposed future ImageJ data model, the imglib library. This will serve as a proof of concept, demonstrating that imglib is as functional as the existing implementation. It will also provide several advantages:
- Access to new data types available within imglib (long, complex float, etc.).
- More easily work with data from sources other than disk.
- Implement each analysis algorithm once, rather than per data type.
One likely disadvantage is speed, though we plan to explore various ways to boost performance as well.
Change History
comment:1 Changed 2011-02-23T14:22:05-06:00 by curtis
- Status changed from new to closed
- Resolution set to wontfix
After a discussion with Wayne Rasband, we have decided not to expose ImgLib/ImageJ2 data types in ImageJ1 with a new ImageProcessor extension, because it is too disruptive to the ImageJ1 codebase.
Instead, we will focus on execution of ImageJ1 plugins only on ImgLib/ImageJ2 data that is compatible with the existing ImageProcessor types (uint8, uint16 and float).