Getting the chance to be a part of this group of extremely visionary & talented people is a feeling I cannot describe. I am looking forward to finally meet some of the people I’ve had contact with over the last months in person, among them Ian, Aseem, Ben, Kevin, Lutz, James, Bill, Jay, and all those I haven’t got to know so far.
They are the brilliant minds behind products & projects such as Silverlight Deep Zoom, Seadragon AJAX, Seadragon Mobile, Seadragon.com, Photosynth, WMP HD Photo JPEG XR, Infinite Canvas, Gimme Shiny! and PSP Player.

Personally I see working at Microsoft as a great opportunity to work on all the things I’m passionate about and potentially reach millions of people around the world.

Stay tuned as I’ll share my stories about settling down in the Seattle area and hopefully a bit about the stuff I’ll be working on!

Yours,
Daniel

P.S. OpenZoom

As of next week active development of the OpenZoom SDK on my part will be put on hold for the duration of my internship. I consider the features and components already included (0.4.2.1 release) fairly stable and as many people have shown it’s very well suited to be used in real-world projects. Apart from that, I’ll still try my best to answer questions and help out on the OpenZoom community whenever possible.

I’d like to point that I made sure that the status of the OpenZoom project itself is not in any way affected by this announcement. It’s still open source and free. Actually, I’d like to encourage other people to fork it and continue where I left off.

What Is the OpenZoom SDK?

The OpenZoom SDK is a free & open source toolkit for delivering high-resolution images and Zoomable User Interfaces (ZUIs) to the web and desktop. It is built on top of the Adobe Flash Platform which means you can use it in Flash, Flex, ActionScript & AIR projects equally well.

Showcase

Gigapixel Photography

GigapixelPhotography.com — Dugg almost 5000 times on digg.com.

Copyright 2009, Gigapixel Photography

Alba Water

AlbaWater.com.vn — Stunning microsite for Alba Water.

Copyright 2009, Alba Water

Is This Your Luggage?

Remix of the famous IsThisYourLuggage.com. Powered by OpenZoom.

Copyright 2009, IsThisYourLuggage.com

Development

While the development of the OpenZoom SDK originally started in Subversion on Google Code¹, I have meanwhile successfully and happily migrated it to Git and GitHub.

Having the OpenZoom SDK hosted on GitHub means you can browse the history, fork the project, watch its progress, download tags & branches or just quietly enjoy the power & simplicity of the Git version control system.

Community

The OpenZoom project has a thriving community over at Get Satisfaction with 82+ topics posted, 95+ people participating and me answering questions and addressing bugs in matters of hours.

Unless there’s something confidential about your project or you plan to ask me for my bank account for donations, I promise you’ll get a quicker answer on Get Satisfaction than by emailing me.

License

In order to encourage a broad (ab)use of the OpenZoom SDK, I’ve added two additional licenses under which you can use it. The OpenZoom SDK is now licensed under MPL 1.1/GPL 3/LGPL 3.

This licensing model was adopted from the famous Mozilla foundation and their products I love so much: Firefox and Thunderbird.

Although I’m not a big fan of lawyers either, I strongly recommend you carefully read the licensing terms of the available licenses, choose the one that suits you & your project best and consult with a lawyer if you have questions. You should never assume anything.

With the current licensing model I want to encourage all kinds of projects & products powered by the OpenZoom SDK while ensuring the constant evolution of OpenZoom SDK, including third-party improvements.

Should your project require a different kind of licensing scheme, please contact me at daniel@gasienica.ch.

Attribution

Besides publishing any source code as required by the license you chose, please attribute your use of the OpenZoom SDK by creating a context menu entry with the caption About OpenZoom... linked to http://openzoom.org/. Thanks.

Download & Documentation

Get the latest OpenZoom SDK, including source code, documentation, SWC library and 14 examples for Flash CS3, Flash CS4, Flex & ActionScript projects.

Download OpenZoom SDK (ZIP)

After you’ve downloaded the SDK, please read the OpenZoom SDK API documentation.

Follow

Keep up with the development progress of the OpenZoom SDK through Twitter and Facebook:

• Follow @OpenZoom on Twitter
• Become a Fan of OpenZoom

Donations

With a donation you can support the future development of the OpenZoom SDK and other OpenZoom projects. Thank you.

Stats

Footnote

[1] Thanks, Google, for not ever replying to my two emails and one tweet regarding my deep wish to get the much deserved openzoom project handle which is reserved by a #$*&#@ project on SourceForge (link purposely not included) which hasn’t even had a commit in four years.

Remix: Is This Your Luggage

View Showcase | View Original | View Source

Disclaimer: This is nothing but a showcase for what you can do with zooming & OpenZoom. If you liked this, please give proper respect to the author and visit the original site.

P.S.

This is supposed to demonstrate a bit what kind of experiences you can build with the OpenZoom SDK. It doesn’t always have to be high-resolution images and a boring layout. Hope you enjoy it.

Copyright: All Artwork & Content Copyright 2009, Is This Your Luggage.

Scenarios

