Open Microscopy Environment

We are in the process of acquiring a new server, and moving all our data into OMERO. How much disk space will be needed? I'm not quite sure how the image server is handling caching etc.

The images we have are about 2TB jpeg-files. uncompressed, assume around 20TB. I am working on a converter to store the files in ome.tiff without switching to LZW-compression so hopefully the input will instead be about 2TB ome.tiff in the end.

That's actually a bit of a tricky question and it depends heavily on the tradeoffs you are willing to put up with. As of OMERO Beta 4.3.0 users have had access to a set of techniques we call FS Lite (http://trac.openmicroscopy.org.uk/ome/ticket/5640). These techniques were developed as a mechanism to satisfy the big image use case where the 2D (X/width and Y/height) dimensions of the image number in the 10's of thousands. 150,000 pixel square images are a concrete example of this. The file formats that were FS Lite enabled in 4.3.0 were:

• Aperio SVS
• JPEG
• PNG
• JP2
• TIFF

Part of the FS Lite techniques are that each 2D plane of the image must be converted into a losslessly compressed (via JPEG-2000) image pyramid by the server before it can viewed. As we progressed through OMERO Beta 4.3.1 and 4.3.2 it became clear from user feedback that this image pyramid generation technique and thus FS Lite was not something everyone who used the above file formats required exclusively. In OMERO Beta 4.3.2 we did two things to address the issue:

[list=]
[*]Put in place a configurable size criteria (http://trac.openmicroscopy.org.uk/ome/ticket/6313)[/*]
[*]Made the list of FS Lite enabled file formats configurable (http://trac.openmicroscopy.org.uk/ome/ticket/6313)[/*]
[/list=]

With that background in mind and depending on the dimensions of your JPEG files you could simply lower the size criteria on your server. This would ensure that all your data was subject to the FS Lite techniques. The down side is per-2D plane read speeds from the JPEG-2000 compressed image pyramid that would be created are significantly slower than with uncompressed data. The advantage of course is that your source data would be losslessly JPEG-2000 compressed.

It sounds like we could more or less disable this feature; one level should be sufficient for our purposes. But there is one confusion as you talk about uncompressed data - do you just mean "original data" or do you imply that an uncompressed version is stored somewhere?

As part of import all data is stored in an uncompressed form in the OMERO binary repository unless the image meets the FS Lite criteria and has an image pyramid generated for it. The levels are something you get for free with JPEG-2000 as part of the wavelet transform that is used to compress the data. They are effectively at a zero cost to you.

As it stands with OMERO Beta 4.3.2 if your JPEGs do not meet the size criteria (the default is 3192 x 3192) that JPEG will be decompressed and stored uncompressed in the OMERO binary repository. If they do meet the size criteria the original JPEG is archived to the server and a losslessly compressed JPEG-2000 pyramid is created for it for the purposes of tiling and image display.

I have done a benchmark and one jpeg of 20kb becomes 28kb jpeg2000 (I had expected more!). So 2TB images will become 5TB with omero. If in the future they could be read out of the original files on-demand it would be great; but for now I'm happy just getting the images into the system. Thanks!