Image-stitching and virtual tour solutions My account Updates
It is currently Fri Oct 31, 2014 9:31 am

All times are UTC + 1 hour




Post new topic Reply to topic  [ 23 posts ] 
Author Message
PostPosted: Tue Nov 23, 2010 1:01 pm 
Offline
Member
User avatar

Joined: Tue Jun 09, 2009 1:01 pm
Posts: 3345
Location: Salzburg
PTP 1.5 RC using...

inspired by this thread:
http://www.autopano.net/forum/t10606-tiles-and-cutting-size

I came along the problem how to set the perfect cutting size value?

If I use "compute optimal size" the witdh and heigh values are getting calculated, but not the also listed Cutting Size value.
so doing it manually...
... but which logic: when to use a high value, when using a small value.
If I interprete the threads correct: doing a multires.pano it make sens to use a small cutting size value so zooming into the pano can load small chunks of the image.

in my example the optimum width/heigth values are 3672/640

if I use a cutting size of 1000 the pano is murder fast loaded and the rotating "clock" saying image loading just take parts of a second.
if I use a cutting size of 100 the pano is murder SLOW loaded and the rotating "clock" take a minute or longer to finish loading...

So setting this value to a low value while using a 10 times bigger or even gigapixel pano cant work...?
do I miss something?

why cant the "compute optimal size" button no also calculate & suggest an optimum value for the cutting size?

Liebe Gruesse,
Georg



_________________
pages: gigapixel.at - jedermann.at - My Equipment


Last edited by gkaefer on Tue Nov 23, 2010 1:03 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 23, 2010 1:18 pm 
Offline
Member

Joined: Thu Feb 23, 2006 2:55 pm
Posts: 157
Location: Italy - Roma
Hi Georg,

I think I came to same conclusion.
There's no need of small tiles if the panorama is intended for fullscreen and, in general, I guess there's no need of tiles smaller than the window hight.
Did I get it right?

Regards,
Marco


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 23, 2010 1:23 pm 
Offline
Member

Joined: Thu Feb 23, 2006 2:55 pm
Posts: 157
Location: Italy - Roma
...but what about max preview size?
What about the "right" value.

Regards,
Marco


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 23, 2010 1:30 pm 
Offline
Member
User avatar

Joined: Tue Jun 09, 2009 1:01 pm
Posts: 3345
Location: Salzburg
marco.lanciani wrote:
Hi Georg,

(...), I guess there's no need of tiles smaller than the window hight.
Did I get it right?

Regards,
Marco

If I pick up your idea this would lead to coclusio that this value is absolute useless, because I can optimize the tile size to my screen where I create the tour but I've no single influence on enduser looking at this pano, because everybody is using individual monitors & screensizes... ;-(

Georg

_________________
pages: gigapixel.at - jedermann.at - My Equipment


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 23, 2010 1:35 pm 
Offline
Administrator
User avatar

Joined: Wed Sep 29, 2010 9:00 am
Posts: 199
Location: Francin
Some information has been posted here: http://www.autopano.net/forum/t10606-tiles-and-cutting-size

_________________
--
Yann G.
www.kolor.com


Last edited by ygilquin on Tue Nov 23, 2010 1:35 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 23, 2010 2:31 pm 
Offline
Member
User avatar

Joined: Tue Jun 09, 2009 1:01 pm
Posts: 3345
Location: Salzburg
ygilquin wrote:

hmmm, Yann I noticed this thread in my initial response...
... but unfortunateley it explains some part but let also some part unclear:

digipano says in the thread we both are citing:

Quote:
so smaller tiles will render tours faster when fully zoomed in.

but as I could proof with my little test this cant be true - smaller cutting size leads to massive longer loading time...
why does not the cutting size value get calculated, if I press the button "compute optimal size"?

so:
when is a small cutting size value recommended?
when is a big cutting size value recoomended?
is there any mathematical calculation I can use so I do not have to try and error several times?

you write in the cited thread:
Quote:
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

ok in my example with a rarley very small pano the cutting size of 1024 is percect, but reduing it to 100 leads to an pano tour with is unsharp for the fist 40 seconds and than very slowly loading until the spinning wheel indicates the loading has finished (in total over one minute)