The following are three real-world scenarios for publishing high-resolution images on the web: news, blogs and photo sharing. Explore any one or all of these scenarios and interact with the images within… Come on, let’s get your mouse wheel spinnin’!

News: The New York Times

View Demo | View Original Page

Disclaimer: Since a high-resolution version of the original image was not available to me, I replaced it with another one from the Department of Defense which was taken in the same region, called Zabul Province.

Blogs: Information Architects

View Demo | View Original Page

Photo Sharing: Flickr

View Demo | View Original Page

Disclaimer: Due to conflicts, the original JavaScript that was included in the page was removed for this demo.

Vision

The solution for publishing high-resolution images on the web I set out to develop had to have the following qualities…

For Users

• The user shall not pay, in terms of time or bandwidth, for large images she’s not interested in.
• The solution shall degrade gracefully, e.g. fall back to status quo, for users that do not meet the technical requirements.
• The solution shall offer a vastly enhanced experience for viewing high-resolution images on the web, including full screen support while retaining as many of the standard interactions with images as possible.
• The user shall not be taken out of the context she was working in.

For Publishers

• The solution shall offer simple publishing of high-resolution images and turn their exploration into an awesome experience!
• The solution shall be as much backwards- & forwards-compatible as possible.

Solution

The solution I developed, based on something I started to call Inline Multiscale Image Replacement, is a combination of three different technologies from the OpenZoom project, together known as OpenZoom Endo:

• OpenZoom Caral: A Python tool to batch convert images into a multiscale image format based on the OpenZoom Description Format and Microsoft Deep Zoom.
• OpenZoom Nano: A light-weight multiscale image viewer running in the Adobe Flash Player and built with the OpenZoom SDK.
• OpenZoom Endo: A script performing progressive enhancement on new and existing HTML pages. It is written in JavaScript and packaged as jQuery plugin.

Features

• Simple publishing of high-resolution images on the web, even on existing pages.
• Continue to use interactions your already familiar with such as Save Image As… and View Image. (Screenshot)
• Progressively enhance your browsing experience, with graceful fallback for those of you with browsers that are not JavaScript or Flash enabled.
• Never download more data than you currently look at.
• Take advantage of your entire screen real estate by using the full screen mode.
• Explore the full glory of high-resolution images without ever leaving their page.
• Publish images in different sizes from the same source image.
• Free! …as in beer and freedom!
  Released under the GPLv3 open source license.

Known Issues

Of course, as with any fresh-out-of-the-oven technology there a couple of things that don’t work as intended. Here’s a list of known issues:

Image replacement can be delayed by large pages, resulting in a visible page flicker.

At this point, OpenZoom Endo does not pass the W3C validator due to the custom attribute (XHTML namespaces & custom DTDs, anyone?)

Ideally, the viewer would initially feature some visual cues that convey the enhanced functionality. Add some simple controls to that. Designer, anyone?

Script sometimes conflicts with existing JavaScript within the same page.

Multiple replacements of images cause performance problem related to Flash Player plugin instantiation.

Images sometimes fail to load due to plugin activation issues.

Walkabout

Let me quickly guide you through the basic process of publishing a high-resolution image on your web page:

1. First, use Python and the OpenZoom Caral library to convert your image into a multiscale image pyramid and optionally define additional sizes of your image you’d like to publish or offer for download:
   
   

   import openzoom
    
   creator = openzoom.ImageCreator()
   creator.create("awesome.jpg", "awesome", [0, 600, 1920])

2. Reference jQuery library (e.g., using Google) and the OpenZoom Endo script in your HTML page:
   
   

   <script type="text/javascript"
    src="http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js"></script>
   <script type="text/javascript"
    src="openzoom-min.js"></script>

3. Place the OpenZoom Nano viewer SWF (OpenZoomViewer.swf) file into the same directory as your page.
4. Add the image to your HTML page and annotate it with the special openzoom:source attribute:
   
   

   <img src="awesome/awesome-600x320.jpg" width="600" height="320"
    openzoom:source="awesome/image.xml"/>

5. Enjoy hassle-free high-resolution imagery on the web!

Download & Source

• Download OpenZoom Endo (808kb) from Google Code.
• Have a look at the source code on the OpenZoom Google Code repository.

You

I want your feedback! Let me know if my idea works for you… If it doesn’t, why not?… How could things be improved? I am listening. If you’re a JavaScript hacker, take apart my code and share with me what could be done better! If you’re a designer, consider contributing to a better interface for the viewer for an even better user experience! If you’re an iPhone user, let me know if my solution breaks when you check out one of the previous demos! If you think this is b#$&#($*, then share your vision of the future of high-resolution images on the web with me!
As always, if you have feedback, questions or want to start a dialogue, feel free to leave a comment down below, head over to the awesome OpenZoom Get Satisfaction site or follow me on Twitter: @OpenZoom and @gasi. In case you find a bug, please file a bug report in the OpenZoom Google Code Bug System.

Epilogue

