Initial impressions about OMERO

[CiclistaDan]

Hello All,

First of all I'd like to commend the developers of OME. I have relied for years on the Bioformats importing library to work with diverse microscopy images from from several of my microscopes. The OMERO platform is also accomplishing things I never thought possible and looks to have great potential for the future of microscopy computing.

Recently I have been looking into options for my lab (and department) to better organize and annotate the increasingly complex images we capture on a day-to-day basis. I obviously chose OMERO as my first solution to these needs and would like to share my thoughts on the product at this point in time to 1.) provide feedback to the developers to help make the best product possible and 2.) inform anyone interested in implementing this my humble opinion. As background on myself, I am a cell biologist and microscopist by training. I am a computer enthusiast who dabbles in several different programming languages in my free time but in no means am I a professional programmer or software designer.

I installed the core OMERO.server on one of our department servers and have been testing it for ~10 hours so far. The first thing that is unfortunately obvious is that this is beta software, with significant delays when rendering image stack projections and during several instances rendering colors/scales became incorrectly displayed. Delays when switching between slices/timepoints leads me to believe the image is not cached, not sure if there is an option to cache current images but I know that would be ideal for adjusting levels and creating projections without the delay.

As much of my current image processing relies on ImageJ macros, I was very interested in using the ImageJ-OMERO plugin. This plugin displays a file tree with no searchability/filterability (not a deal breaker), but the biggest problem was the fact that it only opens images in an "Image5D" style window. This is not easily converted to more common rendering windows (composite hyperstack or ImageJ standard) without splitting the stack/channels apart and reassembling. Furthermore this is not a compatible format for many plugins and at least for my current macros, none of my processing macros. I'm not sure what other methods exist for opening OMERO data directly in ImageJ but this is not usable for me. I do concede that the OMERO scripting ability is appealing, leaving the server to do the heavy processing on site. This would require however to rewrite everything as a python plugin script.

To end on a good note, I found several feature that truly amazed me. The ability to paste image renderings to an entire folder or images is inspiring. Also, the ability to simlpy define ROIs which remain linked to the image without additional file linking might outweigh the problems for people that rely on ROI definitions for much of their processing requirements. Final verdict, good job but we're going to pass on the beta version. Keep up the good work and I promise to give you a try again in a few version.

[jburel]

Good morning

Thanks for comments and feedback.

I installed the core OMERO.server on one of our department servers and have been testing it for ~10 hours so far. The first thing that is unfortunately obvious is that this is beta software, with significant delays when rendering image stack projections and during several instances rendering colors/scales became incorrectly displayed. Delays when switching between slices/timepoints leads me to believe the image is not cached, not sure if there is an option to cache current images but I know that would be ideal for adjusting levels and creating projections without the delay.

A limited number of rendered images rendered is cached. The number varies depending on the number of viewers opened at the same time, and the size of the image.
Could you give us some information about the size of the image?

The rendering code was initially implemented in the client side, we moved it to the server a while back for various reasons. We certainly need have the ability, in some cases, to perform the rendering on the client side. This implies that the raw data must be transferred to the client. Depending on the size of the image, the speed of the network and the memory allocated , this can become an issue.

As much of my current image processing relies on ImageJ macros, I was very interested in using the ImageJ-OMERO plugin. This plugin displays a file tree with no searchability/filterability (not a deal breaker), but the biggest problem was the fact that it only opens images in an "Image5D" style window. This is not easily converted to more common rendering windows (composite hyperstack or ImageJ standard) without splitting the stack/channels apart and reassembling. Furthermore this is not a compatible format for many plugins and at least for my current macros, none of my processing macros. I'm not sure what other methods exist for opening OMERO data directly in ImageJ but this is not usable for me. I do concede that the OMERO scripting ability is appealing, leaving the server to do the heavy processing on site. This would require however to rewrite everything as a python plugin script.

The problem has been addressed and it is now possible to open an image using various viewers.

Jmarie

[jrswedlow]

Hi-

Thanks from all of us on the project for your feedback. Comments like this are very helpful, and we appreciate the time you've taken on this.

A few comments:

I installed the core OMERO.server on one of our department servers and have been testing it for ~10 hours so far. The first thing that is unfortunately obvious is that this is beta software, with significant delays when rendering image stack projections and during several instances rendering colors/scales became incorrectly displayed. Delays when switching between slices/timepoints leads me to believe the image is not cached, not sure if there is an option to cache current images but I know that would be ideal for adjusting levels and creating projections without the delay.

We use OMERO in production for fairly large image stacks and timelapse sequences, and don't see this. As OMERO is a server-client application, this performance depends on the config of the server, network characteristics, etc. Can you tell us anything about this?

Final verdict, good job but we're going to pass on the beta version. Keep up the good work and I promise to give you a try again in a few version.

Thanks, but can you tell us specifically is there's anything else we should address to make you change your mind? Give us a bar to jump over, and we probably will. That's what open source is all about.

Thanks again,

Cheers,

Jason