⚠

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 #660 (closed defect: moved)

Opened 2011-07-05T09:50:15-05:00

Last modified 2013-06-05T15:19:50-05:00

Improve Display-DisplayView-DataObject hierarchy

Reported by: curtis Owned by: curtis
Priority: critical Milestone: imagej2-b8-analysis
Component: Display API Version:
Severity: critical Keywords:
Cc: Blocked By: #995
Blocking: #579

Description

Currently, a Display consists of a list of DisplayViews, each of which links to a DataObject. After talking with a few people about use cases, it seems that this approach is too simplistic.

For example, if you have a Dataset with a collection of Overlays intended to correspond to that Dataset, it would be nice for the data structures to indicate that they are specifically linked somehow, rather than just implicitly so by being in the same display.

A tree-like hierarchy of data objects would provide more explicit linkage between related objects, as well as easy duplication of the same structures across multiple displays. (TrakEM2 and Endrov both support tree-like hierarchies of data objects.)

Another problem is that we currently have no UI-agnostic mechanism to create DisplayView instances from a given Dataset or Overlay. Many plugins need to return a DatasetView or an OverlayView, but must avoid invoking e.g. "new SwingDatasetView" in code.

Further, for plugins that wish to return more complex data structures (e.g., a Dataset together with some Overlays), it would be nice to have the aforementioned tree structure, so that it can be used by those plugins.

To address these issues, I propose the following changes:

  1. Create a third type of DisplayView called a CompositeView that consists of a list of other DisplayViews.
  2. Provide a helper/factory that can generically create DatasetViews and OverlayViews.
  3. Potentially, for simplicity, change Display to take a single CompositeView.

Change History

comment:1 Changed 2011-07-05T13:04:09-05:00 by leek

It seems to me that there are several problems:

  • It would be nice to be able to group overlays and datasets hierarchically. For overlays, I was hoping that there would be some sort of directory structure. I could then put all overlays from a segmentation (the segmented cells / particles) in the same folder. It would be nice if you could get the segmentation itself from the folder (or see provenance below).
  • It would be nice to have some provenance for a data object - I think that's what you want to model when you link. Overlays could be traced back to the associated dataset by the provenance. I think you want the provenance annotation to model the process that created the data object and I'm not sure how complicated to make this. I like how the annotations are done in JHotDraw where the property names specify the type of object returned. Then, when querying an object's provenance, you'd ask for the "FROM_DATASET" part of the provenance for an overlay and get back a dataset. When you asked for the "FROM_LABELING" part of the provenance, you'd get back a labeling, ask for "FROM_PLUGIN" and you'd get the plugin that generated the image (maybe the exact instance so you'd be able to see the parameters used?) and so forth.
  • There is a conflation of display and dataset in the current model. I think you should be able to composite multiple datasets within a display in the same way you can composite multiple overlays by adding multiple DisplayViews to a display. Datasets could have a DatasetManager so plugins could create datasets that weren't attached to displays.
  • My gut feeling is that we should have data object composites and not DisplayView composites. I already have a composite for overlays; potentially, you could have a composite figure that would let you edit the composite overlay. The composite dataset should behave like an image derived from a bunch of aligned sub-images. This would let the same code use composite or simple overlays and datasets without knowing the difference - if it's at the View level, the code has to special-case to operate on each of the composite members. We could add a method on the Display to fetch the composite overlay and composite image for the display for convenience - both of these should be backed by the set of overlays or datasets and should not be copies. It should not be hard to write a Image class for imglib that is a composite of other images (with offsets or transforms for alignment).
  • The factory pattern is absolutely the way to go. We have Display.display(Overlay x) and Display.display(Dataset x), so I'd say we only need to have the factory create displays. I'd add a method to the DisplayManager to do this.

comment:2 Changed 2011-07-27T10:11:54-05:00 by curtis

  • Owner changed from gharris to curtis
  • Status changed from new to assigned
  • Milestone changed from biweekly-2011: Jul-18 to Jul-29 to biweekly-2011: Aug-01 to Aug-12

comment:3 Changed 2011-08-01T12:10:32-05:00 by curtis

  • Milestone changed from biweekly-2011: Aug-01 to Aug-12 to imagej-2.0-alpha5

Milestone biweekly-2011: Aug-01 to Aug-12 deleted

comment:4 Changed 2011-09-29T16:15:26-05:00 by curtis

I posted a  blog entry detailing the latest work and plans on this front. Lee, I think the current refactoring plans cover everything you mention above except for the provenance issue, which could be added later without too much disruption, I think.

comment:5 Changed 2011-11-01T10:31:16-05:00 by curtis

  • Status changed from assigned to accepted

comment:6 Changed 2012-02-22T14:07:58-06:00 by curtis

  • Blocked By 995 added

comment:6 Changed 2012-02-26T22:57:09-06:00 by curtis

  • Blocking 10 added

comment:7 Changed 2012-02-26T22:58:13-06:00 by curtis

  • Blocking 579 added; 10 removed

comment:8 Changed 2012-03-02T13:13:27-06:00 by curtis

  • Milestone changed from imagej-2.0-beta1 to imagej-2.0-beta2

comment:9 Changed 2012-06-16T23:27:42-05:00 by curtis

  • Milestone changed from imagej-2.0.0-beta3 to imagej-2.0.0-beta4

comment:10 Changed 2012-08-14T09:52:06-05:00 by curtis

  • Milestone changed from imagej-2.0.0-beta4 to imagej-2.0.0-beta5

The theme of beta5 will be more flexible data visualization and processing.

comment:11 Changed 2013-06-05T15:19:50-05:00 by bdezonia

  • Milestone changed from imagej2-b7-ndim-data to imagej2-b8-analysis

comment:10 Changed 2014-05-25T21:38:17-05:00 by curtis

  • Status changed from accepted to closed
  • Resolution set to moved

Migrated to  https://github.com/imagej/imagej-common/issues/12