With this and my other work on the OpenZoom project, I want to explore new ways of interacting with visual information on the web. Join me and let’s explore how the future of browsers with the appropriate image formats that support high-definition images could look & feel like!

GigaPan Mobile 2.0

GigaPan Mobile 2.0 is here and there’s no need to add RSS feeds to your Seadragon Mobile, although you still can. Just grab your iPhone, launch Safari and head over to GigaPan Mobile and start enjoying all 20′000+ gigapans in full glory.

Quick Setup

1. Get an iPhone/iPod touch.
2. Install Seadragon Mobile.
3. Add the GigaPan Mobile RSS feed to Seadragon Mobile.

GigaPan Mobile RSS Feed

http://gigapan-mobile.appspot.com/feed

Setup

1. Install Seadragon Mobile from the Apple AppStore.
2. Launch Seadragon Mobile…
   
   
3. Tap the + button in the lower right corner to add custom content…
   
4. Choose RSS feed…
   
5. Enter the URL for the GigaPan Mobile feed from above and tap Done.
   

Browse GigaPan Mobile

• Go to the newly added GigaPan feed in Seadragon Mobile…
  
  
• …and explore the details of one of the 10 most popular gigapans from GigaPan.org with just the tips of your fingers.
  
  

Photo President Barack Obama’s Inaugural Address © 2009, David Bergman

Inside GigaPan Mobile

GigaPan Mobile was built using Python, Google App Engine and knowledge acquired through the OpenZoom project.

20′000+ Gigapans (Update – 04.08.2009)

To see one of more than 20′000 gigapans with Seadragon Mobile, simply add the following link as Deep Zoom Content, where <ID> is the gigapan ID number:

Custom GigaPan Content for Seadragon Mobile

http://gigapan-mobile.appspot.com/gigapan/<ID>.dzi

Example: Obama Inaugural Address
http://gigapan-mobile.appspot.com/gigapan/17217.dzi

GigaPan Desktop

Keyboard Shortcuts

• F: Toggle Fullscreen
• H: Show All
• W, S, A, D or arrow keys: Pan
• I, O or +, –: Zoom

Download & Source

Download | View Source

Feedback

Please post feedback and feature requests on the GetSatisfaction OpenZoom channel, thanks.

Demo: Z-Order Visualization

View Demo | View Source | View ZOrder Class Source

You might know that since version CS3 Adobe Photoshop has a great built-in feature for exporting high-resolution images with Zoomify. The feature works really great. Although it took my machine a couple of minutes, I've managed to export a beautiful 86400×43200 pixel version of the NASA Blue Marble images. The feature would be perfect if it wasn't for the not so perfect, not so smooth Zoomify viewer that is used to view the exported image.

Scratching Your Own Itch

Therefore, while enjoying the calm of the holidays, I sat down and developed an OpenZoom viewer that you can use as an drop-in replacement for the built-in Zoomify viewer in Adobe Photoshop.

Demo: OpenZoom Viewer for Adobe Photoshop

New and improved viewer built with the OpenZoom SDK:

View Demo | View Source

Features

• Fullscreen support
• Mouse navigation (click to zoom in and Shift-click to zoom out)
• Mouse wheel support in all browsers (scroll to zoom)
• Keyboard navigation (Pan with W, S, A, D or arrow keys, Zoom with + / – or I and O, Show All with H, Fullscreen with F.)
• Context Menu support
• Standards-compliant Flash embed through SWFObject
• 6 templates — Normal / Fullscreen: black, gray and white.
• Just 40KB — 100% Flash, no Flex.
• 100% Open Source. No branding.

Demo: Zoomify Viewer for Adobe Photoshop

For comparison, this is the old Zoomify viewer in Photoshop:

View Demo

Download

1. Download OpenZoom Viewer Templates
   for Adobe Photoshop CS3/CS4 (ZIP – 86KB).
2. For installation and tutorials, read the instructions in README.txt
3. Enjoy and let me know what you come up with!

Update — March 25, 2009

The OpenZoom Viewer Templates received an update in the form of a 0.3 release and are now known as OpenZoom Tango.

Update — August 9, 2009

With the 0.5.2 release, OpenZoom Tango has moved from Google Code to GitHub. Additionally, OpenZoom Tango is now licensed under the MPL 1.1/GPL 3/LGPL 3 licenses.

P.S. To get started, check out this great tutorial called Zoomify High Resolution Images With Photoshop CS3.

The Truth Is Out There

Taking this paradigm into account, we suddenly encounter a problem with multi-scale images. If the original image is exploded into many little pieces, where do we store its metadata? There are different solutions to this problem. For mapping sites such as Google Maps and Yahoo Maps it is probably sufficient to just hard-code the image pyramid properties and how to access the tiles directly inside the client. However, for general multi-scale image viewing technologies such as Zoomify, Deep Zoom or OpenZoom this is not an option since we don’t know the properties of the images until run-time. Again, there’s a simple and elegant solution to for this: XML description files that carry the image metadata.

Rumble In the Jungle

