Ticket #1014 (closed feature: wontfix)
Opened 2012-02-24T14:16:30-06:00
Last modified 2012-02-24T16:04:46-06:00
Support for ImgLib-backed data in ImageJ1
| Reported by: | curtis | Owned by: | bdezonia |
|---|---|---|---|
| Priority: | blocker | Milestone: | imagej-2.0.0 |
| Component: | Core | Version: | |
| Severity: | serious | Keywords: | |
| Cc: | Blocked By: | #145, #146, #192, #193, #194, #196, #197, #203, #204, #206, #209, #212, #218, #222, #228, #229, #232, #233, #234, #235, #242, #255, #256, #258, #259, #266, #267, #268, #270, #274, #276, #283, #284, #295, #297, #303, #305, #306, #311, #313 | |
| Blocking: | #1010 |
Description (last modified by curtis)
One initial approach we took when developing ImageJ2 was a new ij.process.ImageProcessor implementation called ImgLibProcessor, that provided ImgLib-backed image data. We also experimented with the idea of overriding the ImageStack. In this way, we could add support for new pixel types to ImageJ1 without breaking existing code.
In order for ImgLibProcessor to work, we needed quite a few minor changes to ImageJ1 codebase to rework the assumption that no other ImageProcessor subclasses (besides Byte, Short, Float and Color) could exist. We maintained these changes in an area called ij1-patches, and worked with Wayne Rasband to get them brought into the official IJ1 distribution.
Ultimately, however, Wayne deemed that this approach represented too much change to the ImageJ1 codebase, and we were forced to find an alternative approach (see ticket #1011 for details).
This ticket exists only to document the history of that work.
Change History
comment:1 Changed 2012-02-24T14:16:52-06:00 by curtis
- Status changed from new to closed
- Resolution set to wontfix
As noted above, we abandoned this approach in favor of the legacy layer (ticket #1011).