[ome-users] Image Upload and Java API

[Ilya Goldberg]

On Jul 14, 2006, at 2:04 AM, gerhard wrote:

> Hello,
> Is it not possible that there is a remote function that extracts the
> metadata from uploaded pictures if it is in the right format. I  
> think if
> I upload an image from the webui this is done be the Image Importers.
> So I should be able to run this functions on images when I uploaded  
> the
> to OMEIS.

Yup, this is exactly what I was suggesting.  Send a file to OMEIS,  
tell OME to import it using its standard importers.

All of the importers in OME already operate on files uploaded to  
OMEIS (they do not work on local files).
The idea is to simply open an interface between the upload step and  
the import step.  This would take very minor changes to the code  
(really just adding the API), which is why I was claiming this could  
be done in an afternoon.
The idea would be that as we bring BioFormats on-line, the API would  
work exactly the same way, except it would now support more formats  
and more meta-data transparently.

> Regarding the image upload I would prefer this to be done with XML-RPC
> because this way is independent from the used programming language.

I prefer language neutrality as well (and I'm glad others agree).
I think I'll go ahead and set up an XMLRPC interface so we have  
something to tweak as needed.

Just to get it started, I'll set up what I specified earlier:
getDefaultRepository()
	returns the Repository object, consisting of the fields id and  
ImageServerURL
importFiles (RepositoryID,FileIDs[,DatasetID])
	Parameters are the ID of the default repository, and an array of  
FileIDs as returned by the OMEIS UploadFile call(s)
	A DatasetID is optional as the last parameter (one will be created  
if its not specified).
	This call will block until the files are imported, and return an  
array of ImageIDs.

It turns out there was an XMLRPC method in place to do something like  
this (startImport), but it appears to have never worked.
The startImport call was set up to be non-blocking.  We can leave  
this method in (and fix it) since import can take some time (like  
with a bazillion images, or even a few very large ones).  A non- 
blocking call can't return the image IDs, but it can return something  
that can be used to get the ImageIDs later.  This can also be used to  
keep track of progress.

The blocking call (importFiles) is as good as done.  The non-blocking  
API will be a little harder to use and will require a little more  
work on the back-end (getImportStatus, getImportImages, etc), but  
very doable since a framework for non-blocking requests is already in  
place.

Do we want a blocking call, a non-blocking call or both?

To answer Nick's question:
It is possible to get the list of objects produced by the importer  
during image import with a single call (The outputs of the  
ImageImport Module Execution).  This will include all of the meta- 
data recognized by the importers.  Don't get too excited - there's  
not a whole lot there unless you're importing OME-XML or OME-TIFF (of  
course!).  BioFormats will get more meta-data out of proprietary  
formats (and recognize more file types), and the idea is to use it  
through the same import mechanism, so all of its functionality would  
be available transparently through this very same high level API.

-Ilya


>
> Gerhard
>
> Curtis Rueden wrote:
>
>> Hi Nicholas,
>>
>> We want to be able to do the same thing here at our lab, and have
>> created a command-line utility called "omeul" (currently bundled with
>> VisBio -- http://www.loci.wisc.edu/ome/visbio.html) that uploads
>> images to the OME server. The current implementation only uploads
>> pixels without much (any) accompanying metadata, but we are currently
>> working to migrate omeul into our new Bio-Formats library (
>> http://www.loci.wisc.edu/ome/formats.html) and expand its
>> functionality. We still have a ways to go, and everything is in a bit
>> of flux right now, but we hope to have a more robust solution
>> available for you soon. (The strategy we are going to pursue is much
>> like what Ilya outlined in his reply.)
>>
>> -Curtis
>>
>> On 7/13/06, *Nicholas Lahens* <lahensn at canisius.edu
>> <mailto:lahensn at canisius.edu>> wrote:
>>
>>     Hi Ilya,
>>     Basically, I'm looking into using OME to store images and
>>     image data for use with the Virtual Cell program. Since the
>>     majority of VCell clients are offsite and we don't want to
>>     open up a file directory on the OME machine for uploading
>>     files, having the ability to upload images at the application
>>     level would be great. We could adapt the VCell to do this,
>>     but it is preferable if OME could directly handle remote
>>     image uploads. There's a bit of a crunch here right now, but
>>     tomorrow afternoon I'll have a chance to sit down with my
>>     boss, go over the questions you posed and really work out
>>     what we're looking for. Thanks for all the help.
>>
>>     Nick
>>     _______________________________________________
>>     ome-users mailing list
>>     ome-users at lists.openmicroscopy.org.uk
>>     <mailto:ome-users at lists.openmicroscopy.org.uk>
>>     http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users
>>     <http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users>
>>
>>
>> --------------------------------------------------------------------- 
>> ---
>>
>> _______________________________________________
>> ome-users mailing list
>> ome-users at lists.openmicroscopy.org.uk
>> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users
>>
>>
>
> _______________________________________________
> ome-users mailing list
> ome-users at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users
>