In the following section I will first quickly present you the two dominant multi-scale image description formats out there: Zoomify and Microsoft Deep Zoom. After that, I will introduce you to a new description format I designed called OpenZoom description format.

Note: The following examples all describe a 10 megapixel JPEG image with the name bruges.

Zoomify

Example

<IMAGE_PROPERTIES VERSION="1.8"
 WIDTH="3872" HEIGHT="2592" TILESIZE="256"
 NUMTILES="241" NUMIMAGES="1"/>

This Zoomify image has the following structure on the file system:
Descriptor
bruges/ImageProperties.xml
[filename]/ImageProperties.xml

Tiles
bruges/TileGroup0/0-0-0.jpg
bruges/TileGroup0/1-0-0.jpg
bruges/TileGroup0/1-0-1.jpg
bruges/TileGroup0/1-1-0.jpg
bruges/TileGroup0/1-1-1.jpg
bruges/TileGroup0/2-0-0.jpg
…
bruges/TileGroup0/4-15-9.jpg
[filename]/TileGroup[X]/[level]-[column]-[row].jpg

Deep Zoom Image (DZI)

Example

<?xml version="1.0" encoding="UTF-8"?>
<Image xmlns="http://schemas.microsoft.com/deepzoom/2008"
       TileSize="256" Overlap="1" Format="jpg">
  <Size Width="3872" Height="2592"/>
</Image>

This Deep Zoom image (DZI) has the following structure on the file system:
Descriptor
bruges.xml
[filename].[xml|dzi]

Tiles
bruges_files/0/0_0.jpg
bruges_files/1/0_0.jpg
bruges_files/2/0_0.jpg
…
bruges_files/9/0_0.jpg
bruges_files/9/0_1.jpg
bruges_files/9/1_0.jpg
bruges_files/9/1_1.jpg
…
bruges_files/12/15_9.jpg
[filename]_files/[level]/[column]-[row].[extension]

OpenZoom Description Format

The following is actually a description of the Deep Zoom image we’ve looked at previously.

Descriptor
bruges.xml

[filename].xml

Tiles
Wherever you wish…

Example

<?xml version="1.0" encoding="UTF-8"?>
<image xmlns="http://ns.openzoom.org/openzoom/2008">
  <pyramid width="131072" height="131072" type="image/jpeg"
           tileWidth="256" tileHeight="256" tileOverlap="0" origin="topLeft">
	<level width="1" height="1" columns="1" rows="1">
	  <uri template="bruges_files/0/{column}_{row}.jpg"/>
	</level>
	<level width="2" height="2" columns="1" rows="1">
	  <uri template="bruges_files/1/{column}_{row}.jpg"/>
	</level>
       …
	<level width="242" height="162" columns="1" rows="1">
	  <uri template="bruges_files/8/{column}_{row}.jpg"/>
	</level>
	<level width="484" height="324" columns="2" rows="2">
	  <uri template="bruges_files/9/{column}_{row}.jpg"/>
	</level>
	<level width="968" height="648" columns="4" rows="3">
	  <uri template="bruges_files/10/{column}_{row}.jpg"/>
	</level>
	<level width="1936" height="1296" columns="8" rows="6">
	  <uri template="bruges_files/11/{column}_{row}.jpg"/>
	</level>
	<level width="3872" height="2592" columns="16" rows="11">
	  <uri template="bruges_files/12/{column}_{row}.jpg"/>
	</level>
  </pyramid>
</image>

OpenZoom Description Format XML Schema (Draft)

Not Invented Here

Alright, we’ve seen examples of all three description formats for the same image. Before anything else, you might ask yourself: Why the #&$@ another format? Good attitude and glad you asked. Hopefully, I will be able to answer this question for most of you. If not, just leave me a comment, I’d be glad to discuss this further. Now, let’s compare these three formats by looking at where they shine but of course also at their shortcomings.

Conciseness

Obviously, Zoomify and Deep Zoom win big time here. Their description files have a couple of lines vs the 40+ lines of the OpenZoom descriptor which inherently is very verbose — Ed.: Levels 2–7 omitted for esthetic reasons. On the other hand, we should keep in mind that everything we see in the OpenZoom descriptor sample somehow has to be computed by the client for the other two formats. More on that later.

Portability

Not sure if portability is the right term, but let me explain what I mean: How flexible is the format regarding the storage of the descriptor and its image tiles? Deep Zoom is the most extreme case of the three where the descriptor file and the image tiles are strongly coupled through the original file name of your image. That means if you move your descriptor you always have to remember to move the image data folder as well. This could be considered risky as the two are not contained in one folder. Zoomify has the same limitation but at least the image data and its descriptor are both contained in the same folder that carries the name of the original image. OpenZoom is clearly the most portable of the three as it let’s you specify the descriptor file independently of the image tiles.

Important Note: Both Microsoft and Zoomify offer an alternative storage method in the form of a single-file format. They are called Zoomify’s Pyramidal File Format (PFF) and DZIZ (a ZIP-based container for DZI) which I’ve seen used by Microsoft Photosynth.

Flexibility