so finally: even for this small pano using a value less than 1024 is not usefull. So which values are used in which cases?


Georg

_________________
pages: gigapixel.at - jedermann.at - My Equipment


Last edited by gkaefer on Tue Nov 23, 2010 2:41 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 23, 2010 2:42 pm 
Offline
Administrator
User avatar

Joined: Wed Sep 29, 2010 9:00 am
Posts: 199
Location: Francin
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.

gkaefer wrote:
when is a small cutting size value recommended?

Almost all cases (<600px). If you're uncomfortable with this setting (and I know it will be much easier once documentation is released) set a value in range [500-600].

gkaefer wrote:
when is a big cutting size value recoomended?

Gigapixels tours where memory overhead allocation in player will result in browser crash. (1024px)

gkaefer wrote:
is there any mathematical calculation I can use so I do not have to try and error several times?

No. Only empirical testing will allow to set it with a value giving the most comfortable user experience and preventing flash player from crashing.

Does this answer your questions ?

_________________
--
Yann G.
www.kolor.com


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 23, 2010 2:51 pm 
Offline
Member
User avatar

Joined: Tue Jun 09, 2009 1:01 pm
Posts: 3345
Location: Salzburg
ygilquin wrote:
Does this answer your questions ?

yes. clear now.

PS about user friendly UI:

to be honest: having one "otimize size button" obove 4 local values places which have all to to with size and are all grouped by one square around them leads any normal user to conclusion that klicking this button will affect all 4 values. In fact it affects only the above width and height values. Perhaps this confusion could be avoided by better seperation/placement...

Liebe Gruesse,
Georg

_________________
pages: gigapixel.at - jedermann.at - My Equipment


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 23, 2010 3:00 pm 
Offline
Administrator
User avatar

Joined: Wed Sep 29, 2010 9:00 am
Posts: 199
Location: Francin
Good feedback, thank you.

_________________
--
Yann G.
www.kolor.com


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 23, 2010 3:23 pm 
Offline
Member

Joined: Sat Feb 16, 2008 9:07 am
Posts: 581
Well I should have been more complete in my answer that gigapixel images will benefit with smaller cutting tiles (128x128) & the tour will render faster but this is not a fixed ratio & you need to test on a real server.

But now I am confused too when ygilquin say
"Gigapixels tours where memory overhead allocation in player will result in browser crash. (1024px)"

Am I correct that for gigapixel images we should use smaller numerical 128x128 or 64x64 (more number of tiles) if we want faster rendering assuming it will be using more ram as ygilquin say in another post?


Last edited by digipano on Tue Nov 23, 2010 3:34 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 23, 2010 3:36 pm 
Offline
Member
User avatar

Joined: Tue Jun 09, 2009 1:01 pm
Posts: 3345
Location: Salzburg
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...

Liebe Gruesse,
Georg

_________________
pages: gigapixel.at - jedermann.at - My Equipment


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 23, 2010 3:53 pm 
Offline
Member

Joined: Wed Nov 14, 2007 2:12 pm
Posts: 14069
Location: Isleham, Cambridgeshire, UK.
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...

Liebe Gruesse,
Georg

Did you embed everything when building the tour for this test?

_________________
Andrew Stephens
Many different Nodal Ninja and Agnos pano heads. Merlin/Panogear mount with Papywizard on Nokia Internet tablets.
Nikon D5100 and D40, Sigma 8mm f3.5 FE, Nikon 10.5mm FE, 35mm, 50mm, 18-55mm, 70-210mm. Promote control.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 23, 2010 3:54 pm 
Offline
Member

Joined: Sat Feb 16, 2008 9:07 am
Posts: 581
Quote:
a pano with 3672x998 pixels

at that resolution there is no need to use smaller tile as this wont benefit, in fact you are correct that at this size bigger tile size will be faster but the real use of tiles & its cutting size is when you are dealing with 30000x 20000 gigapixel image & you would use multires option where the tile size need to be smaller else the server will be downloading bigger tiles even when the user want just a smaller area to be viewed.

Kolor's Paris gigapixel is an example

Franky I am now completely confused & I may be wrong in my understanding hence seek an official documentation or at least an official answer for the questions you have put up.

