Open will-moore opened 2 years ago
This issue has been mentioned on Image.sc Forum. There might be relevant details there:
https://forum.image.sc/t/omero-figure-memory-usage-when-loading-slidescans/58322/3
From the original thread, it looks like the number of resolution levels is definitely involved in this issue. This raises the question of what the behavior of OMERO.figure should be in this scenario.
There are many scenarios where we explicitly disable operations that would require huge memory usages and ultimately harm the server/client, for instance the generation of floating-points OMERO pyramids. One option would be to detect this scenario in OMERO.figure and display an error/warning to the user stating that there are not enough pyramidal levels and that the file should be converted with extra resolutions to be usable for a figure creation.
As discussed, the only option for rendering a large portion of an image when the lowest resolution is not low enough is to use the thumbnail (bird's eye view).
The most conservative cut-off could be omero.pixeldata.max_plane_width/height
(~ 3k * 3k), but could make this configurable.
NB: PIL
will warn if you open an image over MAX_IMAGE_PIXELS
and fail if double that.
MAX_IMAGE_PIXELS = int(1024 * 1024 * 1024 // 4 // 3)
equivalent to 9459 * 9459
sized image.
If the lowest resolution of a pyramid is not very small, the longest size will exceed the max_size given the logic at See https://github.com/ome/omero-figure/blob/b31ace415ac170b970b88f26311f83f1fdb42436/omero_figure/views.py#L183
This can cause a large to be rendered, causing memory issues. See https://forum.image.sc/t/omero-figure-memory-usage-when-loading-slidescans/58322
To create a sample image to match the size and resolutions from the issue above, import a file named
test&sizeX=186496&sizeY=78336&resolutions=3&resolutionScale=4.fake