[ome-devel] optimised viewer for time laps data

[Jean-Marie Burel (Staff)]

Hi Kai

The difference between the OMERO.insight and OMERO.insight-ij when viewing an image
is that when the image is opened in OMERO.insight-ij
the plane is retrieved from OMERO using the OmeroReader and rendered in ImageJ i.e.
it does not use the OMERO internal rendering engine.
OMERO.insight will usually render all the active channels i.e. several planes
will be read instead of one at a time usually in ImageJ
This could explain the speed difference you noticed

As mentioned in a recent blog post
http://blog.openmicroscopy.org/future-plans/community/2016/12/21/omero-5-3/
We are focusing our effort on improving the Web client, that also includes the viewer.
Some changes have already been made to the web architecture to allow,for example,  the installation of
dedicated viewers e.g. multivew, general view, figure etc.

We are also exploring alternative mechanism to load the planes
depending on the history navigation: this will support the "hop" use case mentioned in your e-mail.
Some of the features might be integrated, time alllowing, in the new app viewer https://github.com/ome/omero-iviewer
before its first release.

Cheers
jmarie

From: ome-devel <ome-devel-bounces at lists.openmicroscopy.org.uk<mailto:ome-devel-bounces at lists.openmicroscopy.org.uk>> on behalf of Kai Schleicher <kai.schleicher at unibas.ch<mailto:kai.schleicher at unibas.ch>>
Reply-To: OME External Developer List <ome-devel at lists.openmicroscopy.org.uk<mailto:ome-devel at lists.openmicroscopy.org.uk>>
Date: Saturday, 21 January 2017 16:34
To: "ome-devel at lists.openmicroscopy.org.uk<mailto:ome-devel at lists.openmicroscopy.org.uk>" <ome-devel at lists.openmicroscopy.org.uk<mailto:ome-devel at lists.openmicroscopy.org.uk>>
Subject: Re: [ome-devel] optimised viewer for time laps data


Hi Will,

thanks for your detailed reply!

The FIJI viewer actually downloads all the planes locally when you open an image.
I have used the OMERO.insight-ij integration and opened the image as a virtual stack. This way it was actually quite fast to view the first frame, but I believe it opens the images only frame-by-frame, correct? Indeed loading all frames into memory first is not what I am looking for as this would take very long.

I have been considering a web viewer that loads multiple planes in hand E.g. see http://codepen.io/will-moore/pen/Beuyc (mouse wheel to scroll through Z)
This is brilliant! Already for showing the "orthogonal view", I am sure this would be appreciated a lot by our users!

One request regarding viewing tl data was that the users wish to "hop" around in the video, i.e. jump from the first frame directly ~100 frames forward to the middle/end of the tl.
I guess with the approach of loading multiple frames at once this would still pose a problem if they wish to see a frame very "far" away.

You could build a python viewer that behaved similarly to the FIJI viewer, but I’m not sure this would get you any advantages over using FIJI?
>From what I understand I assume it comes down to whats the fastest way to load an image. As I found the FIJI viewer with virtual stack to perform faster than the desktop clients viewer I was wondering if theres further performance improvement possible when writing a "dedicated tl-viewer".
But I can see from https://github.com/openmicroscopy/omero-webtest/pull/11 that you are already on this :)

Thanks again and cheers,
Kai


On 01/20/2017 02:24 PM, William Moore (Staff) wrote:
Hi Kai,

 The reason for the different speeds of the viewers is because they access the data in different ways.

Webclient is slowest since it only loads a single plane at a time and for each plane we have to initialise the rendering engine (open the image file etc).
Insight is faster because it keeps the rendering engine open while you’re viewing the image so it doesn’t have to open the file each time you request a plane.
However, you are still reading a plane at a time from the server.
The FIJI viewer actually downloads all the planes locally when you open an image. This means it takes longer to open the image but then you
have all the data in hand, so there’s nothing to load remotely when you scroll through planes.

I have been considering a web viewer that loads multiple planes in hand E.g. see http://codepen.io/will-moore/pen/Beuyc (mouse wheel to scroll through Z)
but you’d have to reload all the rendered planes from OMERO when you change the rendering settings.
Also it becomes unviable to load all planes for larger images.

Ah - just found that this same question (with similar response) can be found at https://www.openmicroscopy.org/community/viewtopic.php?f=4&t=8079

You could build a python viewer that behaved similarly to the FIJI viewer, but I’m not sure this would get you any advantages over using FIJI?

We’ll discuss “potential for improving the situation” and let you know if there’s any positive news.

 Regards,

   Will.



On 20 Jan 2017, at 12:37, Kai Schleicher <<mailto:kai.schleicher at unibas.ch>kai.schleicher at unibas.ch<mailto:kai.schleicher at unibas.ch>> wrote:

Hi,

In our facility we have a couple of users that store large time laps datasets in OMERO.
Viewing these, i.e. replaying and scrolling around in these tl files is however problematic when using the OMERO viewer, with several seconds long pauses when jumping between frames depending on the size of the images (e.g. ).

I did however notice that there are performance difference depending on the viewer that is used. Here I have tested the web-viewer, desctop-client-viewer and viewing the images in FIJI when fetched via the FIJI-OMERO-connector using virtual stack.

While the desktop-clients-viewer performs about 40% faster than the web-client, the FIJI-OMERO connector provided another increase of about 40% in replay speed compared to the desktop-client.

While I am aware that these viewers are not meant to be optimal for tl-data, my tests make me wonder if it would be possible to write a simple viewer (e.g. in python) dedicated to only this task and optimise it for speed.
I apologise if this question is very naive (and I am also _not_ asking you to write a new viewer :)), but I was simply wondering if there is any potential improving the situation for our users by this approach.

Of course, if you happen to know other factors that also influence the speed at which tl data is replayed, e.g. the file format used, let me know and I'd be happy to try them outI'd be happy to know and try them out.

Thanks for your help and cheers,
Kai

--

Please note my NEW PHONE NUMBERS: +41 61 207 57 31 (direct) +41 61 207 22 50 (central)<<
Kai Schleicher, PhD | Research Associate in Advanced Light Microscopy | Biozentrum, University of Basel | Klingelbergstrasse 50/70 | CH-4056 Basel |
Phone: +41 61 207 57 31 (direct) +41 61 207 22 50 (central) | kai.schleicher at unibas.ch<mailto:kai.schleicher at unibas.ch> | <http://www.biozentrum.unibas.ch> www.biozentrum.unibas.ch<http://www.biozentrum.unibas.ch> | <http://www.microscopynetwork.unibas.ch> www.microscopynetwork.unibas.ch<http://www.microscopynetwork.unibas.ch>

_______________________________________________
ome-devel mailing list
ome-devel at lists.openmicroscopy.org.uk<mailto:ome-devel at lists.openmicroscopy.org.uk>
http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel


The University of Dundee is a registered Scottish Charity, No: SC015096


The University of Dundee is a registered Scottish Charity, No: SC015096
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openmicroscopy.org.uk/pipermail/ome-devel/attachments/20170123/31a166ee/attachment.html>