[ome-devel] Who's who in Pixels?

Josh Moore josh at glencoesoftware.com
Fri Oct 7 13:20:37 BST 2011


On Oct 7, 2011, at 12:05 PM, Harri Jäälinoja wrote:

> 
> Hello all,
> 
> I am interested in finding out the true identities of the files in the /OMERO/Pixels directory, where the binary data goes. For example:
> 
> 1 = image1.jpg
> 2 = /home/bob/Data/sample1/A1.tiff
> 3 = ...
> 
> Is there a way to query this from the OMERO database?

Sure. If you want to load the whole graph you can use:

  omero.model.Pixels p = sf.getPixelsService().retrievePixDescription(1);

The image name is available from:

  String imageName = p.getImage().getName().getValue();

If you'd like to bulk load, you'll need to use the sf.getQueryService().projection() method.

> Are these identities permanent? For example, Pixels/1 will always be image1.jpg? Or if image1.jpg is deleted, can 1 later on point contain the pixels of image3.jpg, imported in the system later on?

The ids in OMERO are unique per DB instance and won't be reused after deletion.

> What I am after is integration of OMERO with iRODS, which I was thinking about earlier on as well. The mailing list thread is here:
> http://lists.openmicroscopy.org.uk/pipermail/ome-users/2010-October/002452.html
> 
> My latest idea is to have all OMERO data go in iRODS, by simply setting the OMERO binary repository be a folder where iRODS is mounted via FUSE. https://www.irods.org/index.php/iRODS_FUSE. I have tested with one image so far, so I cannot say much about performance or possible problems yet.
> 
> The original data (before OMERO import) are also in iRODS, and
> OMERO import is made automatically via Dropbox:
> http://wiki.helsinki.fi/display/LMUISA/iRODS+and+OMERO+integration. What I would like to achieve now is a sort of a link between the two. For example, I could add metadata to image1.jpg: CONVERTED_FILE_IN_OMERO="/Pixels/1". This way, if image1.jpg is archived, I could also find and archive Pixels/1, and thus free space on the resource where OMERO is running.

Understood. Let us know if you run into any concrete barriers while making that happen.

> This is still sketchy, and not the optimal situation (as pointed out by Josh in his reply on the mailing list) where one of the replicas of image1.jpg is known to OMERO. If OMERO were to understand image1.jpg as such, without the conversion to the internal format, I think we would have the optimal situation. And now that I think about it, maybe also programmatic access to OMERO will be useful here, not just snooping around in the repository.
> 
> Any comments?

There's been some recent work on making OMERO understand images without conversion, once that API is ready for general consumption, we'll contact the lists. It's possible that that'll be one of the 4.4 releases.

> Best regards,
> Harri

Cheers,
~Josh.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 243 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openmicroscopy.org.uk/pipermail/ome-devel/attachments/20111007/01273918/attachment.pgp>


More information about the ome-devel mailing list