When to use smaller tiles?
When to use bigger tiles?


Last edited by digipano on Tue Nov 23, 2010 4:21 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 23, 2010 4:10 pm 
Offline
Member

Joined: Mon May 22, 2006 12:18 am
Posts: 7812
Location: Duesseldorf, Germany
Can we say as a conclusion: for "usual" sizes - which means around 10000x5000px - a cutting size of 512 is the optimal setting related to loading and displaying speed and offers a sufficient zoom-level?
And that with partial panos of some Gigapixels a cutting size of around 64 or 128 is the optimum?

So that´s two different pieces of cake?

best, Klaus

_________________
Simplicity is the keynote of all true elegance. Coco Chanel


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 23, 2010 4:20 pm 
Offline
Member

Joined: Sat Feb 16, 2008 9:07 am
Posts: 581
klaus thats what I understood till now that we have 2 parameter for 2 different cases one for usual pano & another for multires (gigapixel) panos but will now wait for official answer.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 23, 2010 4:40 pm 
Offline
Member
User avatar

Joined: Tue Jun 09, 2009 1:01 pm
Posts: 3345
Location: Salzburg
mediavets wrote:
Did you embed everything when building the tour for this test?

actually I didn' care ;-) have to look...

html generic template + Fullscreen nav...+help template
no. neither embed all nor embed xml...
but i used demo PTP 1.5 RC version, xml files are created ...
and tested with Google Chrome, IE9beta and also Firefox...
and opening tour locally on PC where I created the tour

Georg

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?

_________________
pages: gigapixel.at - jedermann.at - My Equipment


Last edited by gkaefer on Tue Nov 23, 2010 4:47 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 23, 2010 4:48 pm 
Offline
Member

Joined: Wed Nov 14, 2007 2:12 pm
Posts: 14069
Location: Isleham, Cambridgeshire, UK.
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 ?

It raises another question.

According to the documentation for the KMAKEMULTIRES krpano tool:

http://krpano.com/tools/kmakemultires/

"[using default settings] it automatically calculates the best tilesize and the number of multiresolution levels and generates the tiles for it"

Which suggests there is an optimum tilesize and number of multiresolution levels for any particular pano image.

.................

Do you think 'cutting size' is the best terminology?

Is the APT/PT/PTP term 'cutting size' what krpano terms 'tilesize'?

