Loading Profile...
checkerboard scaling artifacts
I've noticed that the ajax version of seadragon often displays tiles scaled very slightly from their natural scaling. I'm displaying images with isolated colored pixels on a black background, and when an image like that is scaled to say 1.01 of its natural size, what you see is a checkerboard pattern where some areas are crisp while other areas show two or four dim pixels instead of one bright pixel.
Should seadragon be trying to snap to natural scaling when close? If that's not currently a feature, would it be reasonable to add?
An example is at
http://jdc.math.uwo.ca/tmp/deepzoomte...
where all of the tiles have every 4th pixel on. (While zooming, this of course looks strange, but what I'm talking about is the image that is shown while not zooming.) In case you can't reproduce, I've attached a screen shot.
It's possible that I'm creating the image pyramid incorrectly. If you remove "test.html" from the URL, you can browse the dzi file and the image pyramid and see if it looks ok.
I'm using firefox 3.0.17 on Ubuntu, and I haven't tested images like this with the .NET version.
Thanks for any suggestions!
Should seadragon be trying to snap to natural scaling when close? If that's not currently a feature, would it be reasonable to add?
An example is at
http://jdc.math.uwo.ca/tmp/deepzoomte...
where all of the tiles have every 4th pixel on. (While zooming, this of course looks strange, but what I'm talking about is the image that is shown while not zooming.) In case you can't reproduce, I've attached a screen shot.
It's possible that I'm creating the image pyramid incorrectly. If you remove "test.html" from the URL, you can browse the dzi file and the image pyramid and see if it looks ok.
I'm using firefox 3.0.17 on Ubuntu, and I haven't tested images like this with the .NET version.
Thanks for any suggestions!
2
people have 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 answer from the company
-
Apologies if I'm still misunderstanding, but it seems like you're saying: "if Seadragon detects that the current zoom level is causing tiles to be drawn very close to their natural resolution but not exactly at it, Seadragon should adjust the zoom accordingly."
Assuming that's correct -- and if it's not, feel free to ignore everything below and just let me know -- I think that's a reasonable feature request, and we've thought about it before to varying degrees (it's especially relevant for maps, where the text gets either too big to be useful or too small to read if you're not at "exact levels"), but we haven't dedicated the time to implement it.
It's just been non-trivial to implement because the logic for setting the zoom level (in the Viewport class) is decoupled from the logic for rendering (in the Drawer class), arguably rightly so. For example, you wouldn't want the Drawer to change the Viewport directly during rendering -- that gets a bit messy when you consider the springiness of the Viewport.
I think one approach that would work is for this logic to be in the Viewport directly; whenever you modify the Viewport's zoom level, it could calculate the scale of the image and adjust accordingly. This would add a dependency from the Viewport to the TileSource, but I think that's reasonable in this case. (Right now, the Viewport depends only on the size of the image, not the full set of TileSource properties.)
So if you want to tinker in the code yourself, try that approach. Off the top of my head, you'd want to change the Viewport constructor to take the TileSource instance, then in the zoomTo() method, do the math to figure out what scale the image will be drawn at, and if it's close to an exact power of 2, round the zoom level to make it so.
I hope this helps!
I’m happy to help
The company says
this answers the question
-
Inappropriate?That's just common Moiré pattern... which is not to say that there isn't something that could be done to counter the effect, such as only coming to rest when the current tile layer is onscreen at scale (in fact the Bing Maps Silverlight edition does precisely this - only available on Linux after Moonlight 3 is completed), but it is, to some degree, unavoidable when Seadragon lets you zoom to any arbitrary scale and especially when using the limited blending that is available when using the Javascript implementation.
For more on the differences between Seadragon Ajax and Seadragon Silverlight (Deep Zoom), see:
A Deep Zoom Blog : Seadragon AJAX and Deep Zoom
deepzoom silverlight vs ajax
I’m merely commenting.
-
Inappropriate?Right, but it seems strange to me to come within a few percent of exact scaling but not snap right to the exact scaling. It happens quite regularly, which makes me wonder if there is a minor bug. Or maybe it's just bad luck.
It looks like Seadragon zooms by a factor of two by default, so maybe all that is needed is to ensure that the initial "home" size is a nice zoom level?
Can anyone suggest how to achieve this (even if the user switches to full screen mode)? -
Inappropriate?Hey Dan,
Indeed, astute observation! Seadragon Ajax does choose to always scale down higher-res tiles rather than scale up lower-res tiles.
In general, this leads to better and sharper output, but in cases like yours where the imagery is different per level, it can indeed lead to undesirable results. Since the vast majority of imagery out there and used by Seadragon is the same per level (e.g. regular photographs), we went with our behavior.
We don't unfortunately have a knob or config to tweak that behavior, but that's a reasonable request. I can honestly say we just don't have the resources to do this and ship it anytime soon (I personally am stretched thin already), but hopefully in a future version of Seadragon Ajax we can include this functionality.
If you want to ensure that the initial home zoom is a "nice" zoom level, as you put it, you can definitely do so. Take a look at this thread where Dustin shares equations for translating between "zoom level" and "scale". You could try extending that code to say "given this default home zoom level, give me the zoom level that will render the image at the nearest 'nice' scale", where "nice" means an exact log_2 value, e.g. 1, 0.5, 0.25, 0.125, etc.
I'm sorry that this is a problem for you, and I hope you're able to find a suitable solution or workaround. Do share with us any progress you make, and thanks for understanding! -
Inappropriate?Thanks for the reply, but I'm not sure it exactly answers the question. It's not that I'd prefer scaling up a low-res image to scaling down a high-res image. I'd prefer no scaling at all. It seems that for me seadragon is often very slightly scaling the image data. Even for ordinary photographs, this can lead to bad aliasing, so it would seem to me that if seadragon notices that the desired scaling is very close to exact scaling, it should zoom in or out a tiny bit more so that no scaling is necessary.
I'll be out of town for a little when, but now that you've given me the info I need to try playing with the code (in response to another question of mine), I might be able to figure out how to tweak the code to do this when I get back. I imagine it would improve the image quality for other users as well. It will make a dramatic improvement for me, not because I'm using different data at different levels, but because the images I'm showing have pixel level detail.
Thanks again for being so helpful! It's really appreciated. -
Inappropriate?Ah, so you're saying that even when the image is a "perfect" size (e.g. exactly half resolution, or quarter resolution), Seadragon Ajax is still rendering and scaling the next level, instead of rendering only the exact level it's at?
That sounds like one of those bugs where somewhere in the code is a >= sign instead of just >. =P If you do decide to dive into the code yourself, the file to look at will be Seadragon.Drawer.js. Somewhere in the update() routine, it'll be calculating the levels to iterate over. I would guess the fix would go in there.
If I get some time I'll try to investigate this myself briefly. And no problem, we're glad to help!
-
Inappropriate?Aseem,
No, it's not that seadragon is using an image tile from the wrong level. It's just that it's using an image tile at very close to its natural resolution, but not exactly at its natural resolution. Fixing this should just be a matter of noticing when some number is near 1 and adjusting the zoom level to make it exactly 1. I'll see what I can find when I get a chance to play with the code, but that probably won't happen for a little while. -
Inappropriate?Apologies if I'm still misunderstanding, but it seems like you're saying: "if Seadragon detects that the current zoom level is causing tiles to be drawn very close to their natural resolution but not exactly at it, Seadragon should adjust the zoom accordingly."
Assuming that's correct -- and if it's not, feel free to ignore everything below and just let me know -- I think that's a reasonable feature request, and we've thought about it before to varying degrees (it's especially relevant for maps, where the text gets either too big to be useful or too small to read if you're not at "exact levels"), but we haven't dedicated the time to implement it.
It's just been non-trivial to implement because the logic for setting the zoom level (in the Viewport class) is decoupled from the logic for rendering (in the Drawer class), arguably rightly so. For example, you wouldn't want the Drawer to change the Viewport directly during rendering -- that gets a bit messy when you consider the springiness of the Viewport.
I think one approach that would work is for this logic to be in the Viewport directly; whenever you modify the Viewport's zoom level, it could calculate the scale of the image and adjust accordingly. This would add a dependency from the Viewport to the TileSource, but I think that's reasonable in this case. (Right now, the Viewport depends only on the size of the image, not the full set of TileSource properties.)
So if you want to tinker in the code yourself, try that approach. Off the top of my head, you'd want to change the Viewport constructor to take the TileSource instance, then in the zoomTo() method, do the math to figure out what scale the image will be drawn at, and if it's close to an exact power of 2, round the zoom level to make it so.
I hope this helps!
I’m happy to help
The company says
this answers the question
-
Inappropriate?What you wrote in the first sentence of your most recent comment is exactly what I mean, and your proposed solution sounds like what I expected, although I wasn't aware of the problem of getting the information into the right place. I still hope to have a chance to play with this sometime soon, and will report back here if I do.
Thanks for the tips, as they will save me a lot of time.
EMPLOYEE
