Ice Memory Limit Exception

[ebbwdan]

Hi Josh,

Sorry to cause confusion. The original image has dimensions (xy) 77092x156544. The ROI is around 24000x35000. The images are of adult mouse brain and they are generated using a slide scanner microscope. Users image at 20x so that they can count populations of cells. Sometimes processing of the image requires breaking up the original image into the individual tissue sections (the original file can be difficult to deal with). Currently users create these ROIs offline but I just wanted to see how feasible it was to do this on the server (it is rather slow but it actually handles it pretty well).

I was asking about pyramids because it seems like the display of the image generated from the ROI is quite slow. Maybe sticking to an offline solution then uploading would be better?

Cheers,

Dan.

[jmoore]

Hi Dan,

Sorry to cause confusion. The original image has dimensions (xy) 77092x156544. The ROI is around 24000x35000.

No worries. With images like that, it's certainly good to be clear on the numbers!

Currently users create these ROIs offline but I just wanted to see how feasible it was to do this on the server (it is rather slow but it actually handles it pretty well).

How are users creating the ROIs offline? How are the being stored?

I was asking about pyramids because it seems like the display of the image generated from the ROI is quite slow. Maybe sticking to an offline solution then uploading would be better?

If storage space is not a particular problem, it sounds like you may initially want to store a copy of each ROI as a separate image. They're large enough that they'll trigger the generation of a new pyramid. An annotation on each ROI could point you at the Image ID of the related pyramid. This is, in fact, the beginning of a workflow that was often requested this year at the users' meeting. We'd be very interested to hear if it works for you.

Cheers,
~Josh.

[ebbwdan]

Hi Josh,

Currently our users can make images from sub-regions of the image (maybe the use of ROIs is confusing - not ROIs in the Omero sense) offline using a pretty simple app I wrote in Python (wxpython gui) that uses h5py (this was before I discovered pytables) to get the image data (which is Imaris format) and then writes out the data in one go as an ome-tiff (home-made image writer). I am in the process of changing it over to using tiled writing (I only recently discovered just how big these ROIs are!) and intend to use pylibtiff to do this since it provides an interface to libtiff. (I would also like to extend my app so that users can upload directly to Omero but I am having troubling importing Ice - I will post separately.)

Doing this on the server and then uploading the image sounds like the way to go. Or maybe I'm not totally appreciating what you are telling me in your previous message. And I'm not totally sure I'm appreciating what you mean when you say (sorry!):

An annotation on each ROI could point you at the Image ID of the related pyramid

If I understand correctly it is possible to annotate an ROI? I could get the Image ID of the new image I upload and annotate that ID to the ROI which lives in the parent image?

Cheers,

Dan.

[jmoore]

Currently our users can make images from sub-regions of the image (maybe the use of ROIs is confusing - not ROIs in the Omero sense)

No problem; understood.

