NOTICE! This is a static HTML version of a legacy ImageJ Trac ticket.

The ImageJ project now uses GitHub Issues for issue tracking.

Please file all new issues there.

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: imagej-2.0-alpha1
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).