Flexibility apparently was not a design goal of Microsoft or Zoomify. This is fine considering that the design of such a new format requires these kinds of trade-offs. Their assumption is that the descriptor file and the image tiles are strongly coupled and the latter are computed with a well-defined algorithm and stored in a fixed file hierarchy. Flexibility is the area where the OpenZoom description format shines. When I worked on the OpenZoom description format, I obviously followed the Python Zen which states Explicit is better than implicit. Although one drawback is the verbosity of the format, there are many advantages we can get from it. For example, when I worked on the OpenZoom framework, I wanted to test it with some really large multi-scale images that are out there. Well, what is the largest image out there that I know of? A map of the world, of course. The OpenStreetMap Project, for example, features many, many gigapixels of image data. Fine, so how do I test the framework with a map? Hard-code the URLs somewhere? No, no. Let’s create a descriptor for it. So I did. Grab it and play with it with your copy of the OpenZoom framework. Look Ma’, no code!

This example demonstrates one of the advantages of the format, namely your descriptor file does not have to be stored along with your image data. Just put your descriptor wherever you wish and point it to the image tiles.

Features: OpenZoom Description Format

The following section gives you a short summary of some of the features in the OpenZoom description format.

Flexible Pyramid Layout
Behind both Zoomify and Deep Zoom, there are well-specified algorithms that create the image pyramid and define its properties. To get an idea of how the formats expand the information you previously saw in their descriptors, feel free to take a look at their implementation in OpenZoom: ZoomifyDescriptor and DZIDescriptor.

The OpenZoom description format doesn’t require a particular layout of the image pyramid. One requirement would be that every level of the pyramid approximately has the same aspect ratio but I’ve even managed to work around that constraint. To give you an idea of how powerful this flexibility is, consider the following couple of facts:

1. The OpenZoom description format can express both, the properties of a Deep Zoom image pyramid, as well as the one produced by Zoomify. Besides these, it supports the pyramids of OpenStreetMap, Google Maps (road, terrain and satellite) and many more.
2. Just like in Deep Zoom, you can specify tile overlap⁵ in the OpenZoom description format.
3. Unlike Deep Zoom or Zoomify, the OpenZoom description format also supports non-square image tiles by exposing a tileWidth as well as a tileHeight property. Deep Zoom and Zoomify obviously don’t have to support this as they know that their algorithms don’t produce non-square tiles. The OpenZoom format however, has to accomodate legacy multi-scale image data that has non-square tiles.
4. One thing that surprised me most is the fact that even images on Flickr which are stored in many different dimensions can be put into relationship of an image pyramid. The levels of a Flickr image pyramid are quite irregular compared to Deep Zoom and Zoomify as they are bounded by maximum sidelengths of 100, 240, 500, 1024 and original. Even though it isn’t very efficient since Flickr doesn’t support tiles, images from Flickr can be rendered as multi-scale images inside OpenZoom.

Important Note: Deep Zoom features a powerful concept called Sparse Images not present in any other format known to me. However, I am considering to incorporate this feature into the OpenZoom description format at a later date.

Powerful Addressing Scheme
The description format again makes minimal assumptions about the location of the image tiles. Only the following two conditions have to be met: Tiles have to be addressable by their column and row in a cartesian or rectangular coordinate system. The client then simply applies string substitution to the reserved tokens {row} and {column} and replaces them with coordinates that have a range of [0, numRows) or [0, numColumns) respectively. The upper bounds numRows and numColumns are specified on the corresponding level element.

Important to note is that unlike Zoomify which only seems to support JPEG tiles anyway and Deep Zoom where the extension is specified in the descriptor, the OpenZoom description format makes no assumptions about the file extension of the tiles whatsoever. In the days where server-side scripts with a extensions like .php or .cfm serve us images, it would be negligent to rely on the file type extension. For the client to decide if it can render the images that are being served, the format features a type property on the pyramid element that specifies the mime type of the tiles.

Exceptions: Obviously, no matter how powerful a design is, there are always things it can't handle. For the OpenZoom description format this means sources such as Microsoft's Virtual Earth or the GigaPan project which both feature a quadtree-based addressing scheme. That the OpenZoom description format cannot describe these kinds of sources doesn't mean the OpenZoom framework can't render them. However, doing that involves some amount of code which in the case of OpenZoom would mean to implement the IMultiScaleImageDescriptor interface. For Silverlight Deep Zoom that would be the abstract MultiScaleTileSource class.

Support for Multiple URLs
As you may know, most current browsers are limited to 2 concurrent requests per domain. Therefore, the OpenZoom description format has support for defining multiple URLs for the same data. A client which supports the format is then able to concurrently fetch more than 2 image tiles at the same time. This technique is applied by most large map providers such as Google Maps and Microsoft Virtual Earth.

Example

…
<level index="11" width="524288" height="524288" columns="2048" rows="2048">
  <uri template="http://t0.foo.com/11/{column}/{row}.png"/>
  <uri template="http://t1.foo.com/11/{column}/{row}.png"/>
  <uri template="http://t2.foo.com/11/{column}/{row}.png"/>
  <uri template="http://t3.foo.com/11/{column}/{row}.png"/>