If so, would it not be better to adopt the term 'tile size'? (it isn't one word in English!)

_________________
Andrew Stephens
Many different Nodal Ninja and Agnos pano heads. Merlin/Panogear mount with Papywizard on Nokia Internet tablets.
Nikon D5100 and D40, Sigma 8mm f3.5 FE, Nikon 10.5mm FE, 35mm, 50mm, 18-55mm, 70-210mm. Promote control.


Last edited by mediavets on Tue Nov 23, 2010 4:48 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 23, 2010 4:57 pm 
Offline
Member

Joined: Sat Feb 16, 2008 9:07 am
Posts: 581
I vote for Tile size as a terminology.
Quote:
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?

That the feature indeed so only the required tile or tiles which the viewer is seeking will get downloaded instead of one big tile hence faster viewing of gigapixel online tours.

Still seeking an official answer.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 23, 2010 5:39 pm 
Offline
Administrator
User avatar

Joined: Mon Nov 14, 2005 4:56 pm
Posts: 5901
Location: Francin, France
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.

The tile size will influence on these values :
- In krpano player, the structure which stores all triangles to be displayed. For Paris26G, with 512 pixels tiles, the memory used by flash was around 850 MB. With 1024 tiles, it was reduced to 150 MB ( I remind me these figures, but it's already a long time since we released that project )
- 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.

Is there a way to calculate the optimal tile size for a given panorama ?

In fact, we have this problem.
* Input variables : panorama width / height
* Two unknown : the number of levels of the pyramid, the tiles size
* Measurements : memory used in flash, speed of first perfectly displayed panorama

Not really easy to get something that works always. I believe that there is an optimal value somewhere between 512 and 1024, but again it really depends on the input image. For a image of 250 Gigapixels for example, I believe that the answer would be 2048.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 23, 2010 7:38 pm 
Offline
Member

Joined: Mon May 22, 2006 12:18 am
Posts: 7812
Location: Duesseldorf, Germany
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.

Hi Alex - thanks for this very good explanation! You took it to the point. :cool:

best, Klaus

_________________
Simplicity is the keynote of all true elegance. Coco Chanel


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 23, 2010 11:40 pm 
Offline
Member
User avatar

Joined: Tue Jun 09, 2009 1:01 pm
Posts: 3345
Location: Salzburg
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.
(...)

Alexandre, I read your lines. I can follow them... sounds clear. Only thing I cant proof them in my tests.

I can set cutting size to 64 and I do get according tiles in size of 49x49 pixels and accordingly more multires levels. See my table to compare them on a pano i did test with. number of files increased, tile size shrinks and mb sum is doubled compared to 128 cutting size...

I get different tile sizes and I do get different multires levels in my examples. all best with them...

but why takes the loading of the initial resulting pano differently long time from 1 second with 1200 tilesize until >140 seconds for the 64 cutting size? the pano size zoom level resulting quality of pano is in all examples equal...

why is the cutting size in all cases nearly 50% bigger than the resulting tilesize?

so in all my examples reduzing cutting size from default value of 1200 only affects (negatively) the loading time.

it would be ok if the loading of the default view is in all cases same lets assume 1 second and according of zooming into the pano the according sector get loaded again - and here according of the set cutting size the reload differes in time needed.

But in reality the loading of the default pano is depending from cutting size - lower cutting size = longer initial loading (more tiles have to be loaded for the (I assume) total pano (and not the displayed inità­al sector). Is the inital loading finished zooming into the pano does not result in any reloading of the zoomed into sector.

I uploaded the 1200 and 600 cutting size example (sorry 150.000 files uploading for the 64 version I didnt want to wait for ;-)

1200 cutting size: http://www.burgspiele-salzburg.at//Galerie/Panorama/test-PTP/test1-cutting-size-1200.html
600 cutting size: http://www.burgspiele-salzburg.at//Galerie/Panorama/test-PTP/test1-cutting-size-600.html

the initial source file used for the tour is a 750mb .kro file with 18228 x 10419 pixel (a 25% render of original size).

Liebe Gruesse,
Georg



_________________
pages: gigapixel.at - jedermann.at - My Equipment


Last edited by gkaefer on Tue Nov 23, 2010 11:53 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 24, 2010 9:53 am 
Offline
Administrator
User avatar

Joined: Mon Nov 14, 2005 4:56 pm
Posts: 5901
Location: Francin, France
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 ? ;) )


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 24, 2010 12:02 pm 
Offline
Member
User avatar

Joined: Tue Jun 09, 2009 1:01 pm
Posts: 3345
Location: Salzburg
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 ? ;) )

to be honest - im unhappy with what you're saying...
... because it leads me to conclusion that using other value than the suggested one is useless. So why having this option at all?

If I have a pano source of 20.000x10.000 pixsel sliced into 64pixel tiles and I've a 5000x2000 source pano sliced into 64 pixel tiles...
and there is no speed difference in loading (compared to the fast loading versions with 1200 cutting size)?

139mb contra 36.7mb is of course more to download. But if you look into the created directory you see the 64cutting version does have one more subfolder than the 128cutting version with 36.7mb (2more subfolders than the 300cutting version etc.). if you compare the equal directories of both version they're equal in size.

So If I load initial panoview of the 64cuttingsize version, why must the version be downloaded with the biggest number of slices (more files more overhead, more mb etc.= longer loading), I did not zoom into the pano so the smallest of the subfolders containing only the 6 tiles should be enough to be downloaded for displaying. If I zoom later into the pano according to my choosen area, exactly than the needed data from the according subfolder should be loaded & displayed. Finally if I zoom into the pono to the maximum the tiles of that directory containing the most tiles should be loaded according to my choosen area).

PS: and using only big cuttingsize values results in having only view subdirectories with less multiresolution versions

Liebe Gruesse,
Georg

_________________
pages: gigapixel.at - jedermann.at - My Equipment


Last edited by gkaefer on Wed Nov 24, 2010 12:16 pm, edited 1 time in total.

Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 23 posts ] 

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group