marco.lanciani wrote:Hi Georg,
(...), I guess there's no need of tiles smaller than the window hight.
Did I get it right?
ygilquin wrote:Some information has been posted here: http://www.autopano.net/forum/t10606-tiles-and-cutting-size
so smaller tiles will render tours faster when fully zoomed in.
This is false. Be aware that Krpano player allocates some memory overhead (RAM) for each tile it loads. This means limiting tiles number is a way to reduce memory consumption used by the browser and in certain cases, it's a way to prevent him from crashing. To limit tiles number, you can increase tile cutting size to 1024 for example. Using a high cutting size is recommended for gigapixels tours
gkaefer wrote:why does not the cutting size value get calculated, if I press the button "compute optimal size"?
gkaefer wrote:when is a small cutting size value recommended?
gkaefer wrote:when is a big cutting size value recoomended?
gkaefer wrote:is there any mathematical calculation I can use so I do not have to try and error several times?
ygilquin wrote:Does this answer your questions ?
digipano wrote:Am I correct that for gigapixel images we should use smaller numerical 128x128 or 64x64 (more number of tiles) ?
gkaefer wrote:digipano wrote:Am I correct that for gigapixel images we should use smaller numerical 128x128 or 64x64 (more number of tiles) ?
you mean setting the cutting size to 128 or 64?
if so: I had in my test (screenshot first posting) a pano with 3672x998 pixels jpg with about 400kb.
If I set cutting size to 1000 I've a perfect tour fast loading.
If I set cutting size to 100 its takes more than a minute to load the initial view of the tour. Has this loading finished zooming into is again perfect without pausing waiting to load tiles...
but If I imagine using a multiple bigger pano or even gigapixel... I cant imaging 64 or 124 as cutting size will work...
a pano with 3672x998 pixels
mediavets wrote:Did you embed everything when building the tour for this test?
ygilquin wrote:gkaefer wrote:why does not the cutting size value get calculated, if I press the button "compute optimal size"?
Because there is not one optimal value for a tour. See that as an additional option given to Panotour users to ease their lifes, not to complicate it.
Does this answer your questions ?
EDIT: but I did the opposite test and did embed all and voila its going to be VERRRRRy FAST even using cutting size of 10!
so feature or a bug finally?
AlexandreJ wrote:- The time to get a perfect view on the current viewpoint should not be influenced too much by tile size. Imagine a 2 megapixels screen, you will need to download these pixels. Now, let's think about the tiles that are cutting the edges on the screen : if the tile is just 512, then only some pixels outside current viewpoint have been downloaded and never displayed ( because outside the current viewpoint ). With a 1024 tile, you will have more pixel that has been downloaded but not displayed yet ( because outside viewpoint ). So, it's a bit slower to get the initial perfectly download view. But if you start to scroll, it's in fact faster than with 512 tiles because you have more pixel already downloaded. This could be viewed as a frame of pixels around the current screen pixel : with bigger tiles, this frame is bigger around the screen. I hope I did manage to highlight this concept.
AlexandreJ wrote:(...) We have an experimental approach on the cutting size, but first one fact : if you put a cutting size of 10 => you'll get 128 because it's the minimal value allowed.
AlexandreJ wrote:You did a great benchmark, Gerog. That's really cool.
It really highlights some fact that I was aware of but not sure about their influence :
- Each jpeg file contains also a header, that doesn't stores anything usefull ( pixels in fact ).
So more tiles, more unneeded stuff to download ( see 139 mb versus 36.7 mb for small / high res tile version ).
So apparently, this simple fact compensate what you could gain in hidden pixels frame download.
- Another fact to take into account : if you have 10 big images to download through the web, you have less chance to be stucked waiting for one to finish than if you have 150 small images to download ( each if we consider that the size to download of 10 big images = size of 150 small images ). That's a typical behavior of internet routine.
So it seems that the conclusion is clear : the bigger the best !
( where does that comes from ? )
Users browsing this forum: No registered users and 1 guest