</level>
…

Ease of Implementation
Since the OpenZoom description format is very explicit (and therefore verbose), implementing a client to read it is very, very simple. Unlike Deep Zoom and Zoomify where the client has to do a considerable amount of work to compute the properties of the image pyramid, with the OpenZoom description format this work basically boils down to mapping the properties of the descriptor into the internal representation of a multi-scale image description.

In my opinion, the single biggest advantage of the OpenZoom description format is that a client that can read the format does not need to understand the algorithms that created the image pyramids which the format itself describes. This way we can totally decouple the producer of an image pyramid from its ultimate client.

If you are interested in getting an idea of how all of this works, I suggest you take a look at the following classes in the OpenZoom source code repository: ZoomifyDescriptor, DZIDescriptor and OpenZoomDescriptor.

Conclusion

I hope this overview of the three multi-scale image description formats gave you an idea on what problems each one of them is trying to solve and how well they succeed in doing that. When designing the OpenZoom description format, my intention was certainly not to create yet another description format. It simply tackles the issues of multi-scale image formats from a different angle. Doing that, it turned out to be quite powerful in representing all kinds of multi-scale images out there, including the two big ones: Deep Zoom and Zoomify. More importantly, the OpenZoom description format offers a way to describe a vast amount of all multi-scale image out there under a single specification.

That being said, the OpenZoom framework itself, which strives to be the most open, most flexible platform for multi-scale images and Zoomable User Interfaces out there, obviously supports all of the formats discussed here equally well.

I hope you've enjoyed this behind the scenes of the OpenZoom description format. At some point, I will show you an idea I've been working that involves these multi-scale image descriptors. Until then, have a look at the links in the Further Reading section as there are some hidden gems.

Disclaimer: All details of the OpenZoom description format are subject to change. Feature requests and opinions are welcome. As usual, feel free to leave a comment.

Acknowledgement

At this point, I'd like to thank my buddy Boris who unbeknownst to him, through our many very valuable discussions, considerably shaped the current form of the OpenZoom description format specification. Believe me when I say that without him the format would have most certainly been YAMSIDF.

Footnotes

[1 & 3] If you’d like to get some more background on this topic, I wrote an introduction to multi-scale imaging and another article about the mathematical properties of an image pyramid using Microsoft’s Deep Zoom as an example.

[2] From my own experience, I know that there are unfortunately still people out there who think that there is some magic going on behind multi-scale imaging. To set this straight, if you’ve used any of the following, Google Maps, Yahoo Maps, Microsoft Virtual Earth, Silverlight Deep Zoom, Seadragon AJAX, Seadragon Mobile or Zoomify,⁴ you should know that all of them basically work the same, namely with off the shelf JPEG or PNG image files. These files are stored either on disk or in a database. Once requested, they are sent to and rendered on the client which in the previous examples is either the browser, the Flash or Silverlight plugin or the iPhone.
But you might ask: What about JPEG 2000? Indeed, there are some possible candidates for image file formats out there which would bring better support for multi-scale imaging in the future. Two of them being JPEG 2000 and HD Photo. We won’t see significant adoption of the first anytime soon because of legal issues such as this one. HD Photo originated at Microsoft and is being considered as successor to the JPEG standard dubbed JPEG XR. Again, widespread use won’t happen overnight.

[4] By the way, OpenZoom supports most of these out of the box.

[5] In Inside Deep Zoom 2 I’ve explained the concept of tile overlap.

Further Reading

• Wikipedia: JPEG 2000
• Wikipedia: HD Photo
• HD Photo (formerly Windows Media Photo) vs JPEG 2000
• Photosynth —Bill Crow gives us an excellent behind the scenes of an early preview of Photosynth and how it leverages HD Photo.
• Microsoft MSDN: Deep Zoom File Format Overview
• Dragonosticism: DeepZoomTools.dll — Develop your own tools for creating Deep Zoom images.
• Viewing Large Images – OpenLayers, GSIV, ModestMaps, DeepZoom, and Python — Create Deep Zoom Images on Windows, Mac and Linux with Python and PIL.
• Enter the Seadragon — Introduction to Seadragon and multi-scale imaging.
• Seadragon On Your iPhone — The story of Seadragon Mobile by Ian Gilman, one of the Seadragon team members.
• Seadragon AJAX & Deep Zoom — Comparison of the two implementations by Lutz Gerhard, a LiveLabs product manager.
• Zoomifyer EZ — Create Zoomify images for free on your Mac and PC.
• Zoomify Photoshop — Create Zoomify images with Adobe Photoshop.

Today I’d like to share with you a first preview of the MultiScaleImage component that I’ve built on top of the OpenZoom SDK.

Introducing the OpenZoom SDK

This stuff is really old and is only kept around here for archival purposes. Get the latest news and the first public release of the OpenZoom SDK in the official announcement.

Nomen Est Omen

