Loading Profile...
To Use or Not to Use OpenZoom?
Hi Daniel,
Let's start with saying I admire your work. I've been playing around (or been poking it, as someone else said;) with the flash examples and I think you did a really great job on structuring the whole thing. I'm really not the most advanced programmer but I can find my way around quite easiliy.
I'm currently working on a project where I need to load some fullscreen high-quality images to show porfolio stuff. but it has to render supersmoothly on both small and really huge screens.. Now i've been testing your API and the tiled loading doesn't really look as smooth as I would have hoped. Now I'm thinking about using it with single-tile images.
But now I'm doubting wheter I'm on the right track using this sytem. because I'm not using the zooming functionality. I only need the smooth loading and fullscreen image (no matter what resolution).
So actually I'm asking your opinion, do you think it still makes sence to use OpenZoom or are there alternative ways you know of, for selective image loading (depending on stagesize) and progressive loading?
Again, I love your work and I'm sure I will use it on projects in the future, but I don't know wheter I should use it now...
Let's start with saying I admire your work. I've been playing around (or been poking it, as someone else said;) with the flash examples and I think you did a really great job on structuring the whole thing. I'm really not the most advanced programmer but I can find my way around quite easiliy.
I'm currently working on a project where I need to load some fullscreen high-quality images to show porfolio stuff. but it has to render supersmoothly on both small and really huge screens.. Now i've been testing your API and the tiled loading doesn't really look as smooth as I would have hoped. Now I'm thinking about using it with single-tile images.
But now I'm doubting wheter I'm on the right track using this sytem. because I'm not using the zooming functionality. I only need the smooth loading and fullscreen image (no matter what resolution).
So actually I'm asking your opinion, do you think it still makes sence to use OpenZoom or are there alternative ways you know of, for selective image loading (depending on stagesize) and progressive loading?
Again, I love your work and I'm sure I will use it on projects in the future, but I don't know wheter I should use it now...
I’m super thankfull
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.
-
Inappropriate?Willem,
Thanks for asking! This is a very good question. I am aware that tile loading and blending is still not perfect – certainly not where I want it to be. As already mentioned, I've started a new branch for the OpenZoom SDK to experiment with new rendering techniques.
What exactly are the issues you're experiencing with tile loading?
In terms of file size, you could certainly use OpenZoom as it really only loads modules (smooth zooming) on a pay-as-you-go basis. But if you really want to go with single-tile images, you might as well build your own component. If that's what you want, I'd suggest you implement a component based on Sprite that reacts to resizing and calculates its screen size with getBounds(stage) and then loads the appropriate bitmap. For the loading part, you may still use bits and pieces from the OpenZoom SDK such as NetworkQueue which is a light-weight alternative to BulkLoader.
In the end, what you choose should be depend on how much time and budget you have and what you requirements you have.
If you have further questions, please ask.
–Daniel
P.S. This is a slightly older example without zooming, just size aware rendering:
http://gasi.ch/examples/2008/12/08/fl...
The newest version from the repository has improved loading and rendering happens from inside out, giving it a much smoother touch.
-
Inappropriate?you're so quick.. but that's not really the first time you hear that i guess;)
Well the thing is, on high resolution (or big stage-size) the tile overlap becomes very visible. especially when reloading the images from cache. When using a smaller stage-size (like 400x400) it renders really smoothly. On 1920x1050 it's not. When using one tile it does.. but then it becomes slow when loading from a server.
Is it not so, that when i render a 1920px image, that ALL the smaller levels are being loaded.. so basically it takes much longer to load a file?
When starting this project i was looking for something like streaming images in Flash, instead i found this methodology.. now i wonder if i'm doing the right thing.. It might just be more then I actually need for this project...
Haha, sometimes you get so exited about some new techniques that you forget all about the purpose..
If you like, i could pm or mail you the link to the tests I'm running. Than you can see what i mean?
Thanks for your help!
Willem
I’m still happy:D
-
Inappropriate?Willem,
What do you exactly mean by «...tile overlap becomes very visible»? Are you talking about the 1px tile overlap thing or the tiling in general? The 1px shouldn't be a problem really. As for the tiling in general, there's certainly room for optimization but only to a certain degree.
Yes, at the moment all levels below the requested level are loaded first. This is certain suboptimal but the math behind it will tell you that it's theoretically just 33% more data you're loading :)
For the main use case of OpenZoom it does make sense, too, since your zooming into the image where this will make for a much smoother effect.
If you really just want to have size aware image rendering, you might be better off to just quickly cook something up along the lines of what I outlined before.
Cheers,
Daniel
-
Inappropriate?Hi again, Daniel:)
I did some more testing today. And I must say the problem is smaller then i thought. It's probably al lot of tweaking I still need to do.
with "the tile overlap becomes very visible" i mean you can really see that it's blocks being loaded, and especially on the overlap you can see it really clear. But after today's testing I need to add: it only occurs when I load the same picture more then once. So, after it's cached or still in memory?
I'm testing just a simple version of the MultiScaleImage.fla .. I'm loading 4 different images from a menu.. Which will basically be the way it'll have to work. People select a project from a menu and browse through some pictures.. So it could be that people open the same image more then once.. Any idea how I could prevent this problem?
Since I can't use your openzoom format yet, which format do you think works best for my project? Zoomify or Deepzoom images? The zoomify pictures, exported from photoshop, seem to work smoother than the deepzoom pictures (for big stages). Or do you think it makes no difference?
I’m unsure wheter i'm a pain in the #%$ ? ;)
-
Inappropriate?Willem,
Forgive me for not having offered you to email me your examples before.
Regarding the loading problems, it's a shame since I am working on a new rendering system which will most likely solve those kind of problems. It's still a couple of weeks out and I'm not sure it's worth fixing the issues with the old rendering system.
Multiscale Image Formats
The OpenZoom Description Format is not an image format per se, meaning it's just a sidecar file for describing properties of image pyramids and access to the tiles. Don't worry if that sounds confusing, I should make it more clear that for most people the OpenZoom Description Format is not relevant.
I endorse the Deep Zoom image format as it (theoretically) should offer you the smoothest experience. There are also many tools available for it such as Deep Zoom Composer, the DeepZoomTools.dll and my very own Python Deep Zoom Tools. Most importantly it has widest adoption in terms of rendering: Silverlight Deep Zoom, Seadragon Mobile (iPhone/iPod touch), Seadragon Ajax (JavaScript) and of course OpenZoom (Flash & Flex).
Zoomify of course has the Photoshop export and is not a bad format by any means.
Still, the most future-proof way to go is with the Deep Zoom image format, I believe.
Cheers,
Daniel
P.S. Don't worry, you're definitely not a pain in the #%$ and this remains so as long as you don't spam my personal inbox. :)
-
Inappropriate?Daniel,
"Forgive me for not having offered you to email me your examples before." So.. is that the offer?
"P.S. Don't worry, you're definitely not a pain in the #%$ and this remains so as long as you don't spam my personal inbox. :)" so maybe I better not mail you my example? haha..
Okay, that still leaves me with some questions..
If I don't modify your api core code, is it possible to update when you've published the new rendering engine?
I understood the Multiscale Image Formats part.. but the question was actually more about the best tools to use. For this project, it will only be computerscreens which will be used.
Since I'm mainly using my mac I can't really use the DZ-compiler. And I can't get python to work on my hosting-account..
So I exported the same picture both on my windows pc with DZ-compiler and on my mac with Photoshop CS4.. and it seems photoshop does a way better job on exporting the picture..
I’m confident
-
Inappropriate?Willem,
Sure, send those examples my way to daniel@gasienica.ch! :)
There's no need to install the Python Deep Zoom Tools on your server if you don't plan to dynamically convert your images on the server. Just run the Python script locally and upload the exported image just like with Deep Zoom Composer or Photoshop Zoomify. Nonetheless, if Photoshop works fine for you that's great!
As for backwards compatibility, I can't promise anything considering there has been no official public release of the components so far! :) I will certainly try to minimize impact of the new rendering engine as I will have to update more than a dozen examples myself. However, a simple and clean API is priority number one!
Cheers,
Daniel
EMPLOYEE
