I want my seadragons in HD!!!

  • 2
  • Question
  • Updated 10 years ago
  • Answered
Will there be support for the .wdp HD Image format that is being created with Image Composition Editior?
Photo of Andy Close

Andy Close

  • 1 Post
  • 0 Reply Likes
  • seeking answers

Posted 10 years ago

  • 2
Photo of Aseem Kishore

Aseem Kishore, Former Employee

  • 702 Posts
  • 124 Reply Likes
Well the good news is that IE9 supports HD Photo (whose new name is JPEG XR btw -- it was accepted as an international standard!) -- see this test page for example. If other browsers start to support it, then we may be able to support it in Seadragon Ajax.

Hopefully Silverlight will eventually support it too, which will mean Deep Zoom in Silverlight will work with it too. But we don't know if they will support it yet.
Photo of Nathanael Lawrence

Nathanael Lawrence

  • 795 Posts
  • 55 Reply Likes
Aseem, it looks to me like JPEG XR support means that each DZI should be smaller, being that it appears as though it uses something closer to wavelet compression, thus cutting out much of the redundancy that today's JPEG image pyramids contain. Is this correct, or is there not much of a footprint difference between a zipped up DZI (as Photosynth uploads to the server) and a JPEG XR file?

Also, if (or perhaps when?) JPEG XR becomes pervasive will viewers like Seadragon still use DZI extensions or will it simply navigate the JPEG XR file as it sits on the server without the need for it being unzipped already? Will Seadragon still need to perform tiling for JPEG XR's multiple resolutions or is this inherent to JPEG XR's formatting already?

I tend to be a very hardline 'the truth is in the file' sort of fellow, so while I recognise the need for content to be cleanly delineated into its various pieces internally, I don't feel like the end user should ever see any of that and it should be as simple as possible to simply save or copy any piece of media or document. In other words, it's fine with me if a video contains the video stream, the audio stream(s), subtitles, chapter divisions, menus, etc. all as separate files within a video container format, so long as for the end user it simply appears as a single video file that carries everything with it when I save or copy it.

As of now, unless you've got some (admittedly rather basic) coding chops, there's no way to simply download either the entire image pyramid or (more usefully) the highest resolution of a DZI on Photosynth, etc and have the tiles pieced back together with the correct amount of overlap automatically, even though all the information is sitting there in the DZC's XML. Even if I could, quite a lot of the metadata for the original file has been discarded and the information that is actually retained is stored (in Photosynth's case) in the synth's JSON file (and presumably some form of XML in Deep Zoom Composer's and Pivot's cases).

In the AJAX and Deep Zoom implementations of Seadragon with the current JPEG tiles, (and this may be just due to my browser's cache size, though I've increased it before to seemingly not much effect), it often seems as though I have to download the same tiles for the same image multiple times. Whether that is typical behaviour or not, I don't know.

I would love to see with JPEG XR, if I am viewing the image with a beautiful hardware accelerated HTML5 Canvas implementation of Seajax, that all of the pieces of the file which have been downloaded already into the browser's cache would not have to be downloaded again if I decide to save the entire image to the hard drive, but simply be added to, in order to complete the download in much the same manner as a torrent. To me, this would be optimum efficiency. I'm thinking that someone on the Seadragon team must feel the same way, mainly because of your team's choice with Seadragon.com to get people accustomed to having the option to save the original image or document directly next to any zoomable version of the same (though, I understand that in today's Seadragon.com the original file and Seadragon's DZI are completely different documents).

Am I far off as far as the future of using the already downloaded tiles|data to shorten saving the entire image|document?

I suppose that I should ask Daniel directly, but I've seen options in his OpenZoom viewer to save various resolutions of the image that the viewer is currently pointed to. I wonder if he uses any of the tiles that have downloaded to the machine already or if the image is simply compiled server-side and sent down to the client.