[ome-devel] optimised viewer for time laps data

Sat Jan 21 16:34:06 GMT 2017

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 <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> | 
>> www.biozentrum.unibas.ch <http://www.biozentrum.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 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openmicroscopy.org.uk/pipermail/ome-devel/attachments/20170121/8137c0c9/attachment.html>