So here's my setup... and this is likely to change in the near future.<div><br></div><div>I'll use my main site as a reference:</div><div><br></div><div><a href="http://cancer.digitalslidearchive.net">http://cancer.digitalslidearchive.net</a> (aka CDSA)</div>
<div><br></div><div><br></div><div>So when I started writing this (2-3 years ago).... Main options were MOOVIEWER, and Microsoft's DeepZoom (and it's open source flash version Openzoom), other viewers were available, but I'll just focus on these two. My friend who developed the initial version of my portal really liked FLEX / Flash, so we used that as a prototype. The two main reasons were that in my opinion, the zooming/panning in OpenZoom was much much smoother than the competition.... Even now the javascript version of Mooviewer seems slightly less visually smooth than Flex...</div>
<div><br></div><div>There is now a javascript port of the Flex Code--- it was initially SeaDragonAjax, and then <a href="http://openseadragon.codeplex.com/">http://openseadragon.codeplex.com/</a>... which seems no longer maintained, and most recently (and the one I am playing with now) <a href="http://thatcher.github.com/openseadragon/">http://thatcher.github.com/openseadragon/</a></div>
<div><br></div><div>These javascript implementations seem still smoother than MooViewer, although I haven't played around with Mooviewer lately... since the API for the Flash and Javascript version are quite similar, I am first focused on porting over the main part of my application to Javascript, and then I'll probably try and play with a MOOVIEWER vs Openseadragon versions..</div>
<div><br></div><div><br></div><div>Now in terms of file formats--- this is of course the killer. My microscope uses NDPI images--- which as we have discussed on this listserve are it's own special format. And I mean "special"... in that it's a pain in the ass to deal with.</div>
<div><br></div><div>So let me explain how I am storing images---since I have 5-6 terabytes of SVS and NDPI files, which I also want to be web accessible, I wind up transcoding the SVS files to a pyramidal TIFF image ... at first using VIPS. Most of the SVS files I had could be read using VIPS directly--- the majority of SVS files use standard JPEG compression.. and a command similar to this</div>
<div><br></div><div>vips im_vips2tiff mybig.svs mybig.svs.tif:jpeg:75,tile:256x256,pyramid,,,,8 </div><div><br></div><div>Basically I tell it to create a pyramidal image with 256x256 tiles... the ,,,,8 at the end tells it to output a BIGTIFF image.. not a TIFF image...</div>
<div><br></div><div>So this worked for like 12,000 files--- there was a couple thousand more that it died one... leading me down the openslide / vips route. So if you type tiffinfo on an SVS file and you see 3x003 as the compression-- it means it is encoded as a JPEG2000 image--- and so the only way to decode those images is via OpenSlide (at least in Linux). </div>
<div><br></div><div>So as has been described on the listserve... if you have compiled the proper libtiff, openslide and VIPS... you can convert even a JPEG2000 encoded SVS file directly into a slide pyramid (or typical DeepZoom folder format )...</div>
<div><br></div><div><div>vips im_extract_bands my.svs my.svs.tif:jpeg:75,tile:256x256,pyramid,,,,8 0 3</div></div><div><br></div><div>As has been explained, the format is a bit different once you compile/integrate OpenSlide into the mix--- isntead of im_vips2tiff you must use im_extract_bands; and also add the 0 3 at the end. Openslide outputs an RGB and Alpha channel, and so the 0 3 tells it to start at 0 and grab the first three channels.</div>
<div><br></div><div><br></div><div>WHY Single file vs Many:</div><div><br></div><div>So if your using MooViewer, your probably familiar with IIPIMAGE server. Anyway personally I prefer having a single file for each pyramid--- instead of a single directory. Since I do my own backups, and also have to move things aroudn when I run out of space... the I/O on moving 10,000 big files is obviously much faster than moving 10,000 directories.. each with 100,000 files....</div>
<div><br></div><div><br></div><div>Also.... the original DeepZoom program I was using preferred ZOOMIFY pyramids... whereas the new one I am using prefers DEEPZOOM--- IIPIMAGE can easily serve up the SVS.TIF (aka pyramids) in a number of file formats which allows me to seamlessly play around with different image viewer clients without having to recode all my images..</div>
<div><br></div><div><br></div><div><br></div><div><br></div><div>As for annotations--- I am actually actively pursuing that aspect this month--- drawing on the canvas itself is a solved problem (I have a couple of reference implementations I have seen), but making sure you do it right is of course the key--- so before I decide on a solution I am playing aroudn with the various implementations and seeing what else I would need--- besides annotation boudnaries, you also likely want... who did it.. when they did it... on what browser (maybe)... and then you also want the ability to EDIT the annotations later (or do you...)... etc</div>
<div><br></div><div><br></div><div>Anyway... a bit off topic for this list..</div><div><br></div><div><br></div><div><br></div><div>ALSO... NDPI IMAGES!</div><div><br></div><div>So to deal with NDPI images--- If I am sufficiently reminded I'll drop the source code on github... but I can't release the NDPI.dll so you'd have to obtain that yourself (which is easy to do)...</div>
<div><br></div><div>Basically my program (written by Dr. Lee Cooper in my group)... has a THUMB and a TILE mode... for a lot of my analysis we have to tile the 20X or 40X NDPI image into smaller tiles for analysis... so basically this program given an input NDPI file will tile it into 4096x4096 tiles (or bigger/smaller) at a given resolution.</div>
<div><br></div><div>It also has a mode to simple output a "thumb" at a given resolution -- 1x, 2x, etc...... this function needs to be patched a bit as it currently does NOT have BIGTiff suport.. so it crashes if you try to export too big of a layer.</div>
<div><br></div><div><br></div><div>Most importantly--- I've gotten it to rune using WINE under Ubuntu! (well one of my friends helped me do it).... so we can acutally tile NDPI images on my ubuntu server.</div><div><br>
</div><div><br></div><div><br></div><div>Once the images are tiled into a "friendly" standard TIFFs.... I wrote another program that will reassemble the individual 4096x4096 tiles int oa single BIGTIFF image (yes I know this is a cluge).. Once I have the bigTIFF image however I can run it again directly into VIPS and so display it on my portal/web broweser.</div>
<div><br></div><div><br></div><div><br></div><div>dg</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div>
<div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br><br><div class="gmail_quote">On Wed, Oct 3, 2012 at 6:34 AM, Alvaro Gonzalez <span dir="ltr"><<a href="mailto:agonzalez@kanteron.com" target="_blank">agonzalez@kanteron.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">El 03/10/12 12:05, PD Dr. M. Weihrauch escribió:<br>
<div class="im">> Our requirements are:<br>
> 1. for the client:<br>
> a) javascript/ajax (no flash)<br>
> b) Possibility for annotations (pathology/hematology) or annotation<br>
> layers, which would be more helpful for teaching purposes<br>
> c) reads deepzoom-format of the tiles (or works together with untiled<br>
> images on the server?!)<br>
> d) redistributable license<br>
</div>You can meet everything but the annotations with iipmooviewer. Maybe you<br>
can extend it.<br>
I've been debugging some javascript problems with the help of Ruven (<br>
<a href="https://github.com/ruven" target="_blank">https://github.com/ruven</a> ) and now the git version for iipmooviewer<br>
works beautifully with DeepZoom images, and is smooth as hell also in<br>
iPads and mobile browsers.<br>
<div class="im"><br>
> 2. for the server:<br>
> a) we have few images (e. g. around 200), each appr. 70,000x70,000px,<br>
> but all in SVS format (Aperio)<br>
> b) we'll have a lot of traffic (e. g. 200 simultaneous users browsing<br>
> the images)<br>
> c) Windows based (I know, you'll probably all cry foul, but we develop<br>
> the login/logout/server architecture on .NET)<br>
</div>Ouch ;)<br>
If you go the way of iipmooviewer the CPU load won't be high, as it<br>
serves plain static files, but I would recommend a Varnish cache in<br>
front if you have any problems, Microsoft IIS isn't as fast as other web<br>
servers for serving static files.<br>
<br>
If you're restricted to IIS, I would check this:<br>
<a href="http://www.ckode.dk/server-configuration/tuning-iis-7-for-static-content/" target="_blank">http://www.ckode.dk/server-configuration/tuning-iis-7-for-static-content/</a><br>
<br>
If the simultaneous access doesn't congregate to certain images ( i.e.<br>
it's an online elearning system and most of the people is checking the<br>
same images) but is distributed between all images, caching is going to<br>
be a bit more difficult, and I would recommend, also, serving the files<br>
from an SSD or a 2 or 3 drives fast RAID which isn't shared with the<br>
rest of the OS or another sites, as it's going to be hit with a lot of IO.<br>
<div class="im">> Because of 1), we chose openlayers. It does not create a beautiful user<br>
> experience like sea-dragon, but is IMHO better supported and has the<br>
> layers, which I find important for our purposes.<br>
> Regarding 2): Because of John and Benjamins (and others I'm sure) great<br>
> work, we can tile our SVS images into the deepzoom-format tiles.<br>
><br>
</div>Good luck!<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
openslide-users mailing list<br>
<a href="mailto:openslide-users@lists.andrew.cmu.edu">openslide-users@lists.andrew.cmu.edu</a><br>
<a href="https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users" target="_blank">https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>David A Gutman, M.D. Ph.D.<br>Assistant Professor of Biomedical Informatics<br>Senior Research Scientist, Center for Comprehensive Informatics<br>Emory University School of Medicine<br>
</div>