[ome-devel] Existing client side code in C

Thu Aug 5 14:11:38 BST 2004

Ilya Goldberg wrote:
> 
> On Aug 3, 2004, at 8:57 AM, Joshua Moore wrote:
> 
>> Two quick questions:
>>
>> (1) Are there client-side C bindings of the omeis methods available in 
>> CVS?
>>
>> (2) What is the availability of time information in the pixel struct? 
>> I.e. if a user needs to calculate DX/DT over two images or 
>> "timeElapsed=T*DT + startTime", is this available somewhere?
> 
> 
> The context of your question maybe implies that you're considering using 
> omeis for acquisition, which is great and fabulous.
Sorry to say that, but that would just be the second step on our list: 
Right now we just want to get Pixels out of OMEIS, to process them offline.
> So, in that sense, maybe omeis should store timing information for each 
> plane as it comes in.  Currently it does not.
> Is this what you had in mind?
> 
> The concept behind omeis is that it deals only with pixels, and time is 
> a piece of meta-data.  So the proper way to do this is to tell omeis 
> about the pixels, and tell OME about the time.  If we included time in 
> omeis (which we could certainly do, and it wouldn't be that hard) then 
> where do we stop?  Surely you want to store what filter you used for a 
> given channel and what the objective was, and all sorts of other 
> things. OME is really the place for all that stuff.
I totally agree on that: There is probably no end on the amount of 
meta-data one wants to drag out of the store for the processing (what 
other channels are available, maybe planeStatistics would also be nice 
and so on). Coming from a client-side view, it would be nice to have 
only one Image-Object to query and not to bother, where the data comes 
from. But as the nature of the two servers are so completely different, 
I think we will live with the split in ome-is and ome-ds, that is 
already used in OME-JAVA. (the one-and-only ImageObject: Now that's what 
i would call a "skinny" Interface...)
> Since we have java-based import of proprietary files that contain 
> meta-data besides the pixels, this could be used as a basis for doing 
> this sort of thing in C.

> If you're talking about having a dumb piece of acquisition hardware talk 
> to OME, then probably the easiest thing to do is to pre-form chunks of 
> XML that has place-holders for your meta-data, then substitute the 
> place-holders with real values at acquisition time.  Then you just 
> import the XML using the regular mechanism.  In this case, you can have 
> the hardware deposit the pixels into omeis directly, and use an omeis 
> reference in the XML you send to OME.  This gives you the best of both 
> worlds:  a pixel-centric interface for your data and a meta-data-centric 
> interface for your meta-data.  Its a bit of a convolution for a piece of 
> acquisition hardware that only produces a fixed set of meta-data, but 
> its easy enough to accomplish by just treating the XML you need around 
> it as pre-set fluff.  Or you can put the meta-data in the binary form of 
> your convenience, and write a back-end importer for it.
> 
> If you're trying to do something with proprietary files, back-end 
> importers are really the preferred way to deal with them assuming there 
> is enough information in the files to unambiguously populate the 5-D 
> pixel array and any meta-data you want stored with the images.
> 
> Sorry if I've completely misunderstood what you were intending to do.
you're absolutely right: We have these three parts of the problem: 
Getting the information out of the microscope and:
-----one----
a) getting the pixels into ome-is
b) getting the meta-data (and this includes the timestamp) into ome-ds
----two----
a) getting the pixels out of ome-is
b) getting the meta-data out of ome-ds

---- three ----
c) making up a convenient data-structure for the image to make 
calculations easy

one&two seem to be genuine OME-topics, three is more a 
"best-pratices"-question and a little bit out of scope of OME

If I got it right, there are two options for one:
a) using the perl-import-modules
b) using the interfaces ome-is (basically http-put, as chris pointed 
out) and ome-ds (basically xml-rpc) offers

we're using (among others) a Leica TCS SP2 AOBS - when I remember the 
other thread right, there is currently no support for that format, 
especially not for that unholy <project>.txt-file the microscope 
produces and which looks nice, but is not documented, let alone easy to 
parse - but at least it contains the time-stamps we need for the 
calculations. We're currently conferencing with Leica to make them 
produce a more easily readable format. Then it should be straightforward 
to use the api's from ome-is&ome-ds to get the pixels and the meta-data 
in. You mentioned a "regular mechanism to import the XML" - do you have 
any pointers, where we could look for that?! Right now, I've only seen 
the API's from OME-Java, but it will be tedious to produce the DTO's for 
all the attributes we want to store and then insert them manually using 
the api: a simple interface to import an <experiment>.ome would be nicer 
- is there any documentation about this import?

to sum it up: one looks solvable, when Leica can produce some sensible 
files.

----two---
getting the meta-data (here: the timestamps for a given image) out of 
OME-DS from C  - does this belong into the other thread?! A "skinny" 
layer on top of the rpc-calls, that encapsulates the same functionality, 
as OME-DS from the OME-JAVA branch does, would be nice. Do you already 
have examples for that? Getting attributes of some Pixels from OME-DS 
into a C-Program?! How do you do that in the programms inside the 
analysis-chains?! Don't they need any MetaData?! Are they working solely 
on the raw pixels?

thx for your patience!
stefan

> 
> -Ilya
> 
> 
>>
>> -Josh.
>> _______________________________________________
>> ome-devel mailing list
>> ome-devel at lists.openmicroscopy.org.uk
>> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel
>>
> 
> _______________________________________________
> ome-devel mailing list
> ome-devel at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel

-- 
Stefan Frank
iBioS - Intelligent BioInformatics Systems
http://www.dkfz-heidelberg.de/ibios
DKFZ - German Cancer Research Center
Im Neuenheimer Feld 580
69120 Heidelberg
Tel.: +49 (0) 6221 42-3612
Mail: s.frank at dkfz-heidelberg.de