[ome-devel] A few questions

Ilya Goldberg igg at nih.gov
Thu Jul 8 20:23:44 BST 2004 

Hi Zach

On Jul 6, 2004, at 4:19 PM, Zachary Pincus wrote:

> Hello,
>
> I've got a few general questions about OME, to help me get my footing. 
> (Sorry to spam the developer list if this isn't really appropriate 
> traffic -- let me know.)
I think it is.  What does everyone else think?

>
> Also, since I know so little about the guts of the system, some of 
> these might actually be feature requests, etc -- so let me know if 
> that's the case and I'll enter them into the bug-tracker.
>
> (1)  I quite like how each image can be associated with various 
> features. Is there any way to associate an image with features that 
> are themselves images? (e.g. the spots resulting from spot-finding or 
> some such.) Or is the appropriate way to deal with this just by 
> following an analysis chain backwards to find the "parent" image?
A Feature is a general container of attributes, so yes one of the 
attributes can be a set of pixels.  To keep things sane though, you'd 
probably want a Feature's pixels to belong to only that feature and not 
be for the entire image.  An ROI (region of interest) is a good example 
of this.  It could refer to the image's pixels by coordinate, but it 
can be its own set of pixels containing a mask (or some other 
transformation/filter).

>
> (2) At the moment, are there any tools for creating 5-D images from 
> multiple lower-D image files? Clearly this can be done with the omeis 
> API, but has this functionality been bundled up in a tool anywhere?
The TIFF importer looks for a specific regular expression pattern that 
is commonly used by MetaMorph.  Its easy to change this pattern so it 
builds up 5-D images out of collections of 2-D TIFFs, but the Web UI 
does not provide an interactive tool to manipulate this pattern.  
VisBio does though, and it knows how to talk to OME.  Look at:
http://www.loci.wisc.edu/visbio/alpha.html
Only the 3.0 version of VisBio (in alpha) supports OME import.
If you have some ideas about how to specify this using other UIs, 
please let us know!

>
> (3) Is there a UI for editing image metadata? After importing images, 
> I'd love to add more metadata about the microscope, CCD, illumination, 
> etc (i.e. everything supported by the OME XML interchange format) that 
> are not present in the original image files/accessible to the import 
> engine. (Corollary question: if so, can this be done in a batch-mode 
> to multiple images at once?) Again, clearly the API can handle this -- 
> I'm just wondering if this has been added/planned for the various UIs.
Sorry, nothing in the UIs yet.  The idea is to define the microscope 
once, then refer to its components by ID in the various STs that link 
acquisition parameters to images.

>
> (4) How are units dealt with in OME? The schema specify things like 
> "PixelSizeX" or "Wavelength" but the units don't seem to be specified. 
> In general they are obvious for biological imaging (microns, 
> nanometers) -- is that enough?
The units are implied.  They are specified in the schema documentation 
- the two examples you gave have specified units.  If you find some 
that don't please let us know.  Look here for a graphical display of 
the schema:
http://docs.openmicroscopy.org.uk/api/xml/OME/ome-image.html
hold the mouse over the PixelSizeX attribute, and it displays a little 
note that its in microns.  If you click on it and go to the schema 
reference, the units are specified in the Image description, but should 
be repeated in the attribute comments as well, I suppose.

> (5) I'm a bit unclear as to how one goes about asking for "all 
> relevant information" about a feature from the database or the web UI. 
> Let me provide an example -- After running "find spots," information 
> about various features is generated and stored in several database 
> tables: Signals, Extent, Location, Threshold, and Timepoint.
>
> I know this because the "find spots" module specifically declares 
> this. So if I want to find out the "Extent" associated with a given 
> feature, I need to look at the appropriate "Module Execution" record 
> in the web UI. Already something is strange -- why can't I look at the 
> "Feature" record and see this information?
I think the patch release will have a way to look this up on features 
the same way you can with images (see Bug #136).  Don't quote me on 
that though.  We're working on a more comprehensive data browser for a 
later release.  This release was essentially an image repository.  All 
the bits to make a comprehensive image analysis system (and data 
browser) are being worked on.

> Perhaps this is just a UI issue, but the problem seems deeper: nowhere 
> in the "Feature" record is any information about the tables in which 
> the attributes of the feature are stored. Nor does there appear to be 
> a backwards reference to the module execution that generated that 
> feature, where you could find that information.
Since a feature is just a container which has no implied attributes 
whatsoever, the feature is entirely defined by the attributes it has.  
Each feature attribute table has a MEX column, which tells you how it 
came about.

> (And what if a feature wasn't added by a module execution, but 
> manually?)
There are two ways to deal with manual entry.  One is by assigning a 
MEX, in which case the manual entry acts just like a module output.  
The other way is by assigning a NULL MEX.  This makes the entry mutable 
- in the sense that the values can be changed (updated).  Full blown 
attributes with non-null MEXes are immutable.  Again, its meaningless 
to create a feature.  It only means anything if you create an attribute 
for it.  Once you make an attribute, you have a MEX, and you have data 
history/dependency and go from there (assuming its not NULL).  Mutable 
attributes with NULL MEXes may be dropped in a future release.

>
> So, given only a feature ID, how do you find all the attributes of 
> that feature? It appears to my uninformed eye that you would need to 
> trawl through the entire database and ask each table for all records 
> with feature ID = whatever. Is there any unified mechanism for doing 
> this (in SQL or the API)? Or am I missing something fundamental here?
Nope, you're not missing anything fundamental.  You have to do the 
query in at least two parts, and you can't do it purely in SQL.  You 
have to get a list of tables that are used by semantic types of 
granularity 'F', then you have to query each of those tables for your 
feature ID.  The API provides facilities for doing this without 
resorting to SQL.

> (6) Finally, I'm wondering in what areas the APIs are just thin 
> wrappers around the database, and in what areas there is a lot of 
> logic in the code itself. This question is just to get me oriented to 
> what the API does, and where...
Make sure you read the newbie guide:
http://docs.openmicroscopy.org.uk/newbie/

The API follows a factory pattern, so most objects (other than the 
Session) are instantiated using the OME::Factory class 
(src/perl2/OME/Factory.pm).  All OME Objects that have DB counterparts 
inherit from DBObject.  Attributes inherit from SemanticType (which 
inherits from DBObject), but the vast majority of these are constructed 
at run-time, so they don't have package counterparts.  There is a lot 
of code in these three objects (especially DBObject and the classes it 
uses) that deal with translating the relational DB to the OO API.  
There's also a bunch of logic in the AnalysisEngine.pm which drives 
module execution.  Other than the relational/OO translation and the 
AnalysisEngine, its all a fairly skinny API on top of the DB.  There 
are a set of classes in the Tasks directory that have some application 
logic as well, but they're basically a bunch of utility methods and 
also fairly thin.  Lastly, importers for various native file formats 
live in OME::ImportEngine.  Things in the OME::Web class hierarchy 
implement the html UI, and contain a fair amount of application logic.  
Overall, we've tried to minimize the amount of application logic 
because most of it derives directly from the data model, which is 
run-time extensible.

Hope that helps
-Ilya



>
> Thanks for any help at all,
>
> Zach Pincus
>
>
> Department of Biochemistry and Program in Biomedical Informatics
> Stanford University School of Medicine
>
> _______________________________________________
> ome-devel mailing list
> ome-devel at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel
>

More information about the ome-devel mailing list