Loading Profile...
OpenZoomDescriptor Broken
Hi Daniel. I'm trying to use the OpenZoom viewer with Picasa. However, I can't seem to understand how OpenZoomDescriptor.parseXML() works, specifically the "parse sources" section, as I can't find any reference to sources in your description of the file format.
Is the implementation complete? I'm using the neorenderer branch of the SDK.
Many thanks for the inspiring work.
Nigel.
Is the implementation complete? I'm using the neorenderer branch of the SDK.
Many thanks for the inspiring work.
Nigel.
I’m confused
1
person has this problem
I have this problem, too!
Tell me when someone solves it.
The more people who report this problem, the more it gets noticed.
The more people who report this problem, the more it gets noticed.
The company marked this problem solved.
The best solutions from the company
-
Nigel,
First of all, I'd like to apologize. You were absolutely right about the OpenZoomDescriptor. It was broken beyond repair due to the many refactorings of the descriptor framework in the neorenderer branch. Although, funny enough it wasn't because of the missing source entries.
I've quickly put together a sample viewer (OpenZoomDescriptorTest.as) and fixed the OpenZoomDescriptor in revision 447:
http://code.google.com/p/open-zoom/so...
I'm looking forward to your results with Picasa. Just remember to be careful about memory usage when using non-tiled image data. It can blow up very quickly.
Cheers,
Daniel
I’m excited
The company says
this solves the problem
-
Nigel,
Thanks for your interest in the OpenZoom project.
First of all, it might help if you could give me more details on what you're trying to achieve:
How exactly do you want to use Picasa with an OpenZoom viewer?
Do you intend to use a tiled image pyramid?
Generally speaking, yes, the OpenZoomDescriptor is feature-complete. However, since you're working with the unstable neorenderer branch, there are no guarantees that everything works as expected ;)
Frankly, I'm a bit ambivalent about the OpenZoom Description Format. Back when I came up with it, it seemed like a nice approach for unifying legacy content. But now, it seems like it's causing more confusion than doing good. I will probably leave the descriptor in the SDK for now but I strongly encourage people to create new content using the Deep Zoom file format (DZI). The Deep Zoom file format has many advantages:
– Broad tooling
(Deep Zoom Composer, DeepZoomTools.dll, Python Deep Zoom Tools, etc.)
– Collection support
– Smooth rendering
– Broad runtime support (Seadragon Ajax, Silverlight Deep Zoom, Seadragon Mobile, OpenZoom, etc.)
Is there anything particular about the OpenZoom Description Format that you would like to take advantage of?
Regarding the parse sources section: Yes, it is indeed used, most prominently in OpenZoom Endo to enable the download of the source images from which the image pyramid was created. However, if I ever get around to do another revision of OpenZoom Endo, I plan to use the Deep Zoom file format and define the sources using XML namespaces within the DZI XML descriptor.
To find out more about it, have a look at my article Inline Multiscale Image Replacement.
As for documentation, the only thing I can offer you is the XML schema definition of the OpenZoom Description Format:
http://code.google.com/p/open-zoom/so...
Looking forward to hear about your OpenZoom/Picasa plans.
–Daniel
The company says
this solves the problem
-
Inappropriate?Nigel,
Thanks for your interest in the OpenZoom project.
First of all, it might help if you could give me more details on what you're trying to achieve:
How exactly do you want to use Picasa with an OpenZoom viewer?
Do you intend to use a tiled image pyramid?
Generally speaking, yes, the OpenZoomDescriptor is feature-complete. However, since you're working with the unstable neorenderer branch, there are no guarantees that everything works as expected ;)
Frankly, I'm a bit ambivalent about the OpenZoom Description Format. Back when I came up with it, it seemed like a nice approach for unifying legacy content. But now, it seems like it's causing more confusion than doing good. I will probably leave the descriptor in the SDK for now but I strongly encourage people to create new content using the Deep Zoom file format (DZI). The Deep Zoom file format has many advantages:
– Broad tooling
(Deep Zoom Composer, DeepZoomTools.dll, Python Deep Zoom Tools, etc.)
– Collection support
– Smooth rendering
– Broad runtime support (Seadragon Ajax, Silverlight Deep Zoom, Seadragon Mobile, OpenZoom, etc.)
Is there anything particular about the OpenZoom Description Format that you would like to take advantage of?
Regarding the parse sources section: Yes, it is indeed used, most prominently in OpenZoom Endo to enable the download of the source images from which the image pyramid was created. However, if I ever get around to do another revision of OpenZoom Endo, I plan to use the Deep Zoom file format and define the sources using XML namespaces within the DZI XML descriptor.
To find out more about it, have a look at my article Inline Multiscale Image Replacement.
As for documentation, the only thing I can offer you is the XML schema definition of the OpenZoom Description Format:
http://code.google.com/p/open-zoom/so...
Looking forward to hear about your OpenZoom/Picasa plans.
–Daniel
The company says
this solves the problem
-
Inappropriate?Hi Daniel. Thanks for the prompt reply to my sleepy question.
I'm interested in using OpenZoom to provide a much more seamless viewing experience for legacy content, such as Picasa or Flickr, as they both provide _untiled_ rectangular image pyramids - hence my interest in the OpenZoomDescriptor.
I was trying to get the flickr.xml descriptor file I found in the SDK to work:
<?xml version="1.0" encoding="UTF-8"?>
<image>
<pyramid type="image/jpeg" height="4083" width="3062">
<level height="100" width="75">
<uri>
</uri></level>
<level height="240" width="180">
<uri>
</uri></level>
<level height="500" width="375">
<uri>
</uri></level>
<level height="1024" width="768">
<uri>
</uri></level>
<level height="4083" width="3062">
<uri>
</uri></level>
</pyramid>
</image>
As it's missing the <source> sections in the example found here it breaks.
As long as the neorenderer still supports arbitrarily-sized rectangular image pyramids, I should be able to roll my own descriptor for my needs.
The Deep Zoom format is elegant, and will be a prime candidate if I decide to convert and cache the legacy images for performance reasons, but I'd initially like to get a prototype working. As the old saying goes, "It's easier to optimise a working system than to get an optimised system to work."
Thanks again,
Nigel.
</source> -
Inappropriate?Nigel,
First of all, I'd like to apologize. You were absolutely right about the OpenZoomDescriptor. It was broken beyond repair due to the many refactorings of the descriptor framework in the neorenderer branch. Although, funny enough it wasn't because of the missing source entries.
I've quickly put together a sample viewer (OpenZoomDescriptorTest.as) and fixed the OpenZoomDescriptor in revision 447:
http://code.google.com/p/open-zoom/so...
I'm looking forward to your results with Picasa. Just remember to be careful about memory usage when using non-tiled image data. It can blow up very quickly.
Cheers,
Daniel
I’m excited
The company says
this solves the problem
-
Inappropriate?Hi Daniel. You're a star!
I went back to the trunk and got a sample working with Picasa - then you reply that neorenderer is fixed and I got that working too.
I tried posting the XML descriptor here, but the URLs got stripped.
Next question: I want to load a sequence of images in quick succession, so speed is essential. To this end, can you make the renderer start loading at the top of the pyramid, regardless of the viewport size? And can you quickly cancel loading when a new image is requested?
Following on from your comment about memory consumption, how can this be tamed if we're loading 100+ images in a rapid sequence?
Many thanks,
Nigel.
I’m excited
-
Inappropriate?Nigel,
Great!
Have you already tried the sequenced loading? As far as I remember, the renderer does indeed start loading the lowest quality level and then moves upwards, giving you this smooth sharpening of the image. I'm not sure though how it reacts if you change the source of the image.
You must know, in the neorenderer branch the MultiScaleImage component has not yet been updated to work with the new rendering architecture, that's why all the example viewers in the root folder have such a tedious setup.
Regarding memory consumption, even though non-tiled images technically work, the cache system was not really designed with such a use case in mind. Currently, the cache works by limiting the number of items (tiles) to, say, 120, but considering that tiles are normally a couple of kilobytes the cache could potentially cause problems with non-tiled images where a tile could be several megabytes. Therefore, as a workaround you can simply lower the cache size which should give you an option control the memory consumption:
http://code.google.com/p/open-zoom/so...
I like that you're experimenting with the OpenZoom SDK. Part of the fun though is that you will have to tweak some things to make it work with your very unique use case.
Can't wait to see what you come up with!
Cheers,
Daniel
-
Inappropriate?Hi Daniel. Thanks for the positive reply again.
I'm looking forward to pushing the system to its limits, and the sequenced loading is the next stage in the prototype. I have to build some client's sites first though.
Thanks for the memory consumption tip.
Best,
Nigel.
I’m excited
EMPLOYEE
