[ImageJ-devel] ImageJ2 and OME ROI models

Wed Jun 22 12:30:20 CDT 2011

Hi Jason,

Thanks for spurring this discussion. I agree that having a single model for
ROIs, or at least extremely compatible models, would be the best thing.

First of all, please realize that the earlier discussion was about
implementation of ROIs in code, rather than modelling. Specifically, we need
the ImgLib2 library (the foundation of the ImageJ2 data model) to support
ROIs. All this talk of KD-trees and hyperrectangle searches is regarding how
best to support the model using data structures. We want to be able to do
things like iterate over all image pixels within a ROI, for which AFAIK
there is no OME reference library. Hopefully ImageJ2/ImgLib2 will help
provide such functionality. Perhaps there is something in OMERO.server or
OMERO.insight that provides such abilities, but my understanding is that
these sorts of features are not exposed as (nor intended to be) standalone
modules for use with other applications. (Though perhaps we could
collaborate on something like that!)

Lee wrote some proof of concept adapter classes that translate between
ImgLib2/ImageJ2 RegionOfInterest objects and OME-XML ROI model objects (as
defined in ome-xml.jar):

http://dev.imagejdev.org/trac/imagej/browser/trunk/core/roi/src/main/java/imagej/roi/omero?rev=2612

At the moment this work is not part of the latest trunk, but we will explore
it further later so that ImageJ can read/write ROIs from/to OME-XML. (And
something similar will likely work for reading/writing from/to an OMERO
server.)

Regarding the definition of the ImageJ2 ROI model, our first priority is to
support everything that ImageJ1 supports. Fortunately, there is very strong
(though not perfect) overlap between OME and ImageJ1 ROIs. As I said above,
it should be straightforward to adapt them between each other.

If you feel adaptation is not sufficient and would like for us to co-develop
a single unified ROI model, we could attempt it. However, my intuition is
that it might be extremely difficult—recall our many discussions at past OME
meetings and how we never fully came to a consensus even then. We would
probably need to formalize such a project, meet in person more often, define
the model as separate from OME-XML as a whole, and have a reference library
for working with ROIs at various levels (data, display, etc.).

A related issue: when it comes to very general standards and foundations for
imaging software, I think we need to move beyond the name "Open Microscopy
Environment." The ImageJ project is broader than just microscopy, being used
by scientists of widely varying disciplines, and we need to respect that.
One idea I mentioned to Josh is to use a "backronym" such as "Open Metadata
Environment" (though Josh pointed out that is probably *too* broad) to keep
the term "OME" while expanding its meaning beyond microscopy, as we have
certainly been working to do technically.

Another thing that would make sense from a technical standpoint would be to
split the OME-XML schema in half: have a base schema for describing image
pixel structure, and an acquisition portion that is more microscopy and/or
life sciences specific. I'm not sure what the best place(s) to divide it
would be. However, as things stand there are some issues with ImageJ2 saving
as OME-TIFF by default even for non-microscopy images. There are quite a few
microscopy-driven design considerations in the schema right now, such as
implicit units. E.g., if ImageJ saves a calibrated photo of a satellite
image as OME-TIFF, storing the spatial calibration as microns per pixel,
rather than e.g. meters per pixel, is awkward.

Lately Kevin and I have been discussing how to improve Bio-Formats to
include support for metadata models beyond OME-XML—or to put it another way,
expand OME-XML beyond microscopy. The issue is a bit semantic, but
regardless we are all working to create broadly useful tools for scientific
imaging, and these growing pains merit further discussion.

Regards,
Curtis

On Tue, Jun 21, 2011 at 1:52 PM, Jason Swedlow
<jason at lifesci.dundee.ac.uk>wrote:

