[ome-users] Image Upload and Java API
Ilya Goldberg
igg at nih.gov
Tue Jul 18 17:00:37 BST 2006
Hello Remote Importers!
As promised, remote import comes to OME
getDefaultRepository() returns a hash:
id => The Repository ID
ImageServerURL => Base URL for OMEIS
importFiles (RepositoryID,FileIDs[,DatasetID])
returns an array of ImageIDs (blocking)
startImport (RepositoryID,FileIDs[,DatasetID])
returns an OME::Task ID (non-blocking)
The DatasetID is optional. A Dataset will be created if its not
specified, just like with the command-line importer.
Please let me know how you like these.
Also, I sexed up the interactive XMLRPC client (OME/src/perl2/OME/
Tests/XMLRPC.pl) to make it easy to test things and see what the
actual calls are.
Here's a brief transcript to see how it works:
---------------------------------
[IGG-Lapzilla:OME-HEAD/src/perl2] igg% perl OME/Tests/XMLRPC.pl
XMLRPC command-line tester for OME
(you can specify the host as an argument to this script)
You will first need to login to OME and get a SessionKey.
After this, you can call any available method and supply any
required parameters. The exact call and the result will be reported.
If the result is not a primitive type, it will be deparsed into perl
syntax.
When prompted, enter one parameter per line.
The parameters will be evaled, so you can send arrays and hashes
specified in perl syntax.
Terminate parameter entry with a blank line.
Using OME server 'http://localhost/shoola/'
Please login to OME:
Username? igg
Password?
Calling createSession (igg,***PASSWORD HIDDEN***)
Got '8a52c10896d7a650e1e72c9f6dcc790e'
Method? getDefaultRepository
Parameters:
Calling dispatch (8a52c10896d7a650e1e72c9f6dcc790e,
getDefaultRepository)
Got 'HASH(0x1977484)'
$VAR1 = {
'ImageServerURL' => 'http://igg-lapzilla.local/cgi-bin/
omeis',
'id' => '4'
};
Method? importFiles
Parameters:
4
[5384,5389,5386,5381,5382,5380,5383,5385,5388,5387]
14
Calling dispatch (8a52c10896d7a650e1e72c9f6dcc790e, importFiles, 4,
ARRAY(0x196a2e4), 14)
Got 'ARRAY(0x1977dc8)'
$VAR1 = [
'122'
];
-------------------
Method? startImport
Parameters:
4
[5384,5389,5386,5381,5382,5380,5383,5385,5388,5387]
14
Calling dispatch (8a52c10896d7a650e1e72c9f6dcc790e, startImport, 4,
ARRAY(0x1979718), 14)
Got '101'
Method? ^C
------------------------
Enjoy!
Ilya
On Jul 14, 2006, at 4:49 PM, Ilya Goldberg wrote:
>
> 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
>>
>
> _______________________________________________
> ome-users mailing list
> ome-users at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users
>
More information about the ome-users
mailing list