[ImageJ-devel] Fwd: CompositeOverlay

[Curtis Rueden]

Thanks for your comments, Lee. I am forwarding this thread to imagej-devel,
since the discussion is of general interest.


---------- Forwarded message ----------
From: Lee Kamentsky <leek at broadinstitute.org>
Date: Mon, Jun 18, 2012 at 3:41 PM
Subject: Re: CompositeOverlay
To: Barry DeZonia <bdezonia at gmail.com>
Cc: Curtis Rueden <ctrueden at wisc.edu>, Lee Kamentsky <
leek at broadinstitute.org>


Hi Barry,

On 6/18/2012 4:06 PM, Barry DeZonia wrote:

> Hey guys,
>
> I am wondering if the current CompositeOverlays approach is broken.
> Originally we had CompositeOverlay only be defined by a
> CompositeRegionOfInterest (defined in Imglib). This makes sense but we want
> to be able to serialize overlays and in order to serialize
> CompositeOverlays we need to either push the serializing code down into
> Imglib's RegionOfInterest code or we need to have CompositeOverlays
> maintain the state of multiple overlays.
>
> Currently we've started down the second road. But looking at the API for
> Overlay I can see things that are tricky to deal with. For instance getting
> well defined axes and ranges from the Overlays making up a Composite (e.g.
> what if axes of two overlays are different?).
>

I think the problem here is similar to the issues we have when combining
any two objects - the EuclideanSpace of the objects might be different and
the "meaning" of the composite is ambiguous: does a 2-d overlay select a
plane in a 3-d space or does it project through all of the planes? So part
of the problem with the overlays as I wrote them was that they only handled
the trivial case and they made assumptions about the user's intent when
mapping onto higher-dimension spaces.


 We could make and(), or(), not(), etc. check that the referenced overlay
> is compatible with the current definition. But before I write a bunch of
> code I'd like to see what you guys think the best approach is. Any
> suggestions?
>
>
In Barcelona, we talked briefly about strategies for melding objects in
different spaces using space-space mappings to project everything into a
common space. That's useful not only for overlays, but for multi-image
alignment and other problems. My gut reaction is that this is another
flavor of the same problem. When creating a composite, you need both the
overlay and a mapping object that translates the coordinates of the
composite space into those of the overlay space (or that executes an
out-of-bounds strategy for coordinates that don't map). We talked about
drawing overlays in a 3-d viewer where the view plane might not be X-Y
plane - there, the space-space mapping lets you rotate our 2-d overlays in
the 3-d space.

I think there's a lot of value in making the composite manage individual
overlays. I have a feeling people will want to ungroup the composites and
adjust the individual shapes, then group them again. I'm also guessing that
people might want each of the sub-objects to have its own line and fill.

Pragmatically, it's possible to take baby steps. You could create a single
identity mapping and have the current code either throw an exception if
axes didn't match or use the identity mapping if they did. Then, you could
add different flavors of and(), or()... to take both an overlay and a
mapping. The mappings themselves would need to be serializable and the
serialization of the composite would wrap the serializations of the overlay
/ mapping pairs.

Hope this helps,
--Lee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20120619/201495fb/attachment.html>