Loading Profile...
How Do I Prevent Loading of Very Small Deep Zoom Tiles?
Daniel,
I've noticed that when using DeepZoom derived descriptors that Openzoom loads many seemingly unnecessary image levels at resolutions far smaller than the viewport dimensions -- the 1x1, 2x2, etc. pixel versions from the DZI pyramid.
This seems odd to me, but would be more of a curiosity if it weren't creating a big impact on certain aspects of our product. When we try to scale a 25,000 x 330,000 pixel image down to 1x2 or something, even with the magic of JPEG2000, my on-the-fly tile cutter chokes.
My custom descriptor, which implements IMultiScaleImageBase, implements the getMinLevelForSize method.
getMinLevelForSize returns the right level for the viewport, but lower levels are also queried. This uses bandwidth in all situations (I noticed the same behavior in your NYTimes inline image replacement demo), but also chokes my build process. It would seem that getMinLevelForSize ought to be setting the floor for the MultiScaleImageLevel to return.
My temporary hack may be to disable the image cutter when both requested dimensions are < 10px and return a blank image... but it would be nicer to know if there's a way to stop the client code from requesting these seemingly unneeded levels.
Thanks again!
-christian
I've noticed that when using DeepZoom derived descriptors that Openzoom loads many seemingly unnecessary image levels at resolutions far smaller than the viewport dimensions -- the 1x1, 2x2, etc. pixel versions from the DZI pyramid.
This seems odd to me, but would be more of a curiosity if it weren't creating a big impact on certain aspects of our product. When we try to scale a 25,000 x 330,000 pixel image down to 1x2 or something, even with the magic of JPEG2000, my on-the-fly tile cutter chokes.
My custom descriptor, which implements IMultiScaleImageBase, implements the getMinLevelForSize method.
getMinLevelForSize returns the right level for the viewport, but lower levels are also queried. This uses bandwidth in all situations (I noticed the same behavior in your NYTimes inline image replacement demo), but also chokes my build process. It would seem that getMinLevelForSize ought to be setting the floor for the MultiScaleImageLevel to return.
My temporary hack may be to disable the image cutter when both requested dimensions are < 10px and return a blank image... but it would be nicer to know if there's a way to stop the client code from requesting these seemingly unneeded levels.
Thanks again!
-christian
I’m unsure
1
person has this question
I have this question, too!
Tell me when someone answers.
The more people who ask this question, the more it gets noticed.
The more people who ask this question, the more it gets noticed.
The company marked this question as answered.
The best answers from the company
-
onedanshow,
You're right. With the new rendering architecture, render mode support unfortunately broke. I don't know if and when it'll make it back in.
Cheers,
Daniel
I’m sorry
The company says
this answers the question
-
Christian,
Good observation. There are a couple of reasons why one would like to use those lower level tiles:
Smoothness & Continuity
Until Deep Zoom came along, pretty much every multiscale image technologies had a really choppy user experience, e.g. Zoomify and Google Maps. Tiles were only loaded for the appropriate level causing hard edges between low-resolution tiles and high-resolution tiles. Deep Zoom changed everything as it slowly blends in image pyramid levels from the bottom up until the correct resolution is displayed. Additionally, through the blending, the user has a better feeling for what's going on and how long it approximately will take.
Personally, I really appreciate this newfound smoothness & continuity, e.g. http://openzoom.org/go/neo/.
Collections
Microsoft's Deep Zoom was one of the first multiscale image technologies to not only focus on single, high-resolution images but also on collections of medium to high-resolution images, e.g. Hard Rock Cafe: http://memorabilia.hardrock.com/.
To maximize the efficiency in terms of network requests & storage, Deep Zoom uses a very clever collection file format which happens to rely on the existence of the 1x1, 2x2, etc. tile levels of the Deep Zoom file format. The topic is too deep (no pun intended) to go into here but I strongly suggest you to read more about it, for example on Lutz Gerhard's blog:
http://blogs.msdn.com/lutzg/archive/2...
Believe me, it's a delight once you get it!
On a side note, if you do the math, you'll discover that under lab conditions you'll never load more than 33% by blending from lower levels compared to simply getting the right resolution, see http://gasi.ch/blog/inside-deep-zoom-2
This coupled with the fact that the next release of the OpenZoom SDK will heavily rely on caching means that there's really no reason to deprive your user from the smoothest user experience possible.
The answer to your question whether it's possible to turn off the bottom up image pyramid blending in OpenZoom is yes*. Simply set the renderingMode of MultiScaleImageRenderer to RenderingMode.FAST. I believe I haven't exposed this property on the MultiScaleImage component, so you'll have to do a little bit of digging:
http://code.google.com/p/open-zoom/so...
In terms of your descriptor, don't derive it from DZIDescriptor and make sure level 0 has the lowest dimension you still want to request.
–Daniel
* As it has been quite some time since I've worked on the trunk of the OpenZoom SDK, I am not sure how well this feature is working.
The company says
this answers the question
-
Inappropriate?Christian,
Good observation. There are a couple of reasons why one would like to use those lower level tiles:
Smoothness & Continuity
Until Deep Zoom came along, pretty much every multiscale image technologies had a really choppy user experience, e.g. Zoomify and Google Maps. Tiles were only loaded for the appropriate level causing hard edges between low-resolution tiles and high-resolution tiles. Deep Zoom changed everything as it slowly blends in image pyramid levels from the bottom up until the correct resolution is displayed. Additionally, through the blending, the user has a better feeling for what's going on and how long it approximately will take.
Personally, I really appreciate this newfound smoothness & continuity, e.g. http://openzoom.org/go/neo/.
Collections
Microsoft's Deep Zoom was one of the first multiscale image technologies to not only focus on single, high-resolution images but also on collections of medium to high-resolution images, e.g. Hard Rock Cafe: http://memorabilia.hardrock.com/.
To maximize the efficiency in terms of network requests & storage, Deep Zoom uses a very clever collection file format which happens to rely on the existence of the 1x1, 2x2, etc. tile levels of the Deep Zoom file format. The topic is too deep (no pun intended) to go into here but I strongly suggest you to read more about it, for example on Lutz Gerhard's blog:
http://blogs.msdn.com/lutzg/archive/2...
Believe me, it's a delight once you get it!
On a side note, if you do the math, you'll discover that under lab conditions you'll never load more than 33% by blending from lower levels compared to simply getting the right resolution, see http://gasi.ch/blog/inside-deep-zoom-2
This coupled with the fact that the next release of the OpenZoom SDK will heavily rely on caching means that there's really no reason to deprive your user from the smoothest user experience possible.
The answer to your question whether it's possible to turn off the bottom up image pyramid blending in OpenZoom is yes*. Simply set the renderingMode of MultiScaleImageRenderer to RenderingMode.FAST. I believe I haven't exposed this property on the MultiScaleImage component, so you'll have to do a little bit of digging:
http://code.google.com/p/open-zoom/so...
In terms of your descriptor, don't derive it from DZIDescriptor and make sure level 0 has the lowest dimension you still want to request.
–Daniel
* As it has been quite some time since I've worked on the trunk of the OpenZoom SDK, I am not sure how well this feature is working.
The company says
this answers the question
-
Inappropriate?Awesome. Setting RenderingMode.FAST did the trick. On one particular image setting it to SMOOTH downloads 48 image slices, while FAST downloads 9.
For most of our images, the change in "smoothness" of the zoom isn't very noticeable, and I (and I'm guessing our users) would prefer the increase in performance and reliability of the servers.
When the neo branch is closer to production I'll have to revisit this.
Thanks again Daniel.
-c
I’m thankful
-
Inappropriate?Glad it worked! :)
Considering your scenario, I will make sure to again include a RenderMode.FAST option in the neorenderer branch.
Cheers,
Daniel
P.S. In terms of good compromise between performance & smoothness, consider following the Zoomify image format which breaks down the original image into levels & tiles until it completely fits onto one tile. This will ensure that the image will always blend in as a whole.
I’m happy
-
Inappropriate?Is there still a way to do this? The RenderMode constants are still in the SDK, but they are not used anywhere and MultiScaleImageRenderer no longer exists. I assume this functionality would be in ImagePyramidRenderer now, but I don't see an equivalent.
I’m sad if this is gone
-
Inappropriate?onedanshow,
You're right. With the new rendering architecture, render mode support unfortunately broke. I don't know if and when it'll make it back in.
Cheers,
Daniel
I’m sorry
The company says
this answers the question
EMPLOYEE