MultiScaleImage? Sounds familiar? Well indeed, it is the same name Microsoft uses for their Deep Zoom Silverlight control. In spirit, the Flex MultiScaleImage component I’ve built and its Silverlight counterpart are very close. How close? Well, let’s look at a fictional code listing:

Code: Silverlight vs Flex

Microsoft Silverlight

 
<MultiScaleImage x:Name="image" Source="foo/bar.xml"/>

Adobe Flex

 
<openzoom:MultiScaleImage id="image" source="foo/bar.xml"/>

Under the Hood

As much as the two look alike from the outside, they differ very much under the hood. Microsoft’s MultiScaleImage control is a native control of the Silverlight runtime and therefore has a very efficient implementation. On the contrary, the Flex MultiScaleImage component is built on top of ActionScript 3. Nonetheless, I am very pleased with the performance, considering I haven’t spent much time on tuning it yet.

Even though I can praise Microsoft for their Deep Zoom implementation, I dare to say they didn’t do their homework on API design. Shortly after Deep Zoom was introduced to the public with the fantastic Hard Rock Memorabilia showcase by Vertigo, dozens of bloggers wrote posts about how to program the Silverlight MultiScaleImage control to create something that somewhat comes close to the Hard Rock site. It was hard because the API is cumbersome and confusing. I’d speculate this is one of the reasons we haven’t seen a lot more inspiring Deep Zoom work since.

Flexibility, a powerful API and ease of use were the top priorities for my implementation of the MultiScaleImage component for Flex. Whether I’ve achieved my goals, I am eagerly waiting to hear from you.

Batteries Included

As the title of the article suggests, the Flex MultiScaleImage component has built-in support for Deep Zoom images. But not only that, it also comes with native support for Zoomify and OpenZoom images without you having to write one line of code. The latter is a new multi-scale image description format I’ve designed and will probably discuss another time.

To keep things clear, there is one thing that the Silverlight MultiScaleImage control supports that I do not (yet) support: Collections. Personally, I think this is one of the cases where it’s misleading that a MultiScaleImage (singular!) supports collections of images and suddenly has subimages. Therefore, once this functionality will be part of the OpenZoom SDK, it most certainly will have its own component.

In order to prevent a similiar incident to Silverlight’s introduction of their MultiScaleImage component where bloggers around the world had to write how to add mouse and keyboard navigation to Deep Zoom, I’ve architected the Flex component in a way that has plug & play support for this kind of functionality which is a nice application of the Strategy Pattern.

Getting Started

I could go on and on about how the Flex MultiScaleImage component works but instead I’ve prepared three demos that let you interactively explore the three core concepts of the component, namely transformers, controllers and constraints.

Demo #1: Transformers

The transformer controls the animation of the viewport. Currently, I’ve implemented one controller, TweenerTransformer, that is based on the fantastic Tweener animation library. Check out the demo to see how flexible the architecture is and how easily you can customize the animation of MultiScaleImage. You want to know what’s also great about transformers? If for whatever reason you don’t need them, you don’t pay a single kilobyte penalty for an animation library that is never used.

View Demo | View Source

Demo #2: Controllers

Controllers are the glue between user input and viewport control. The OpenZoom SDK features two implementations of controllers at this point, namely a MouseController and a KeyboardController. Both have already built-in support for quite some customization but if you need more, feel free to implement your own controller based on IViewportController.

View Demo | View Source

Demo #3: Constraints

The constraint controls what states the viewport can reach. Don’t want people to zoom out too much? Just add a ZoomConstraint and set minimum and maximum zoom. Don’t want them to lose the scene out of sight? Add a VisibilityConstraint. Doesn’t the component only support a single constraint? Yes, but the architecture is flexible enough to allow you to combine constraints in a CompositeConstraint which is an application of the Composite Design Pattern.

View Demo | View Source

Demo #3½: Out of the Box

After having experienced all the advanced features of the component, let’s sit back and enjoy the elegance and purity of the MultiScaleImage component as it comes out of the box. In its plain form, a MultiScaleImage has only one purpose: Displaying images tack sharp no matter how big they appear on the screen. Try for yourself, click on the picture to go to the demo and there just keep on resizing your browser window and enjoy the beauty of simplicity how the image slowly appears sharper and sharper.

View Demo | View Source

Download

If you’d like to play around with this component, please download the OpenZoom SDK (ZIP). If you want to find out more, I recommend you to read the OpenZoom SDK API documentation and if you feel particularly adventureous, take a look at the source code.

In case you have questions, feedback or you’ve found a bug, feel free to leave a comment down below or file a bug report at the OpenZoom Bug Tracking System.

Today, I’ve barely scratched the surface of what’s possible with the OpenZoom Flex MultiScaleImage component. In case you have suggestions for topics you would like me to talk more about, again, just leave a comment and I’ll see what I can do.

I can’t wait to see what you create with it. If you have a demo with the MultiScaleImage component, post a comment with a link to your demo.

Disclaimer

This is a preview release. Performance has not been optimized yet. All parts of the component, in particular the API are subject to change.

License

