You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In conjunction with imagej/imagej-common#12, we want to rework how SciJava Displays are structured.
The status quo:
You have an Object, which gets wrapped in a (UI-agnostic) Display. Each Display is a list of such Objects, rather than only a single Object. To visualize that Display, you then need a UI-specific DisplayViewer, which actually shows the Display's contents to the user somehow.
In ImageJ, the type hierarchies are more complex: you have a Data, which is wrapped in a DataView (e.g., Dataset wrapped in DatasetView, or Overlay wrapped in OverlayView). Then an ImageDisplay, which is a type of Display for DataViews.
We can streamline this. Let's have instead:
View, which wraps an Object, and contains visualization settings. Subtypes of view (e.g., ImageView) implemented as needed to encapsulate the appropriate viz settings.
A ViewService handles wrapping of Objects to the most appropriate View.
In the case of images, there would be an ImageView which has a position (while its wrapped Dataset does not).
Display, which becomes a UI-specific thing used by the UIService.
In other words: DisplayViewer gets renamed to Display.
The old Display no longer exists—we only support a single View per Display.
We have a DefaultView that is used for Objects with no particular need for visualization settings.
To cover the need for multiple N-dimensional image objects (i.e., Datasets and Overlays) bagged together, we provide CompositeView, which composes a list of Views in a single composite space.
See also CombinedIntervalet. al in imagej-common, which will facilitate this.
These changes would reduce the amount of names floating around—we would no longer need "viewers" but would only have Views and Displays. It would also help simplify the implementation of new UIs, at least from the perspective of understanding the execution flow.
The text was updated successfully, but these errors were encountered:
There is also the possibility of getting rid of View altogether. Display is UI-specific and operates on a particular type T. All viz settings (e.g., dimensional position of a Dataset) would need to then wrap into Dataset itself. While this would be a slightly worse separation of concerns, it would greatly simplify the architecture, to the point where I'm thinking it's worth it.
So if you want to show the same image with same visualizations settings and position, great—add the same Dataset to two different ImageDisplays or whatever.
And if you want to show the same image with different viz settings, we can have a by-reference Dataset wrapper that exposes different settings, but for the same backing data object.
Further thought needed of course, but my current thinking is "the fewer class hierarchies, the better".
In conjunction with imagej/imagej-common#12, we want to rework how SciJava
Display
s are structured.The status quo:
Object
, which gets wrapped in a (UI-agnostic)Display
. EachDisplay
is a list of suchObject
s, rather than only a singleObject
. To visualize thatDisplay
, you then need a UI-specificDisplayViewer
, which actually shows theDisplay
's contents to the user somehow.Data
, which is wrapped in aDataView
(e.g.,Dataset
wrapped inDatasetView
, orOverlay
wrapped inOverlayView
). Then anImageDisplay
, which is a type ofDisplay
forDataView
s.We can streamline this. Let's have instead:
View
, which wraps anObject
, and contains visualization settings. Subtypes of view (e.g.,ImageView
) implemented as needed to encapsulate the appropriate viz settings.ViewService
handles wrapping ofObject
s to the most appropriateView
.ImageView
which has a position (while its wrappedDataset
does not).Display
, which becomes a UI-specific thing used by theUIService
.DisplayViewer
gets renamed toDisplay
.Display
no longer exists—we only support a singleView
perDisplay
.DefaultView
that is used forObject
s with no particular need for visualization settings.Dataset
s andOverlay
s) bagged together, we provideCompositeView
, which composes a list ofView
s in a single composite space.CombinedInterval
et. al inimagej-common
, which will facilitate this.CompositeView
would be the closest thing to the currentDisplay
, but would support recursive nesting ofView
s, so that a proper object hierarchy can exist (see also Improve Display-DisplayView-Data hierarchy imagej/imagej-common#12).These changes would reduce the amount of names floating around—we would no longer need "viewers" but would only have
View
s andDisplay
s. It would also help simplify the implementation of new UIs, at least from the perspective of understanding the execution flow.The text was updated successfully, but these errors were encountered: