The OME Blog Because metadata is worth a thousand pictures

OMEROImageChooser

This is the first of what will hopefully be a series of posts about tools developed by members of the community. Ian Munro of Imperial writes:

Over the course of adding OMERO capabilities to a number of pre-existing software tools, I felt that there was a need for a lightweight graphical tool that would make it possible to easily add the capability of allowing users to select images from OMERO, to desktop tools.

What I needed was an OMERO equivalent of JFileChooser or Matlab’s uigetfile or Qt’s QFilelDialog.

OMEROImageChooser is the result.

It is a graphical tool which allows a variety of OMERO objects (Images, Datasets, Plates, Attachments) to be selected with a look and feel modelled on OMERO.insight. It can easily be called from Java or Matlab code and is presented as a quick and relatively easy path to either developing a new OMERO desktop client or adding an OMERO interface to existing code.

The source is available from https://github.com/imperial-photonics/omeUiUtils.

A ready-to-use .jar file compatible with OMERO 5.2.x can be also downloaded from https://bintray.com/imperial-photonics/omeUiUtils/omeUiUtils/.

For instructions on how to integrate with Maven/Gradle, refer to the Bintray user documentation.

There are a number of options available, depending what feedback is needed from the user. The screenshots below illustrate some of these.

  1. Selecting one or more images: selecting images in the UI

  2. Selecting an image or attachment: selecting images or attachments in the UI

  3. Selecting a plate: selecting a plate in the UI

  4. Selecting a Dataset and file name for importing files to OMERO - e.g for use from acquisition tools: selecting a dataset in the UI

UK EU Referendum Update

The recent EU referendum will undoubtedly have implications for the future of UK science. It now seems equally clear that those implications will remain unknown for some time to come. No matter what happens next, we want to emphasize our ongoing commitment to the OME project and to our community.

It is unlikely that our current funding will be altered by the outcome of the referendum or by the apparent upcoming changes to the political landscape. The major awards that support OME’s work–from the Wellcome Trust and BBSRC–are from UK-based institutions. We also participate in several EU projects– Euro-BioImaging, Global BioImaging, MULTIMOT, and CORBEL–that will expire within the two-year window being discussed in the media as the minimum time needed to negotiate a UK departure from the EU. Our understanding is that our participation in these projects is not in question. (We also have newly awarded funding to announce–once we have the final documentation!)

Furthermore, our recent Users Meeting in Dundee once again confirmed strong support from our community and the critical need to develop the tools that will enable the discoveries from next generation imaging technologies that are now appearing in the community’s laboratories. None of our immediate milestones will be modified, and we will keep delivering Bio-Formats, OMERO, and the Image Data Resource1 just as our users expect. We will continue to explore new avenues for funding, based on our community’s need and validation of our software, just as we have done since 2002.

Since the project’s origins, our identity and values have been rooted in openness, and international, cross-cultural collaboration. OME’s achievements have always been made possible by the combined talents of an international team, dedicated to open source software, open development practice, and open engagement with our broad, diverse, and dedicated user community. Today, the members of our development team represent more than ten different nations from both within and outside the EU. Many of us are “immigrants”–we’ve actively chosen to live in new countries with our families to deliver on the promises of interoperability and scale in scientific image informatics. We are a dedicated, multi-national, multi-lingual team that builds and delivers tools that support the global bioimaging community. We think diversity is one of our strengths, as it ensures a range of viewpoints and ideas. We therefore reaffirm our support for inclusion and diversity, and strongly object to the politics of fear and racism that have characterised some of the recent political discussions, referenda and elections. We are an example of the best aspects of the modern, interconnected world that unites dedicated, talented individuals, regardless of race, religion, gender, sexual identity or national origin, with a mission to drive scientific insight and discovery for the benefit of all humankind.

  1. At the time of publication, this was referred to as the ‘Image Data Repository’. 

Affine Transformations of ROI Shapes

The OME Data Model defines a Shape.Transform element with an AffineTransform type that is used to transform a Shape’s position in the image in various ways: scaling, rotations and more. These transformations are performed within the two dimensions of the image’s x, y plane. In order to properly locate a Region of Interest (ROI) on an image any geometric transformations of its Shapes must be taken into account.

The OME Data Model transformation matrix

The OME Data Model’s AffineTransform defines the elements of a transformation matrix,

x′ y′ 1 = A00 A01 A02 A10 A11 A12 0 0 1 x y 1

where the attributes’ geometric meaning is,

A00
scaling of x an example translation
A10
shearing of y
A01
shearing of x
A11
scaling of y
A02
translation of x
A12
translation of y

The accompanying graph shows an example translation of A02=35 in x and A12=-65 in y. The above representation of affine transformations reflects a common approach in computational geometry and works well.

ROI transformations in OMERO 5.2

In OMERO 5.2 the Shape.transform property uses a single string to represent transformations. Historically a variety of formats have been used for this string, most from the World Wide Web Consortium’s Scalable Vector Graphics (SVG), anything from "none" to "rotate (12.000 262.000 174.000)". Unfortunately OMERO clients must thus bear the burden of parsing the possible string formats simply to be able to determine a ROI’s position on the image. From the example illustrated in the previous section, given a Point at (40, 85) with transform "translate(35 -65)", that Point should be understood to be located at (75, 20) in the image.

Parsed transformations in OMERO 5.3

The database upgrade script from OMERO 5.2 to 5.3 will include a parser written in PL/pgSQL that moves these string-based Shape.transform property values of existing ROIs to a new OMERO model object, AffineTransform, whose properties mirror the numeric attributes of the corresponding OME-XML element.

From OMERO 5.3 a Shape that does have an associated transform thus has the named matrix elements A00, A10, A01, A11, A02, A12 conveniently available to OMERO clients as floating-point numbers. This makes it far easier to write clients that properly take account of how a ROI’s Shapes have been transformed.

Adapting existing code

The OME Data Model and Bio-Formats remain unchanged in regard to affine transformations. However, the above constitutes a breaking change for OMERO users. We do not make such changes lightly.

It is highly likely that existing client code that works with OMERO 5.2’s SVG-based Shape.transform property strings already translates them to fit the properties of the new OMERO AffineTransform model object. Such code may parse the "matrix(a00, a10, a01, a11, a02, a12)" SVG format or use transformation matrices in its actual calculation or display. For example, in adapting some of our Java code for OMERO 5.3 we found that the AffineTransform object’s properties directly correspond to properties of the AWT’s AffineTransform Java class that we use already. We are therefore optimistic that, while some ROI-related code does have to be adjusted, it will be a relatively easy process that leaves the code clearer and simpler.

OME 2016 Users Meeting

For those of you who couldn’t make it to Dundee for OME 2016, or maybe just didn’t get to all the sessions you wanted to, we have a range of content on our downloads site–notes, slides and even movie versions of workshop presentations–available to browse from downloads.openmicroscopy.org/presentations/2016/Users-Meeting/ or linked via the programme page if there is specific content you’re interested in.

One of the things the user meeting is really valuable for is hearing about what the rest of the community is doing with our tools so the lightning talks have been a really valuable edition to the format over the past two years. Together with the formal talks, this year’s examples illustrate people doing everything from archiving to data visualization to image processing, from the scale of individual institutions to international research collaborations.

It’s always great to hear positive stories from the community rather than only getting feedback when something needs fixing. To this end, we’d always invite you to make use of the mailing lists and forums to discuss the challenges you’re working on even if you don’t necessarily need help. We’d also be keen to feature your stories on this blog if you’d like to submit something longer e.g. with screenshots - you can open a PR at github.com/ome/blog/ or just drop us an email and we’ll get back to you for details. Did you know we maintain a list of publications using our tools on www.openmicroscopy.org/site/about/publications? We are always happy to hear of new citations to add.

An even newer addition this year was the Unconference sessions on the third day. Again, we’ve put some notes from the session up on our downloads site. The topics covered in the Technical Developer discussions include data pipelines, federation and scaling, while the Admining OMERO section is more about managing data and users, having grown out of a session aimed at facility managers.

