Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


djatoka, OpenZoom, and Deep Zoom / Seadragon

  • David Marble
    David Marble

    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?

  • Ruven

    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
    clients can achieve smoothness much more easily than javascript ones. Our
    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.

  • David Marble
    David Marble

    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.

    OpenZoom (Flash), Deep Zoom (Silverlight), and Seadragon (javascript/ajax --
    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),
    which is pure javascript making use of Deep Zoom-style tiles, has a very
    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
    javascript viewer, but both with smooth experiences (just one much better than
    the other).

  • Ruven

    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.

    The Seadragon people have done a great job on their javascript client. It
    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.

    : http://merovingio.c2rmf.cnrs.fr/iipimage/iipmooviewer-1.1/blending.shtml
    : http://cima.ng-london.org.uk/iip/examples
    : http://merovingio.c2rmf.cnrs.fr/iipimage/IIPFlashDemo.html
    : http://merovingio.c2rmf.cnrs.fr/iipimage/openzoom/
    : http://denics.free.fr/fliip/fliip.html



Cancel   Add attachments