[ImageJ-devel] ImageJ2 and OME ROI models
Jason Swedlow
jason at lifesci.dundee.ac.uk
Wed Jun 22 17:49:42 CDT 2011
Curtis et al-
Thanks very much for this.
As a Preamble:
1. We can probably agree that email threads about standards are about as much fun as pounding nails into one's own head.
2. Emails that say "use my standard" are about as helpful as emails saying "wear my socks".
In response:
I want to discuss with everyone one on this side, but I think there is general agreement with all the points you are making. The model ImageJ uses for ROIs (or anything else) must deliver utility for ImageJ devs and users-- that's its first priority. I think the major point is that we should build and implement these tools mindful of common and interoperable use. That sounds like what is happening, and Lee's work to date sounds great. We'll look at it and report back. In any case, I doubt we can completely avoid adapting one to another. I believe we should treat the willingness to consider and plan for adaptability as a good thing, and the basis for future cooperation and collaboration.
On the wider issue of broadening OME's scope, that is happening anyway, and will be done because it is useful and for no other reason. We'll likely agree to keep "OME", and we can decide what M stands for later (maybe "Muhahahahahaha!").
The "split the schema" suggestion is interesting. We were discussing this today. We have EM models, SPIM models, EHR models, etc. all coming in. So we need to understand how to do this. Not a small task, and doubtless, enough work to keep us busy.
For the moment, we should focus on getting the work done, and getting implementations that show these models working. We'll start cogitating on the split schema issue, using these lists.
Cheers,
Jason
On 22 Jun 2011, at 18:30, Curtis Rueden wrote:
> 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
>
>
**************************
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20110622/8ec0d72e/attachment.html>
More information about the ImageJ-devel
mailing list