[ome-devel] A few questions (Modified by Douglas Creager)

[Douglas Creager]

Haha, whoops!  I sent Zach a response to this yesterday, intending to 
send it to everyone, but forgot to hit "reply all".  My bad.  Here are 
my two cents in addition to Ilya's.

> (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?

This is an interesting question, and it mostly deals with "what we call 
things" kind of problems.  There are a couple of ways you could go 
about this.

First, it's important to realize that in OME, the word "image" might 
not have the exact same meaning as you expect.  For instance, if you go 
to a microscope, grab an set of raw pixels, and then run those pixels 
through a deconvolution algorithm, what do you have?  A common answer 
is that you have two images -- one of raw pixels, one of the 
deconvolved pixels.

In OME, however, those would be considered a single "image".  The image 
just happens to have two instances of the "Pixels" semantic type.  One 
was generated by the microscope.  The second was generated by a 
deconvolution routine which took in the original pixels and some other 
parameters as input.

Second, features end up being most useful to describe containment-like 
relationships.  However, the features themselves do not really describe 
the details of this containment.  This has to be described by the 
feature's attributes, and can vary wildly.  For instance, the "spots" 
which you describe can be described in any number of ways.  You can 
approximate the spot with a Location and Extent.  If you need more 
precision, you can define it with a binary image mask.  Depending on 
the needs of your algorithm, either (or both) could be appropriate.

As you might have noticed, we had a spot-finding test which 
approximated the spots as ellipsoids, so we ended up creating Location 
and Extent ST's to describe the spots.  In the case of an image mask, 
you'd need to create a new semantic type (called ImageMask) which looks 
very similar to the Pixels semantic type.  Its main difference would be 
that it would be feature-granular, whereas Pixels is image-granular.

> (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?

I assume you're referring to importing image files into OME from 
outside.  There is logic for this on the server side in the 
OME::ImportEngine::* classes.  It supports plugin-like support for 
multiple formats, and has some predefined format classes.  This is how 
we get original microscope images into OME.  As far as I know, this 
logic is also available in both the Web and Shoola UI's.  (I didn't 
write very much of the UI code, though, so I might be wrong.)

In general, the process is:

1) Upload files to OMEIS
2) Import the files with the data server

I know that's very bare-boned; we can try to put together a more 
thorough howto on this subject to post on the docs site if you like.

> (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.

Not yet.  Right now, the UI's only support text-based annotations, 
which have their own semantic type (which is, oddly enough, called 
Annotation).  We hope to add support for more generic annotations (of 
any ST) soon-ish.

> (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?

This would be a documentation problem -- a semantic type's description 
should specify the units for all of its fields.  If any of our types 
don't do this, please notify us so we can fix it.  In general, you can 
assume that the X, Y, and Z dimensions are measured in µm; the C 
dimension in nm; and the T dimension in seconds.

> (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?
>
> 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. (And what if a feature 
> wasn't added by a module execution, but manually?)
>
> 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?

This was two questions, as far as I could tell:


5a) How do I tell which MEX created a feature?

You can't.  This is another issue which needs to be addressed.  Right 
now, you'd have to approximate this by knowing which attributes define 
the feature (it's Location/Extent, or its ImageMask, for instance), and 
look up the data history for those.


5b) How do I retrieve all attributes, of any type, for a given 
(dataset/image/feature)?

Unfortunately, your uninformed eye is correct for now.  If you've 
played around with the Shoola UI, and noticed the sizable delay it 
takes to open up the image browser's heatmap, you've seen this 
limitation in action.  The image browser is doing exactly that -- 
checking each semantic type individually to see if it can be used as 
the basis for a heatmap.

Most of the other major application areas in OME do not have this 
problem, since they know a priori which types they have to deal with.  
It's much easier to retrieve "all attributes of the PlaneMean ST for 
this image" than "all attributes of *all* ST's for this image".  This 
was an example of the usual 80/20 problem in developing any large 
application -- we needed to implement first the simple case which 
handles 80% of the use cases.

So the short answer:  We know this is a limitation which we need to 
address.


> (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...

OME::DBObject and OME::Factory provide the low-level database access 
around which everything else is built.  It's a fairly basic 
object-relational mapping layer, which allows individual rows in a 
database table to be represented in Perl as an object.  It includes 
iterator support, so that large queries generate one object at a time, 
rather than loading everything into memory at once.

All of the core tables (those not defined by semantic types) have their 
own DBObject subclasses which define them.  They do not implement any 
extra functionality; they just describe the format of their tables for 
the DBObject class.

The above is all fairly low-level -- nothing that you couldn't do with 
an INSERT or UPDATE SQL statement.  The OME::Tasks::*Manager classes 
define more complex data manipulation logic; for instance, a method 
which creates a well-formed module execution, along with all of its 
actual inputs.

On top of that are the application-level classes.  The analysis engine 
is in the OME::Analysis::* package.  The import logic is in 
OME::ImportEngine::*.  The Web UI is in OME::Web::*.  The data server 
code which communicates with the Shoola UI is in OME::Remote::*.


I hope this helps.  If you have any other questions, fire away.

--doug

------------------------------------------
Douglas Creager <dcreager at alum.mit.edu>
Visiting Scholar, MIT Dept. of Biology
77 Mass Ave, Rm 68-371, Cambridge MA 02139