Viewport Repositioning Problem When Zooming
Hi Daniel,
I'm still working on my custom "eSlide viewer" and I still have a viewport repositioning problem when I go deeper in zoom, as I wrote in the last part of a previous post:
http://getsatisfaction.com/openzoom/t...
I'd like to submit this problem another time, so we could focus on it in order to obtain a solution.
I'm still developing using Adobe Flex Builder 3 and Openzoom SDK 0.4.2.1.
My goal is to handle big, rectangular images based on rectangular tiles. This is an important point in my work because I should handle pre-made images sets that have different zoom levels which are not exactly one half of the previous one (e.g. greater zoom - saying 40X - have 13x10 tiles, 20x have 7x5 tiles, 10x 4x3 tiles, 5x 2x2 tiles, 2.5x 1x1 tiles - it means that the second level of zoom has ceil(first level of zoom/2) tiles). The images' set is fully described in a RDF file called "caseInfo.RDF", inside images' set. My viewer points to this file in order to take all the properties needed by MultiscaleImage. The point of that kind of acquisition is flexibility (should work with every image) and efficiency (to minimize white - not useful - number of tiles). Everything seems to meet requirements of openzoom descriptor
http://gasi.ch/blog/openzoom-descript...
that's why I can't understand the behaviour that I'll post now.
This is the image that I obtain by clicking "load" button (after inserting set's descriptor). The MultiscaleImage is contained in a Canvas (in this case is a test one - 400x300 pixels). I don't know why the MultiscaleImage doesn't fill the canvas, any advice to solve this?
In this second image I clicked in the center of the blue canvas and I obtained this zoom that seems to be consistent, looking at the "image position" canvas (the red one in the preview).
Other little problem. This "image position" canvas seems to behave well, but hasn't the right image proportions (as you can see in the image, is quite square, not rectangular), probabily I have to fix something in transformWindow() function (I integrated SceneNavigator in the .mxml file)
This third image is obtained by clicking in the center of the blue canvas and here the problem is clear. As you can see the "image position" canvas (red one) and the part of MultiscaleImage shown, don't correspond anymore. This level of zoom is 10x, that means 4x3 tiles (the other two were 2.5x - 1x1 tiles and 5x - 2x2 tiles). I should say that when I clicked on previous image, the MultiscaleImage was "going deeper" in zoom in the right way and then the viewport was repositioned in the wrong way.
I can post another image that still shows the problem
Taking a look at openzoom library I found the following lines of code in ImagePyramidRenderManager.as (lines 260-263)
// FIXME: Currently center, calculate true origin
var t:Point = new Point(0.5, 0.5)
var origin:Point = new Point((1 - t.x) * fromTile.x + t.x * toTile.x,
(1 - t.y) * fromTile.y + t.y * toTile.y)
could this code be related with the viewport repositioning problem? I understand that this code re-sets the origin of the viewport on its center at every time/zoom level considered - am I right?
If you like to try my code, I posted my prototype on google code:
http://code.google.com/p/eslide-viewe...
In google code you can find also the images' set ("testTesi.zip" - in download section) of the images I posted.
Last question. Is there any working example of viewers fully based on openzoom descriptor?
Sorry for the length of this post, but I want to give as much details as I can, to make the problem clear.
Cheers,
David
I'm still working on my custom "eSlide viewer" and I still have a viewport repositioning problem when I go deeper in zoom, as I wrote in the last part of a previous post:
http://getsatisfaction.com/openzoom/t...
I'd like to submit this problem another time, so we could focus on it in order to obtain a solution.
I'm still developing using Adobe Flex Builder 3 and Openzoom SDK 0.4.2.1.
My goal is to handle big, rectangular images based on rectangular tiles. This is an important point in my work because I should handle pre-made images sets that have different zoom levels which are not exactly one half of the previous one (e.g. greater zoom - saying 40X - have 13x10 tiles, 20x have 7x5 tiles, 10x 4x3 tiles, 5x 2x2 tiles, 2.5x 1x1 tiles - it means that the second level of zoom has ceil(first level of zoom/2) tiles). The images' set is fully described in a RDF file called "caseInfo.RDF", inside images' set. My viewer points to this file in order to take all the properties needed by MultiscaleImage. The point of that kind of acquisition is flexibility (should work with every image) and efficiency (to minimize white - not useful - number of tiles). Everything seems to meet requirements of openzoom descriptor
http://gasi.ch/blog/openzoom-descript...
that's why I can't understand the behaviour that I'll post now.
This is the image that I obtain by clicking "load" button (after inserting set's descriptor). The MultiscaleImage is contained in a Canvas (in this case is a test one - 400x300 pixels). I don't know why the MultiscaleImage doesn't fill the canvas, any advice to solve this?
In this second image I clicked in the center of the blue canvas and I obtained this zoom that seems to be consistent, looking at the "image position" canvas (the red one in the preview).
Other little problem. This "image position" canvas seems to behave well, but hasn't the right image proportions (as you can see in the image, is quite square, not rectangular), probabily I have to fix something in transformWindow() function (I integrated SceneNavigator in the .mxml file)
This third image is obtained by clicking in the center of the blue canvas and here the problem is clear. As you can see the "image position" canvas (red one) and the part of MultiscaleImage shown, don't correspond anymore. This level of zoom is 10x, that means 4x3 tiles (the other two were 2.5x - 1x1 tiles and 5x - 2x2 tiles). I should say that when I clicked on previous image, the MultiscaleImage was "going deeper" in zoom in the right way and then the viewport was repositioned in the wrong way.
I can post another image that still shows the problem
Taking a look at openzoom library I found the following lines of code in ImagePyramidRenderManager.as (lines 260-263)
// FIXME: Currently center, calculate true origin
var t:Point = new Point(0.5, 0.5)
var origin:Point = new Point((1 - t.x) * fromTile.x + t.x * toTile.x,
(1 - t.y) * fromTile.y + t.y * toTile.y)
could this code be related with the viewport repositioning problem? I understand that this code re-sets the origin of the viewport on its center at every time/zoom level considered - am I right?
If you like to try my code, I posted my prototype on google code:
http://code.google.com/p/eslide-viewe...
In google code you can find also the images' set ("testTesi.zip" - in download section) of the images I posted.
Last question. Is there any working example of viewers fully based on openzoom descriptor?
Sorry for the length of this post, but I want to give as much details as I can, to make the problem clear.
Cheers,
David
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 thinks this is not a problem.
The best solution from the company
-
David,
To keep it short: I still recommend to develop your own descriptor which can represent an image pyramid from reading your caseInfo.RDF file.
Regarding the viewport repositioning problem: I strongly doubt it's a bug but much more likely that your image pyramid data is inconsistent. If I remember correctly I've come to the same conclusion last time. Basically, try to assemble your different levels (20x, 10x, 5x, etc.) manually in Photoshop and see whether your images actually consistently overlap between different levels.
The reason why I'm so confident that this isn't a bug is because the SDK has been out for many months and tested by many, many people and none of the issues that came up had anything to do with viewport repositioning.
Please try the two things I've proposed and let me know what you found out.
Cheers,
Daniel
P.S. Unfortunately, I can't help you with this as I currently don't have working test environment.
The company says
this solves the problem
-
Inappropriate?David,
To keep it short: I still recommend to develop your own descriptor which can represent an image pyramid from reading your caseInfo.RDF file.
Regarding the viewport repositioning problem: I strongly doubt it's a bug but much more likely that your image pyramid data is inconsistent. If I remember correctly I've come to the same conclusion last time. Basically, try to assemble your different levels (20x, 10x, 5x, etc.) manually in Photoshop and see whether your images actually consistently overlap between different levels.
The reason why I'm so confident that this isn't a bug is because the SDK has been out for many months and tested by many, many people and none of the issues that came up had anything to do with viewport repositioning.
Please try the two things I've proposed and let me know what you found out.
Cheers,
Daniel
P.S. Unfortunately, I can't help you with this as I currently don't have working test environment.
The company says
this solves the problem
-
Inappropriate?Hey Daniel!!
I tested my viewer with a test images' set and it seems to work correctly. My descriptor was ok, and it creates the right levels. I was also almost sure that the problem wasn't in the library, but you know... in debugging phase I have to consider every possibility.
I have just a little question about the MultiscaleImage, and I hope that will be the answer to my problem. Is it possible to make the MultiscaleImage fill its canvas?

I mean is it possible to avoid those blank parts (signed by arrows) when the MultiscaleImage is loaded?
Testing the viewer, the "image position" canvas (red one in the preview) is repositioning in the center of the preview if I click on the black spot instead of the blue one (that is the real image center). That's seems a little weird to me and I want to understand what and where I am probabily doing wrong.

That's the effect of clicking the blue spot.
Thanks for your help, I hope to have the right inspiration to completely fix it, I'm impatient to share my work! ;)
David
I’m confident
-
Inappropriate?David,
At this point I'd like to thank you for always providing these well-written descriptions and insightful illustrations & screenshots. This definitely makes my job much easier.
Filling the Viewport
By default, OpenZoom always fits your entire image into the viewport which can cause blank areas around it. If you want to avoid this you basically have two options:
1.) If you're source image aspect ratios are all the same, simply set the components dimensions to the same aspect ratio.
2.) Try to apply a FillConstraint to your MultiScaleImage.
Repositioning Problem
Although you've described it quite clearly, to getter a better picture I need to ask you to put a functioning example online that illustrates this problem.
Looking forward to seeing your end result!
Thanks,
Daniel
-
Inappropriate?Daniel,
I'm really close to the solution!! Thanks for your advices. Unfortunately the FillConstraint doesn't work as I expected (I still see some blank space and I see only a part of MultiscaleImage, instead of the whole image, so I prefer to not use it), but... I have great news! I think that I found the problem in repositioning the viewport!
Well, it wasn't really a problem of viewport repositioning, but it was related with the use of "clamp" in "transformWindow()" where the position and dimension of image position canvas is defined. So I erased all "clamps" from the function and I obtained something like the following images:



