[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