Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
I'm building an application where I'll need to showcase high resolution scans
of old manuscripts. I've been looking over the past few days at IIPImage,
djatoka, OpenZoom, and Deep Zoom / Seadragon.
IIPImage looks pretty good, and I prefer a FastCGI solution over a java-based
solution (djatoka). However, I was wondering if you had any comparison
thoughts on the above solutions. JPEG2000 support like in djatoka and the next
big version of IIPImage is nice for storage requirements, however because of
the pre-sliced web-ready PNGs/JPGs plus level-blending used by OpenZoom
(Flash) and Deep Zoom (Silverlight) / Seadragon (ajax), use of those products
on the web is a much more smooth experience.
Do you have any thoughts on the different approaches?
You seem to have CSS turned off.
Please don't fill out this field.
What do you mean by "level-blending"?
There are, of course, advantages and disadvantages to both approaches. Yes,
with a server-based approach using a TIFF or JPEG2000 you have 1 single file
rather than potentially many hundreds or thousands. Storage space can also be
much lower, especially with JPEG2000. Another advantage is the ability to
handle 16 bit images, to change the contrast and apply other effects server-
side. Our server can also handle scientific multi-channel images such as
multispectral images and 3D topology data etc.
On the other hand, the disadvantage is that you need to install a server
process, which is not necessary for pre-sliced systems. This makes them more
easy to deploy, scale and maintain.
I'm not sure a smooth experience requires pre-slicing. Flash or Silverlight
flash client on the demo page, for example, does the kind of smooth zooming
and scrolling I think you are referring to. Silverlight, of course, does not
work in many web navigators / operating systems, so it also depends on who
your clients are.
So, the appropriate solution depends on the kinds of images you have, your
server environment, whether storage space is an issue, whether you want to use
a particular client or maximize accessibility, whether you prefer to use open
source or closed source software etc.
Thanks for the thorough response. Truly.
Let me see if I understand the differences here -- I might be a little off.
IIPImage and Djatoka are image servers that extract tiles on-the-fly from a
pyramidal tiff or jpeg2000, convert them to a format a browser can render,
then send the tiles over HTTP. This requires extra processing for every
request to view an image and every level of zoom. Storage space is somewhat
less than storing individual the tiles themselves (more for JPEG2000). One
upside is you have the entire image in one place and thus can do some image
processing on-the-fly as well. I'm not sure I get the multi-channel images
comment or 16-bit comment. I'd be interested in any other pluses to this
approach that come to mind.
does not depend on Silverlight or Flash) have very little server overhead as
they rely on browser-friendly images (PNG, JPG) having already been sliced on
the server into tiles for every zoom level. I'll call this the "pre-sliced"
method. This requires more disk space, but arguably the same bandwidth since
IIPImage & Djatoka end up sending similar browser-friendly tiles after slicing
the master images on-the-fly.
What I mean by level-blending is that these 3 pre-sliced methods apparently
load tiles from multiple levels simultaneously, or at least they keep the most
recent tiles in view and cached on the client, so that the user always sees
something, and when they move or zoom, they get an extremely smooth
transition. See the demo at http://seadragon.com and
some deep zoom explanation at http://blogs.msdn.com/lutzg/archive/2009/03/20
Note that even Seadragon (http://seadragon.com),
smooth experience by using this technique (still not as smooth as Flash or
Silverlight, but feels more smooth than IIPMooViewer). No blank tile spaces
have to be filled in when you zoom, you just see a less clear image until the
current level resolves. I'm not sure of the implementation details, but
Seadragon also has a smoother experience when panning. There's no blank space
that needs to be filled in, whether or not the adjacent tiles have already
been loaded. When you pan, either you see a continuous picture with a less
detailed level displayed, or you immediately see the tiles from the current
level that are cached on the client. IIPMooViewer shows blank space either
way, and it's not clear to me if tiles are cached on the client or server.
Does IIPImage do any server caching, and are the images sent cacheable on the
client? Perhaps similar smoothness to what these pre-sliced methods are
getting can be achieved by IIPImage and Djatoka, making the primary decision
only processor vs disk space?
My vote would be for a IIPImage / Djatoka setup that has an option to write
the slices to disk the first time they're requested, so I can deploy my master
JPEG2000 files and have the benefits of pre-rendered tiles for images and zoom
levels that are often accessed. Then a Flash viewer that degrades to a
If you don't get the 16bit stuff, then don't worry, you don't need these
functions! These are images used in professional photography or scientific
You don't need to "write the slices to disk the first time they're requested"
as the file formats we use are already tiled. IIPImage also does server side
caching in memory, so can potentially be faster than pre-sliced tiling if you
have a lot of RAM.
We have several clients that have different strengths and weaknesses. Our Ajax
IIPMooViewer client doesn't currently have the smooth zooming, but is, in my
experience, by far the fastest and most light-weight client out there. It is
also runs in all browsers and is able to run well on older slower hardware. If
you look at our or the at the National Gallery, it's also very extensible. I
will eventually add smooth panning when I have time. If you want smooth
panning now, we also have a that can do this already.
uses, I believe, the canvas extension, so interestingly won't work in internet
explorer. I presume they switch to silverlight for these browsers. Don't
forget also that the licensing of it last time I looked was still uncertain.
You mentioned OpenZoom. It's very nice indeed. Well, OpenZoom is in fact
compatible with IIPImage. There is a demo of OpenZoom using the latest version
of the IIPImage server and a single TIFF file. The next version of our will
probably use the openzoom SDK in some way.