<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi Will,</p>
<p>thanks, this looks amazing! I hope we can give it a try soon.<br>
</p>
<p>The new OMERO.iviewer looks fantastic as well! I am really
looking forward to the meeting :)<br>
</p>
<p>See you soon and cheers,<br>
Kai<br>
</p>
<br>
<div class="moz-cite-prefix">On 05/23/2017 05:52 PM, William Moore
(Staff) wrote:<br>
</div>
<blockquote type="cite"
cite="mid:%3C107325FE-BD9C-42BB-8F31-66FAA8BCC623@dundee.ac.uk%3E">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
Hi Kai,
<div class=""><br class="">
</div>
<div class=""> Further to our discussion below about a
‘time-lapse’ viewer…</div>
<div class="">I have a prototype viewer that I can show you at the
meeting next week: <a
href="https://github.com/will-moore/omero-player" class=""
moz-do-not-send="true">https://github.com/will-moore/omero-player</a></div>
<div class="">I didn’t mention it before since it’s not supported
by the OME team and it’s just a personal prototype,</div>
<div class="">but it is at least pip-installable now, so you might
want to have a look.</div>
<div class=""><br class="">
</div>
<div class="">Ideally (as Jean-Marie said) we’d like to try and
get this functionality into our new OMERO.iviewer at some point,</div>
<div class="">but this may be a bit tricky.</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">So, I can’t promise that this viewer (or one like
it) will be supported by the OME team anytime soon,</div>
<div class="">but it’s still worth trying out a prototype to help
us make those decisions.</div>
<div class=""><br class="">
</div>
<div class=""> See you at the meeting…</div>
<div class=""><br class="">
</div>
<div class=""> Will</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
<div>
<blockquote type="cite" class="">
<div class="">On 21 Jan 2017, at 16:34, Kai Schleicher <<a
href="mailto:kai.schleicher@unibas.ch" class=""
moz-do-not-send="true">kai.schleicher@unibas.ch</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
<p class="">Hi Will,</p>
<p class="">thanks for your detailed reply!</p>
<div class=""><br class="webkit-block-placeholder">
</div>
<blockquote type="cite" class="">The FIJI viewer
actually downloads all the planes locally when you
open an image.</blockquote>
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.
<div class=""><br class="webkit-block-placeholder">
</div>
<div class=""><br class="webkit-block-placeholder">
</div>
<blockquote type="cite" class="">I have been considering
a web viewer that loads multiple planes in hand E.g.
see <a moz-do-not-send="true"
href="http://codepen.io/will-moore/pen/Beuyc"
class="">http://codepen.io/will-moore/pen/Beuyc</a> (mouse
wheel to scroll through Z)</blockquote>
This is brilliant! Already for showing the "orthogonal
view", I am sure this would be appreciated a lot by our
users!
<div class=""><br class="webkit-block-placeholder">
</div>
<p class="">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.<br class="">
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.<br class="">
</p>
<div class=""><br class="webkit-block-placeholder">
</div>
<blockquote type="cite" class="">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?</blockquote>
>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". <br class="">
But I can see from <a class="moz-txt-link-freetext"
href="https://github.com/openmicroscopy/omero-webtest/pull/11"
moz-do-not-send="true">
https://github.com/openmicroscopy/omero-webtest/pull/11</a> that you are
already on this :)
<div class=""><br class="webkit-block-placeholder">
</div>
<p class="">Thanks again and cheers,<br class="">
Kai<br class="">
</p>
<p class=""><br class="">
</p>
<br class="">
<div class="moz-cite-prefix">On 01/20/2017 02:24 PM,
William Moore (Staff) wrote:<br class="">
</div>
<blockquote
cite="mid:%3C5DCC62FA-8A8C-4D80-A8E4-22E06FE22707@dundee.ac.uk%3E"
type="cite" class="">
Hi Kai,
<div class=""><br class="">
</div>
<div class=""> The reason for the different speeds of
the viewers is because they access the data in
different ways.</div>
<div class=""><br class="">
</div>
<div class="">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).</div>
<div class="">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.</div>
<div class="">However, you are still reading a plane
at a time from the server.</div>
<div class="">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</div>
<div class="">have all the data in hand, so there’s
nothing to load remotely when you scroll through
planes.</div>
<div class=""><br class="">
</div>
<div class="">I have been considering a web viewer
that loads multiple planes in hand E.g. see <a
moz-do-not-send="true"
href="http://codepen.io/will-moore/pen/Beuyc"
class="">http://codepen.io/will-moore/pen/Beuyc</a> (mouse
wheel to scroll through Z)</div>
<div class="">but you’d have to reload all the
rendered planes from OMERO when you change the
rendering settings.</div>
<div class="">Also it becomes unviable to load all
planes for larger images.</div>
<div class=""><br class="">
</div>
<div class="">Ah - just found that this same question
(with similar response) can be found at <a
moz-do-not-send="true"
href="https://www.openmicroscopy.org/community/viewtopic.php?f=4&t=8079"
class="">https://www.openmicroscopy.org/community/viewtopic.php?f=4&t=8079</a></div>
<div class=""><br class="">
</div>
<div class="">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?</div>
<div class=""><br class="">
</div>
<div class="">We’ll discuss “potential for improving
the situation” and let you know if there’s any
positive news.</div>
<div class=""><br class="">
</div>
<div class=""> Regards,</div>
<div class=""><br class="">
</div>
<div class=""> Will.</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"></span></div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On 20 Jan 2017, at 12:37, Kai
Schleicher <<a
class="moz-txt-link-abbreviated"
href="mailto:kai.schleicher@unibas.ch"
moz-do-not-send="true">kai.schleicher@unibas.ch</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">Hi,<br class="">
<br class="">
In our facility we have a couple of users that
store large time laps datasets in OMERO.<br
class="">
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. ).<br class="">
<br class="">
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.<br
class="">
<br class="">
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.<br class="">
<br class="">
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.<br
class="">
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.<br class="">
<br class="">
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.<br class="">
<br class="">
Thanks for your help and cheers,<br class="">
Kai<br class="">
<br class="">
-- <br class="">
<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">Please note
my NEW PHONE NUMBERS: +41 61 207 57 31
(direct) +41 61 207 22 50
(central)<<<br class="">
</blockquote>
</blockquote>
Kai Schleicher, PhD | Research Associate in
Advanced Light Microscopy | Biozentrum,
University of Basel | Klingelbergstrasse 50/70
| CH-4056 Basel |<br class="">
Phone: +41 61 207 57 31 (direct) +41 61 207 22
50 (central) | <a moz-do-not-send="true"
href="mailto:kai.schleicher@unibas.ch"
class="">
kai.schleicher@unibas.ch</a> | <a
moz-do-not-send="true"
href="http://www.biozentrum.unibas.ch/"
class="">
</a><a class="moz-txt-link-abbreviated"
href="http://www.biozentrum.unibas.ch/"
moz-do-not-send="true">www.biozentrum.unibas.ch</a>
|
<a moz-do-not-send="true"
href="http://www.microscopynetwork.unibas.ch/"
class="">
</a><a class="moz-txt-link-abbreviated"
href="http://www.microscopynetwork.unibas.ch/"
moz-do-not-send="true">www.microscopynetwork.unibas.ch</a><br
class="">
<br class="">
_______________________________________________<br class="">
ome-devel mailing list<br class="">
<a moz-do-not-send="true"
href="mailto:ome-devel@lists.openmicroscopy.org.uk"
class="">ome-devel@lists.openmicroscopy.org.uk</a><br
class="">
<a class="moz-txt-link-freetext"
href="http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel"
moz-do-not-send="true">http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel</a><br
class="">
</div>
</blockquote>
</div>
<br class="">
</div>
<br class="">
<span style="font-size:10pt;" class="">The University
of Dundee is a registered Scottish Charity, No:
SC015096</span>
</blockquote>
<br class="">
</div>
_______________________________________________<br
class="">
ome-devel mailing list<br class="">
<a href="mailto:ome-devel@lists.openmicroscopy.org.uk"
class="" moz-do-not-send="true">ome-devel@lists.openmicroscopy.org.uk</a><br
class="">
<a class="moz-txt-link-freetext" href="http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel">http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel</a><br
class="">
</div>
</blockquote>
</div>
<br class="">
</div>
<br>
<span style="font-size:10pt;">The University of Dundee is a
registered Scottish Charity, No: SC015096</span>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
>> 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) | <a class="moz-txt-link-abbreviated" href="mailto:kai.schleicher@unibas.ch">kai.schleicher@unibas.ch</a> | <a class="moz-txt-link-abbreviated" href="http://www.biozentrum.unibas.ch">www.biozentrum.unibas.ch</a> | <a class="moz-txt-link-abbreviated" href="http://www.microscopynetwork.unibas.ch">www.microscopynetwork.unibas.ch</a></pre>
</body>
</html>