Ticket #542 (closed task: fixed)

Opened 8 years ago

Last modified 8 years ago

Change legacy layer so that it maintains Display<-->ImagePlus mappings

Reported by: bdezonia Owned by: curtis
Priority: blocker Milestone: biweekly-2011: Jul-05 to Jul-15
Component: Legacy Compatibility Version:
Severity: serious Keywords:
Cc: Blocked By:


Unlike IJ1, IJ2 allows one to view the same set of data in two different views, each with its own Overlays. In order to translate these multiple views to something IJ1 can handle as an input we should create an ImagePlus for each Display.

Each display's Overlay would be the Roi of an ImagePlus. So four displayed views of one dataset each with its own Overlay would map to four ImagePluses each with a different Roi. However with PlanarAccess Datasets the resource usage can be minimized as only plane references are stored. (What would happen here with a big CellImg? Or any type not ubyte, ushort, float?)

We would also like to keep track of Datasets not associated with Displays so that they too can have Legacy plugins run on them. So we might need two mapping structures (from Dataset to ImagePlus and from Display to ImagePlus).

One issue here is what happens when you have a Display that has two views of the same Dataset. Do we hatch multiple ImagePluses? Or treat one as the Dataset and the other(s) as Overlays?

For information on IJ2's current workaround see svn revision d1b8f41fba2b8e73256e4302d7e554f35201529d commit message.

Change History

comment:1 Changed 8 years ago by bdezonia

If we have the situation where we have a multiply viewed Dataset, each view with its own Overlay, why we couldn't enforce the rule that only the active display and dataset get sent to IJ1 together. Thus avoiding multiple ImagePluses per display.

comment:2 Changed 8 years ago by curtis

  • Milestone changed from imagej-2.0-beta1 to biweekly-2011: Jun-06 to Jun-17

comment:3 Changed 8 years ago by curtis

  • Priority changed from major to critical

comment:4 Changed 8 years ago by curtis

  • Priority changed from critical to blocker
  • Milestone changed from biweekly-2011: Jun-06 to Jun-17 to biweekly-2011: Jun-20 to Jul-01

This task has become increasingly necessary before any further work can proceed on the legacy layer. And we really need it before the 2.0.0-beta1 release.

comment:5 Changed 8 years ago by curtis

  • Status changed from new to closed
  • Resolution set to fixed

As of c7b81e58a8e78876b441790adc34ba3634da383c, the legacy layer is ostensibly working again, with the new mapping to Displays instead of Datasets. The LegacyUtils class and some related functionality still needs to be updated to remove some of the hacks—currently, some methods take a Dataset and then look up the first Display corresponding to that Dataset, which we no longer need to do (and in fact won't work once the UI supports multiple views of the same Dataset).

Note: See TracTickets for help on using tickets.