Openlayers / Deepzoom format

Wed Oct 3 09:54:27 EDT 2012

So here's my setup... and this is likely to change in the near future.

I'll use my main site as a reference:

http://cancer.digitalslidearchive.net (aka CDSA)

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...

There is now a javascript port of the Flex Code--- it was initially
SeaDragonAjax,  and then http://openseadragon.codeplex.com/... which seems
no longer maintained, and most recently (and the one I am playing with now)
 http://thatcher.github.com/openseadragon/

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..

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.

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

vips im_vips2tiff mybig.svs mybig.svs.tif:jpeg:75,tile:256x256,pyramid,,,,8

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...

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).

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 )...

vips im_extract_bands  my.svs
my.svs.tif:jpeg:75,tile:256x256,pyramid,,,,8 0 3

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.

WHY Single file vs Many:

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....

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..

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

Anyway... a bit off topic for this list..

ALSO... NDPI IMAGES!

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)...

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.

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.

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.

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.

dg

On Wed, Oct 3, 2012 at 6:34 AM, Alvaro Gonzalez <agonzalez at kanteron.com>wrote:

> El 03/10/12 12:05, PD Dr. M. Weihrauch escribió:
> > Our requirements are:
> > 1. for the client:
> > a) javascript/ajax (no flash)
> > b) Possibility for annotations (pathology/hematology) or annotation
> > layers, which would be more helpful for teaching purposes
> > c) reads deepzoom-format of the tiles (or works together with untiled
> > images on the server?!)
> > d) redistributable license
> You can meet everything but the annotations with iipmooviewer. Maybe you
> can extend it.
> I've been debugging some javascript problems with the help of Ruven (
> https://github.com/ruven ) and now the git version for iipmooviewer
> works beautifully with DeepZoom images, and is smooth as hell also in
> iPads and mobile browsers.
>
> > 2. for the server:
> > a) we have few images (e. g. around 200), each appr. 70,000x70,000px,
> > but all in SVS format (Aperio)
> > b) we'll have a lot of traffic (e. g. 200 simultaneous users browsing
> > the images)
> > c) Windows based (I know, you'll probably all cry foul, but we develop
> > the login/logout/server architecture on .NET)
> Ouch ;)
> If you go the way of iipmooviewer the CPU load won't be high, as it
> serves plain static files, but I would recommend a Varnish cache in
> front if you have any problems, Microsoft IIS isn't as fast as other web
> servers for serving static files.
>
> If you're restricted to IIS, I would check this:
> http://www.ckode.dk/server-configuration/tuning-iis-7-for-static-content/
>
> If the simultaneous access doesn't congregate to certain images ( i.e.
> it's an online elearning system and most of the people is checking the
> same images) but is distributed between all images, caching is going to
> be a bit more difficult, and I would recommend, also, serving the files
> from an SSD or a 2 or 3 drives fast RAID which isn't shared with the
> rest of the OS or another sites, as it's going to be hit with a lot of IO.
> > Because of 1), we chose openlayers. It does not create a beautiful user
> > experience like sea-dragon, but is IMHO better supported and has the
> > layers, which I find important for our purposes.
> > Regarding 2): Because of John and Benjamins (and others I'm sure) great
> > work, we can tile our SVS images into the deepzoom-format tiles.
> >
> Good luck!
> _______________________________________________
> openslide-users mailing list
> openslide-users at lists.andrew.cmu.edu
> https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users
>

-- 
David A Gutman, M.D. Ph.D.
Assistant Professor of Biomedical Informatics
Senior Research Scientist, Center for Comprehensive Informatics
Emory University School of Medicine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.andrew.cmu.edu/pipermail/openslide-users/attachments/20121003/dca9e4cf/attachment.html 