As you can see the "position" canvas is going over the preview image, but the most important thing is that is representig exactly the Multiscaleimage shown.
At the end we were both right about our works, hehe.
At least now I'm sure that I'm on the right way, and I think that I could fix it almost easily.
Thanks for all the support you gave me, I hope to put my viewer online as soon as possible!
Cheers,
David
I’m happy
-
Inappropriate?Daniel,
maybe I celebrated too early... Everything seem to work, but only with the two image sets that I've tested (that are perfect copies).
Trying the viewer with another set, it still give me the "repositioning" problem.
Now I'll try to understand if the problem is in image's set or somewhere else. I'll keep you updated.
Regards,
David
I’m confident
-
Inappropriate?Hey Daniel!
Just an update about my debug. Testing another images' set I observed an interesting behaviour. Working with a particular dimension of the multiscaleImage canvas, it seems that everything works perfectly with zoom in and out. Changing the multiscale image canvas (even keeping proportions) give me my "well-known" problem of repositioning. But now I understood that is not a real repositioning problem, but it is a "level" problem. I mean: going deep in zoom, after a couple of click (normally 2 or 3) the level shown is no more consistent with the number of click given. It means that it makes a "jump" between image pyramid levels, passing for instance from level 2 to level 4 without stopping at level 3, and obviuosly showing something completely different from the expected.
It makes me also think that there's a connection between the canvas that contain a multiscale image and the level of the pyramid shown, is it right?
Is there a way to "hook" the number of click given to the multiscale image with the level shown (if it really makes sense...)?
Obviously my objective is to show an arbitrary multiscale image contained in an arbitrary canvas, and its preview and position canvas should ever be consistent.
I'm pretty sure that this is a really little problem, easy to fix if I knew where to fix, hehe.
Thanks for your help,
regards,
David
I’m confident
-
Inappropriate?David,
Basic question: Does your image pyramid show the same image on every level like a photography or are there changes in between levels like in maps?
–Daniel -
Inappropriate?Daniel,
answering your question: my image pyramid behaves like maps. It changes levels and so on. But I have some news and I can update you.
First of all I tried to take another path so I used a Zoomify set. Testing some zoomify sets, the viewer works great: precise, fast and the tile loading is really hard to see, looking at the picture. Anyway this could be ok for a presentation, but it isn't my objective mainly because of difficulty to obtain a decent zoomify set and obviously the limitation to only use square 256x256 tiles.
Today I've taken in hands my original project another time and testing it with reduced sets I've noticed that it seems to work if I force the various levels to have a number of tiles that is power of 2. I remember to have read something similar in older posts where you told that every level should have a dimension (number of row and columns) exactly double of its precedent. Obviously it doesn't mean power of two, but if this rule is applied starting from the level that contains only one tile, the dimension "power of two" is the only solution.
Giving you a real example, I tested it with a set of images with 5 levels:
"5x" (14x13) //rowsxcolumns
"2.5x" (7x7)
"1.25x" (4x4)
"0.625x" (2x2)
"0.3125x" (1x1)
that is the original set (reduced) and the problems started when the zoom went to the level with 7x7 tiles. Using the same set, but with number of tiles "power of two" that it means
"5x" (16x16) //rowsxcolumns
"2.5x" (8x8)
"1.25x" (4x4)
"0.625x" (2x2)
"0.3125x" (1x1)
it works perfectly.
The rule used to determine the number of tiles in sets that I have in my hands is
columns (of level n) = ceil(columns(of level n+1) / 2)
rows (of level n) = ceil(rows(of level n+1) / 2)
These were chosen in order to minimize the number of "white tiles" for each level (and obviously the waste of disk space for every set).
I also noticed that the creation of my sets implies a "top-down" strategy (starting from the biggest level and going down to the smallest one, using the rules that I've written at every step) and openzoom seems to reconstruct the image in a "bottom-up" way (starting from the level with 1 row/column and doubling the number of rows/columns at every step), obviously giving an unexpected result.
I think that if I could make openzoom "understand" these rules, my viewer will work properly. The only problem is to know how... hehe
I hope that the problem is well explained and understandable.
Thanks another time for your help, I'm sure that we will find a solution!
Cheers
David
-
Inappropriate?Daniel,
I think I made it! The problem was in pyramid levels creation and was related to the number of columns/rows that must be (for each level) exactly double of its predecessor.
I solved it with a "trick" creating pyramid levels of "expected dimension" even if the tiles that should complete the level aren't present and voilà! It works!
Thanks for all the support you gave me and for your infinite patience :)
I will post the link to the viewer as soon as possible, so finally you can see my work!
Cheers,
David
I’m excited
Loading Profile...




EMPLOYEE