The OpenZoom SDK is licensed under the MPL 1.1/GPL 3/LGPL 3 trilicense.

History

As the previous articles and the title of this one already hinted it, I did implement Deep Zoom in Adobe Flash. The viewer I’ve built reads standard, unmodified Deep Zoom images directly from Deep Zoom Composer. It turns out, the idea was born when I was doing my internship at Zoomorama and I was tasked to work on multi-scale image rendering. One night at my apartment, I was taking a closer look at Deep Zoom and realized that it works quite similarly and could be easily implemented on top of the work we did at Zoomorama. The very next day, I talked to our people about it and their reaction was very positive. Another twenty-four hours later, I had a working proof-of-concept for rendering Deep Zoom images inside our own viewer. At this point, I'd like to thank my incredible developer teammates David, Olivier & Eric for being part of making this possible.

Deep Zoom in Flash

What you are about to see, is one set of original Deep Zoom images (fresh out of Deep Zoom Composer) that runs both inside Flash as well as Silverlight. Going into all the implementation details and the implications of this will probably warrant another blog post. However, I think it's interesting to note that with the work I did, we now have a working solution for creating the same kind of experiences Deep Zoom enables on Microsoft Silverlight, but instead running on Adobe Flash.

What does this mean? First, the reach you get with Flash is massively bigger than what you get with Silverlight. Think about it, when Silverlight 2 ships tomorrow it's market share starts at basically zero. Considering that Flash player 9 has something close to 98% market penetration, this is a big deal.

On a side note, if I wouldn't be kept busy with all these ETH projects, Deep Zoom would have been out for weeks before the official launch of Silverlight 2 on a platform that is mature and has an order of magnitude higher reach.

Second, unlike Deep Zoom in Silverlight, Deep Zoom in Flash doesn't crash Firefox on my Mac. Enough said, see for yourself.

Navigation

Click to zoom in and shift-click to zoom out on the picture. Drag & drop to pan. The Flash viewer supports fullscreen mode with the keyboard shortcut F or by right-clicking and choosing Fullscreen in the context menu. Other ways to navigate are also found in the context menu.

Sample #1 – Mont Saint Michel

View in Flash | View in Silverlight Deep Zoom | View Original Image

Sample #2 – Billions

View in Flash | View in Silverlight Deep Zoom | View Original Image

Sample #3 – Deux Femmes

View in Flash | View in Silverlight Deep Zoom | View Original Image

Addendum

The Flash viewer for viewing Deep Zoom images is still work in progress and therefore you might experience certain jerkiness when navigating around. It is based on a codebase I wrote from the ground up. So far in this blog, I've not only written about things I experimented with but usually also released the source code that goes along with it. This should not be an exception, however, the code is not ready for public consumption and therefore I kindly ask you to keep an eye on this blog for future announcements.

Although I agree mostly with the statement that Silverlight Deep Zoom is Nothing New for Flash (one could go one step further by saying Silverlight Deep Zoom is Nothing New), I must give credits to the Seadragon team for their innovative & engaging implementation that revived the interest in zooming as a very powerful concept.

Even though the Adobe Flash Platform is still my preferred development platform, I am very happy about the competition Microsoft brought with Silverlight or Sun, Apple & Curl with their respective RIA technologies. I realized this more then ever when I compared Silverlight Deep Zoom to my own implementation on top of the Flash Player. Therefore, I'd like to take this opportunity to petition Adobe for the following two matters:

Adobe Petition #1:
Native Mouse Wheel Support on Mac OS X

Adobe touts the Flash Player as leading example for a cross-platform development environment. According to this article by Ted Patrick, an Adobe Evangelist, cross-platform is defined as follows:

Across operating systems and web browsers:

• Identical APIs (classes, methods, properties, types, and return values)
• Identical API behavior
• Similar performance
• Similar installation experience

As long as we don't have multi-touch screens available everywhere, the mouse wheel or scrolling is one of the most powerful input gestures for Zoomable User Interfaces.

It's 2008 and the Flash Player still does not allow you to natively listen for mouse wheel events on the Macintosh. Adobe, please fix this glitch.

Adobe Petition #2:
Support for a Background Thread

As you play around with the Deep Zoom samples in Flash you'll sometimes notice jerkiness in the zooming and panning while the movement should be very smooth. Although there is still a lot of room for optimization that can be done on my part, from my observations, the root cause that is responsible for this jerkiness is when the Flash Player is handling network traffic (when fetching tiles) and doing zooming or panning animations at the same time.

From my research I've gathered that Microsoft's Silverlight supports Background Workers, a way to run time-consuming tasks on a background thread. I believe a similar mechanism on the Flash Player would allow me to handle network traffic on a background thread while the UI smoothly animates. This is an advanced feature but the Flash Platform is slowly maturing and exposing such mechanisms to developers has to considered.

Photography

The photos Mont Saint Michel, Billions & Deux Femmes were all taken by me. If you'd like to see more, I suggest you to check out my Flickr stream. All three photos are published under a Creative Commons Attribution-Noncommercial-No Derivative Works license.