> Hi Gang-
>
> Sorry to do this again-
>
> For ROIs, see
>
> http://www.openmicroscopy.org/Schemas/ROI/2011-06/ROI.xsd
>
> or a more readable version is at:
>
>
> http://git.openmicroscopy.org/src/develop/components/specification/Documentation/Generated/OME-2011-06/ome.html
>
> (you'll have to scroll down a ways to the ROI schema).
>
>  If we want to achieve the interoperability that we often discuss, defining
> a single model for ROIs would help.  Tell us what you don't like and we'll
> work on it.  If you want to reject this, that's fine, and really not a
> problem.  If you can't map what we have to imglib2, then we need to scratch
> our heads and figure out how we might make that work.   There is no pretense
> that our existing model is perfect.  If you tell us what's broken, we'll
> work hard to fix it.
>
> If you come up with a new ROI model, let us know, and we'll do the
> translation work (more work for the Bio-Formats developers, known to you as
> Melissa and Curtis).  Of course, if we all used the same one, or even worked
> to make the translation easy, wouldn't that be great?!?!?!
>
> Cheers,
>
> Jason
>
>
> On 21 Jun 2011, at 19:17, Lee Kamentsky wrote:
>
> Thanks Tobias,
> I ended up not using the KD tree for my composite ROI, but I wrote a
> hyperrectangle search class, net.imglib2.algorithm.kdtree.VolumetricSearch,
> anyway. I'm looking at net.imglib2.collection.KDTree and the searches in
> net.imglib2.neighborsearch and I can see those are better places for it now.
> I'll see if I can find some time to reimplement it there.
>
> But, the one in algorithms works - it's pretty cool to have a database of
> N-dimensional intervals that you can search in log time.
>
> --Lee
>
> On 6/21/2011 1:21 PM, Tobias Pietzsch wrote:
>
> On 06/10/2011 03:33 PM, Lee Kamentsky wrote:
>
> Hi all, esp Dscho & Stephan P. I'm thinking of doing a composite region
>
> of interest which would be a collection any other kinds of region of
>
> interest. I'm thinking that the most efficient way to do this is to use
>
> a K-D tree to store references to the sub-ROIs: Wikipedia says that you
>
> can search for hyper-rectangles (the bounds of the ROIs) by storing the
>
> minimum and maximum extents as a 2N-d object in the hyperplane and then
>
> the search for rectangles containing a point becomes a range search in
>
> the 2N-d space for all points on one side of a hyperplane.
>
>
> So 2 questions:
>
>
> 1) Could I add a leaf that holds onto a real interval,
>
> "RealntervalLeaf<I extends RealInterval>", a search method that returns
>
> all points on one side of a hyperplane (T point, Node<T> node, bool []
>
> above = false to retrieve nodes less than point in the given dimension,
>
> true to retrieve nodes greater than point in the given dimension) and
>
> some wrapper class that purports to be a database of "I extends
>
> RealInterval" with a simple interface for retrieving all RealIntervals
>
> containing a point?
>
>
>
> Hi Lee,
>
>
> I'm a bit out of the loop right now, just getting back into imglib
> development. I don't know if this has been discussed in the Skype channel or
> something, but...
>
>
> Did you consider using the new KDTree implementation in imglib2 core,
> instead of the net.imglib2.algorithm.kdtree?
>
>
> The new KDTree does not require it's T to be a Leaf< T >
>
> and there are implementations of the
> net.imglib2.neighborsearch.*NeighborSearch< T > interfaces.
>
>
> It uses exact median-finding algorithm for constructing the tree
>
> (instead of the approximate one in net.imglib2.algorithm.kdtree).
>
>
> It is also faster, if I remember correctly.
>
>
> best regards,
>
> Tobias
>
>
>
>
> 2) imglib2-algorithms is really useful. There are going to be other
>
> cases where imglib2 or other components would like to use algorithms to
>
> construct things like NativeImg and RegionOfInterest. How do we manage
>
> this? It sure would be nice if imglib2 and imglib2-algorithms were
>
> interdependent. If we're not going to allow that, I'll probably
>
> implement the composite ROI in imglib2-algorithms and I'll wait until
>
> imglib2-algorithms to be completed before I use composite ROIs in ImageJ
>
> 2.0.
>
>
> I'm probably going to do the first for the fun of it, the legacy ROI
>
> code will need it, need a break from the GUI stuff and this will be
>
> refreshing. Tell me what you all think.
>
>
> --Lee
>
>
> _______________________________________________
>
> ImageJ-devel mailing list
>
> ImageJ-devel at imagejdev.org
>
> http://imagejdev.org/mailman/listinfo/imagej-devel
>
>
>
> _______________________________________________
>
> ImageJ-devel mailing list
>
> ImageJ-devel at imagejdev.org
>
> http://imagejdev.org/mailman/listinfo/imagej-devel
>
>
>
> _______________________________________________
> ImageJ-devel mailing list
> ImageJ-devel at imagejdev.org
> http://imagejdev.org/mailman/listinfo/imagej-devel
>
>
>
>
> **************************
> Wellcome Trust Centre for Gene Regulation & Expression
> College of Life Sciences
> MSI/WTB/JBC Complex
> University of Dundee
> Dow Street
> Dundee  DD1 5EH
> United Kingdom
>
> phone (01382) 385819
> Intl phone:  44 1382 385819
> FAX   (01382) 388072
> email: jason at lifesci.dundee.ac.uk
>
> Lab Page: http://gre.lifesci.dundee.ac.uk/staff/jason_swedlow.html
> Open Microscopy Environment: http://openmicroscopy.org
> **************************
>
> The University of Dundee is a Scottish Registered Charity, No. SC015096.
>
>
>
>
> _______________________________________________
> ome-nitpick mailing list
> ome-nitpick at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-nitpick
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20110622/ebd488de/attachment.html>