<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#ffffff">
I'm running into a number of problems with overlays that are caused
by the fact that the EuclideanSpace is now defined on the Dataset
and not on the Display used to composite datasets and overlays.
There are more than a few issues:<br>
<br>
<ul>
<li>Trac issue ImageJ 558 - the user takes a Z-stack, multichannel
image and thresholds it to get a BinaryMaskOverlay and
associated ROI. The ROI is properly defined in a 4-dimensional
space. However, when displayed, a single X/Y plane should be
sampled and displayed, but there is no mechanism to retrieve the
plane being displayed or the color display mode. The code
iterates through the entire stack and that's what causes it to
update slowly.</li>
</ul>
<ul>
<li>Datasets have axes which capture the metadata of what a
particular dimension means. Overlays don't have that.<br>
</li>
<li>Channels are really categorical, not ordinal - there's no
reason the red channel is zero, the green is one and the blue is
two and, with a channel-stack, the DAPI channel in one image
might be the PI channel in a second. You can properly relate one
channel to the other through metadata, but overlays don't have
that.</li>
<li>You might want to composite datasets - take two images and
place them adjacently. What happens if they have different axes?
What happens if they have different channel layouts?</li>
</ul>
So, what I'm thinking is the following:<br>
<ul>
<li>A display represents the EuclideanSpace that's used to
composite overlays and datasets. Think of the display as a big
N-dimensional container and the overlays and datasets float
inside that container.<br>
</li>
<ul>
<li>The display has a set of axes that are the union of all of
the axes that appear in the view data objects.</li>
<li>There are two behaviors for a view object that does not have
an axis in the space. Perhaps the user selects the behavior?:</li>
<ul>
<li>The value in space outside of a single plane defined by a
coordinate location along the axis is nan or null.</li>
<li>The value in space along the missing axis is the same at
all locations along that axis.</li>
</ul>
</ul>
<li>A display window holds the information about what plane is
being displayed and how the channels are composited.</li>
<ul>
<li>The views are asked to display according to the plane
information. A plane is an interval where the min=max for all
dimensions but X and Y. The views could construct appropriate
projectors based on the interval. The display window should
also control the channel compositing information and the views
should reference the display window's compositing information
instead of maintaining their own copies.<br>
</li>
</ul>
<li>Perhaps there is a SpatialDataObject or perhaps the DataObject
is always spatial. In any case, the axis information and channel
metadata should be pushed up the inheritance hierarchy so that
Overlay has a first-class representation of that and operations
that generate overlays from datasets copy the information to the
overlays they create.</li>
<li>There is a spectral dimension, but the channel axis doesn't
capture that. Channels are categorical and should have names so
they can be matched in the same way that axes are matched.</li>
</ul>
It's some work to refactor these things, but as the code base grows
and becomes more entrenched it will become increasingly difficult to
refactor, so we should do it sooner rather than later. I don't think
this is much coding at this point and if you look at the code, there
are places where this organization clarifies some things.<br>
<br>
--Lee<br>
</body>
</html>