[ome-devel] Potpourri : Jump in where you can
Joshua Moore
j.moore at dkfz-heidelberg.de
Thu Sep 9 10:56:40 BST 2004
Ok. Just got finished talking to the EMBL biologist (Urban, subsequently
referred to as "He"). A bit of our design plan has changed and I'd like
to do some design-thrashing before getting to work. Several points
follow. Comments on any or all are welcome:
(*) Visualization of plates
He says that everyone in his lab (and by extension everyone, everywhere,
period) doing screens are graphically oriented to looking at plates.
That is, they know where what is on their plate and being able to view
it that way would be a killer app. Whether a .js for the web UI or a
view in Shoola, a rectangular box which they could quickly click on and
get the related image would rock.
(*) Import of metadata
For visualizing plates, we need to get information of the plate size
(20x100, 12x8, etc.) and then map well numbers to spots. This needs to
be an early import. I can certainly cook up a ST for this, but having
his team produce an OME xml is not optimal. Has anyone looked at
alternative formats for ST imports? But this goes a bit further, we'd
like to attach a metadata file to each image (or at least each stack).
Do I just need to stick them in a directory and import them..."voila"?
(*) _Automatic_ Incremental Import
We'd also like to use this initial metadata import for something a bit
trickier: a user creates a "start.ome" file in a directory. In start.ome
is minimally metadata about plate size and number of time steps
(12X*8Y*100T). User imports start.ome into a new dataset. This, ha ha,
should start a process which continually scans that directory for any
new files until 12x8x100 files have been added. (Do we need a time-out?)
These are then uploaded and the matching plane "finished" so that a
composite call can be made for viewing what has already been imported.
(Note: this doesn't even need to be done from the UI. "curl
-Method=UploadFile ..." would work as long as in start.ome is the path
to scan.
E.g.
grid.x=12
grid.y=8
time=100
path=moore/experiment1 # relative to home
(*) Different positions of same spot
It gets a bit trickier still: in their screens a well can have multiple
positions. (A new dimension.) The optimal solution is to have the links
in the well-view (12x8, e.g.) point either to a list of positions or a
.js which automatically opens P (positions) SVG viewers.
(*) UI Searching
Another solution to the multiple position issue is to just use the
searching capabilities. What exactly _are_ the searching capabilities?
I've tried them out in the old (~2) UI and in current CVS UI. They
aren't very intuitive/powerful/whatever...yet. Perhaps this is a quick
workaround. Image Search-->Name-->".*W0001.*T0001.*" would return all
positions of the first time step of the first well.
Fun, fun, fun.
-Josh
More information about the ome-devel
mailing list