[ome-devel] optimised viewer for time laps data

Fri May 26 13:06:39 BST 2017

Hi Will,

thanks, this looks amazing! I hope we can give it a try soon.

The new OMERO.iviewer looks fantastic as well! I am really looking 
forward to the meeting :)

See you soon and cheers,
Kai

On 05/23/2017 05:52 PM, William Moore (Staff) wrote:
> Hi Kai,
>
>  Further to our discussion below about a ‘time-lapse’ viewer…
> I have a prototype viewer that I can show you at the meeting next 
> week: https://github.com/will-moore/omero-player
> I didn’t mention it before since it’s not supported by the OME team 
> and it’s just a personal prototype,
> but it is at least pip-installable now, so you might want to have a look.
>
> Ideally (as Jean-Marie said) we’d like to try and get this 
> functionality into our new OMERO.iviewer at some point,
> but this may be a bit tricky.
> We don’t really want to maintain separate viewers because we’d have to 
> duplicate lots of features many times, e.g. ROI editing etc.
>
> So, I can’t promise that this viewer (or one like it) will be 
> supported by the OME team anytime soon,
> but it’s still worth trying out a prototype to help us make those 
> decisions.
>
>  See you at the meeting…
>
>   Will
>
>
>> On 21 Jan 2017, at 16:34, Kai Schleicher <kai.schleicher at unibas.ch 
>> <mailto:kai.schleicher at unibas.ch>> wrote:
>>
>> 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> 
>>>> 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.microscopynetwork.unibas.ch/>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 
>>
>> _______________________________________________
>> 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 

-- 
>> 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 | www.biozentrum.unibas.ch | www.microscopynetwork.unibas.ch

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