...offline using a pretty simple app I wrote in Python (wxpython gui) that uses h5py (this was before I discovered pytables) to get the image data (which is Imaris format) and then writes out the data in one go as an ome-tiff (home-made image writer). I am in the process of changing it over to using tiled writing (I only recently discovered just how big these ROIs are!) and intend to use pylibtiff to do this since it provides an interface to libtiff. (I would also like to extend my app so that users can upload directly to Omero...

Ah, ok. This makes sense now. So though you can define an OME ROI on the original image as, say, a bounding box, these uploaded bits would definitely seem to be new images (as far as OMERO is concerned).

If I understand correctly it is possible to annotate an ROI? I could get the Image ID of the new image I upload and annotate that ID to the ROI which lives in the parent image?

Correct. So the original image would become a reference of sorts, a way to find and navigate "sub-images".

~Josh

[wmoore]

Just a couple of comments:

Be aware that ROI annotations are not displayed in the clients (web or insight) so don't rely on users being able to see these (although you can of course still access them via the API).

An alternative is to add an annotation to the 'child' image to refer to the 'parent' image ID.
In the image description, you can refer to another image as "Image ID: 51" and Insight will display this as a link that opens the specified image.

You might want to look at the Images_From_ROIs.py script that ships with OMERO (under util_scripts
Although this will currently fail with ROIs that are 'Big' (over 3k x 3k) it does work to produce smaller child images from a BIG parent image, using ROIs. ROIs can be added to big images in Insight or via the API.

Once we get the conn.createImagesFromNumpySeq() to work with tiled images, then this restriction on the Images_From_ROIs script will be fixed, and it might be the easiest for your workflow?

Will.

[ebbwdan]

Hi Will and Josh,

Thanks for the clarifications. Makes a bit more sense now.

Will, I actually have the functionality of creating tiled images from Omero ROIs on parent images working (i.e. I have my own version of 'Images_From_ROIs' which creates tiled images when the ROI has a bounding box > 4096). The problem is that the new child image is massive (2e4x3e4 pixels) and since a pyramid isn't getting generated for this new child image, displaying it in the image viewer is quite sluggish (much more so than the truly colossal parent image which does have a pyramid).

Anyway, thank you both for your very helpful suggestions! I'm sure I'll be bugging you with more questions soon enough!

Cheers,

Dan.

[ebbwdan]

Hi Will and Josh,

Just a note to say I was incorrect - when I create a tiled image from an ROI on the server, I do in fact get a pyramid generated.

Overall the child image generation is very slow (even on our production server) when the child image is big - 30mins for 2e4x3e4 pixels. Client side, writing the tiled ome-tiff takes 1-2mins and then the upload is pretty fast.

I also tried the following server-side:

1. The parent image I have is Imaris format (which turns out to be hdf5 underneath) so I used the path on the server to the original file and pytables to get the tiles.
2. Write a tiled tiff with https://code.google.com/p/pylibtiff/.
3. Upload the image as tiles.

This proved to be slightly slower than using the primary pixels in Omero (but does give me the option of getting pixels at the various resolution levels present in the parent hdf5 image).

In both cases I make an annotation to the parent image on each child.

So, overall the workflow is functional but is very slow.

Cheers,

Dan.

[jmoore]

Hi Dan,

Just a note to say I was incorrect - when I create a tiled image from an ROI on the server, I do in fact get a pyramid generated.

Thanks, definitely good to know.

Overall the child image generation is very slow (even on our production server) when the child image is big - 30mins for 2e4x3e4 pixels. Client side, writing the tiled ome-tiff takes 1-2mins and then the upload is pretty fast.

Are you thinking this is an issue in the writing (i.e. pylibtiff) or the retrieving of the tiles?

Cheers,
~Josh.

[ebbwdan]

Hi Josh,

Are you thinking this is an issue in the writing (i.e. pylibtiff) or the retrieving of the tiles?

It is the retrieving that is the trouble. Just for the sake of some numbers, on my VM and for an ROI of 5000x5000, it takes a total of roughly 1 second to get the tiles with pytables and then write them with pylibtiff. It then takes about 60 seconds to retrieve and upload them. I am using PIL to get the tiles (due to a few difficulties reading tiles from directories in pylibtiff). I guess that might be slowing it down a bit, but having said that, if I use the purely server-side solution to read and write tiles it also takes roughly 60s.

Cheers,

Dan.

[jmoore]

Hi Dan,

It is the retrieving that is the trouble. Just for the sake of some numbers, on my VM and for an ROI of 5000x5000, it takes a total of roughly 1 second to get the tiles with pytables and then write them with pylibtiff. It then takes about 60 seconds to retrieve and upload them. I am using PIL to get the tiles (due to a few difficulties reading tiles from directories in pylibtiff). I guess that might be slowing it down a bit, but having said that, if I use the purely server-side solution to read and write tiles it also takes roughly 60s.

Hmmm.... I'm having difficult understanding what's happening where. Any chance of looking at a code repository where we can talk about line numbers?

Cheers,
~Josh