[ome-devel] OME up-and-running, initial feedback

[Graham Klyne]

Hi,

I'm typing these notes now while the experiences are relatively fresh in my 
mind.  I've not yet seen any attempt to use the system in anger (i.e. on 
real microscopy data).  I'm a software engineer, not a bio-researcher, by 
background, so I don't yet know about the microscopy application 
requirements.  My prior Linux experience is merely moderate, and I'm 
thoroughly confused by Perl.

...

Software version:  I've currently installed the latest stable release 
(2.2.1.1, IIRC).  The host is Fedora Core 2 running under VMware 4.5.2., 
with automatically supplied updates (e.g. bringing Postgresql to the level 
of FC3).

...

Installation:  getting all the dependencies right was a bit of a fiddle, 
but the installation script was pretty helpful.  But when things fail, they 
seem to do so fairly messily.  For the most part, the installation script 
could be re-run many times without problem, which was something of a 
blessing.  It would have been nicer if answers already given would be 
remembered in case of installation failure.  I had problems with modules 
not mentioned in the INSTALL.redhat file:  maybe it would be helpful to 
place a note in this file directing new users to the up-to-date online version?

It would be good if the installation script could check early on if the 
PostgresQL database is running -- I had several failures due to forgetting 
to start it.

One problem I experienced was running out of disk space when trying to 
import a batch of images.  There were no diagnostics indicating what had 
happened, and it left the database un-restartable.

After installation, I tried to change the directories used for PostgresQL 
and OME files.  The former was very easy, but when I moved the other files 
there seemed to be "hard-wired" directory references left in the 
database.  I'm not really surprised by this, but given the 
disk-space-intansive nature of OME it would be nice if it there were a 
clear way to move data to (say) a new, larger disk.

I found it wasn't very clear where the OME system itself resides:  the 
running system seemed to use a combination of the original directories from 
which it was installed, and new directories under /OME.  I think the 
default installation would probably be better to not have /OMEIS a 
subdirectory of /OME -- when I install a live system, I expect I shall 
place /OME on the root volume, in (say) /usr/OME, and /OMEIS, along with 
the postgresql data, on a separate volume (say) /usr2/OMEIS and 
/usr2/OME/pgsql.  The idea would be to separate programs (which generally 
don't grow) from data (which is expected to grow like topsy).  Default use 
of symlinks in the software install directory might be one way to ease the 
data moving problem mentioned previously.

A brief section about disk/directory layout in the INSTALL file would be 
helpful.  (Comments about directory/disk layout from folks experienced with 
using OME would be appreciated.)

...

When importing image files, I found the running system seems to require 
that apache has write access to the directory+files from which they are 
imported.  The install script suggests read access is enough, but following 
importation I  saw the file creation times (ls -cl) were updated.  It 
seemed that importation would fail with file-not-exists errors until apache 
had more than just read access to the files (I say seemed, because it may 
be something else that fixed the problems I was seeing.)

...

In use, I found the user interface wasn't immediately obvious.  Mainly, I 
found the command links below the summary bar were not obvious:  a row of 
buttons along the top of the window would be more menu-like.

Also in use:  for testing, I imported a small collection of my own photos 
(from a digital camera), converted to TIFF (I recognize this isn't what OME 
is designed for, but I needed to test *something*).  It's not clear to me 
what kind of processing takes place during import... is there any 
documentation about this?  (I didn't see any.)  The imported images seemed 
to me to be too dark.  Also, when viewing them, I didn't see any way to 
change the scale at which they were viewed, and there was no way to pan 
large images.  I had also hoped that more camera metadata from the TIFF 
file would be captured and displayed.  Am I missing anything here?

Beyond that, I assume that other processing is whatever the researcher may 
want, and is supplied in the form of additional "plug-in" modules.

...

So that's roughly where I am.  My next steps are to figure out how people 
will actually use this software in a research environment, and proceed to 
plan a "live" installation.

#g


---
Graham Klyne
Image Bioinformatics Laboratory
Department of Zoology, University of Oxford
South Parks Road, Oxford OX1 3PS, UK
E-mail: <Graham.Klyne at zoo.ox.ac.uk>
Direct phone: +44-(0)1865-281991
Departmental fax: +44-(0)1865-310447