The File Formats discussion provides a good example of how we carry issues raised forward. The Unconference session on Reader integration and decentralisation prompted the creation of a GitHub Design issue where the interested members of the community can follow the options we’re considering and make comments.

If you haven’t noticed our Design repo before, you can find Issues relating to a whole range of design scoping for the UI, OMERO.web viewer, Folders etc. You do need a GitHub account to comment but signing up only requires a valid email address. Similarly, we have a selection of public Trello boards at trello.com/ome to help you track what’s going on with the project, and receive notifications and give feedback if you sign up for free.

We’ve had some great feedback from the meeting attendees and would love to carry forward more positive engagement and to help empower our user community to help each other. We’ll be looking at ways to try to promote the activities of our community better going forward and in the meantime, please keep in touch!

Upcoming support for ROI Folders

For several months the OME team has been working on what will soon be released as the new 2016 OME Data Model. The OME Data Model specifies Regions of Interest (ROIs) in terms of a set of Shapes. As OMERO 5.3 will use the new Data Model, the upcoming changes include an initial round of adjustments that improve consistency between Shape representations in the Data Model and OMERO. They will each also include a significant addition: Folders, a new top-level model object.

Using ROI Folders

Our initial focus is on supporting ROI-based Folder workflows. OMERO.insight, OMERO.web and OMERO.cli will offer some support for users to have their images’ ROIs organized into a hierarchy of folders. We have several use cases in mind: for example, one may wish to sort cells into phenotypes or assign ontology terms to them, or an analysis script may track entities across a set of images and use a folder for each entity to store sightings of it. We expect the community to think of many more uses for folders.

Folders may seem rather like Datasets in their implementation: in our current draft of the Data Model one may name Folders, add a description, even annotate them, exactly as with datasets. The most obvious difference from Datasets is what Folders may contain: ROIs, but also other folders, even a mix of both. Folders may be nested arbitrarily deeply but with a caveat: a Folder may have only one parent. The same Dataset can be put into many projects but the Folder hierarchy is a strict tree. This simplifies the user interface and speeds up processing.

Graphical clients

An ROI may be both on an image and in some folders. When a scientist views the ROIs of an image in OMERO.insight or OMERO.web they will be able to see how those ROIs are organized into folders. Work is ongoing in both clients to deliver at least some ability to work with ROIs and folder hierarchies in OMERO 5.3.0. On Twitter, YouTube and elsewhere we have already published some screenshots of how OMERO.insight can be used to organize ROIs into folders and we are working on usability features such as making images searchable by the name of a folder that contains any of the image’s ROIs.

ROI Folder screenshot

OMERO.server and scripts

Users of the Blitz API are well aware that it allows a wider range of actions than the graphical clients support. Those exploring how Folders are represented will see that a Folder has a parentFolder property for its parent, if any, and childFolders and roiLinks properties for its contents, as they might expect.

In our current draft of the new OME Data Model folders may directly contain images regardless of ROIs. One may expect the graphical clients to ignore this experimental feature, relying instead on folder-image linkage via ROIs as above, but the additional imageLinks property of Folder objects may be useful for grouping images in a different way within a hierarchy.

One concern with writing scripts may be that processing an arbitrarily deep Folder hierarchy could require many separate calls to the IQuery query service. OMERO 5.3.0 will include two new Request subclasses for queries, FindParents and FindChildren, that can be used to traverse hierarchies arbitrarily far in one call: for instance, to ask which images are contained in a set of Folders or in any of their subfolders.

The future of Folders

We have considered proposals for containing other objects, like plates, wells and annotations, in Folders. One can imagine that someday Folders may supersede everything from tag sets to datasets but, in starting out by allowing only a couple of kinds of content, and then only in a strict tree of Folders, we take a conservative approach that allows us to adjust our plans based on how the community reacts to the introduction of Folders in OMERO. We welcome your input on how you see Folders being used in your workflows.