APT • Performance

[MTK]

APT • Performance

by MTK » Wed Jan 06, 2010 1:03 am

Hello, Autopano Tour Forum,

I have produced a few 360° Virtual Tours 360° x 180°; I have uploaded them to [url]360.mtkmarketing.com[/url] .
I have noticed the performance seems rough and not smooth while on auto rotation or manual rotation.
The VT seems to hesitate slightly.

Has anyone else experienced this issue in their panorama virtual tours and have suggestions to offer?

Thank you in advance for any advice given.

Kind regards,

Michael T. Kleven

[Adrien F]

by Adrien F » Wed Jan 06, 2010 9:34 am

Hello Michael,

If you use the krpano unlimited licence, you should try to set a smaller cutting size in Pictures parameters (512 seems ok to me) to take advantage of multiresolution. Play also a bit with jpeg quality and you should be good.
Most of the time the un-smoothness of visits is due to a too big picture size.

Adrien

[klausesser]

by klausesser » Wed Jan 06, 2010 11:41 am

Hello Michael,

If you use the krpano unlimited licence, you should try to set a smaller cutting size in Pictures parameters (512 seems ok to me) to take advantage of multiresolution. Play also a bit with jpeg quality and you should be good.
Most of the time the un-smoothness of visits is due to a too big picture size.

Adrien

Hey Adrien!

Wait a minute: setting the cube-face size to 512 for taking "advantage of multiresolution"? Or what do you mean with "smaller cutting size"?

I usually take 1024px for the cubefaces in APT - and THAT´S definitely too low for a really good looking fullscreen view.

I´m just playing around with multires-tours in APT - without success actually. But i wouldn´t give up . . . .

best, Klaus

[Adrien F]

by Adrien F » Wed Jan 06, 2010 1:22 pm

setting the cube-face size to 512 for taking "advantage of multiresolution"? Or what do you mean with "smaller cutting size"?

No, I did not say to set the cube face to 512, that would definitely kill any visit quality!
As said here http://www.autopano.net/forum/t7639-question-concerning-preview

So what is the cutting size? It is the maximum size a patch can have. When loading pictures APT uses approximations of the panorama, at different level of zoom, cut in patches. Choosing to have a high cutting size means loading biggers parts of the scene, but in little number. A low cutting size means having a lot of small pictures to load, thus ensure a "smoother" loading

Cube face is related to visit resolution/quality, cutting size is not.

Note : what I call patch is also known as tile

Last edited by Adrien F on Wed Jan 06, 2010 1:43 pm, edited 1 time in total.

[mediavets]

by mediavets » Wed Jan 06, 2010 2:29 pm

Note : what I call patch is also known as tile

I think it would reduce risk of confusion if we were to adopt 'tile' as the preferred term?

[klausesser]

by klausesser » Wed Jan 06, 2010 2:58 pm

"So what is the cutting size? It is the maximum size a patch can have"

??? i don´t understand what that could mean. . .

Coulnd´t anybody give an advice in SILMPLE words how to use multires - STEP BY STEP!?

Let´s begin with a 20000x10000 px image: what´s to do to make a multires pano from it?

If you be so kind: step by step logically . . .


best, Klaus

P.S.: where in hell is an item named "cutting size" in APT?

Last edited by klausesser on Wed Jan 06, 2010 3:00 pm, edited 1 time in total.

[digipano]

by digipano » Wed Jan 06, 2010 3:34 pm

P.S.: where in hell is an item named "cutting size" in APT?

Panorama properties> Picture parameters> compute optimal size> cutting size (2nd row)

[klausesser]

by klausesser » Wed Jan 06, 2010 3:41 pm

P.S.: where in hell is an item named "cutting size" in APT?

Panorama properties> Picture parameters> compute optimal size> cutting size (2nd row)

i see - never knew what it exactly (!) means. Don´t know it still . . .

best, Klaus

P.S.: is it related to multires?

Last edited by klausesser on Wed Jan 06, 2010 3:42 pm, edited 1 time in total.

[digipano]

by digipano » Wed Jan 06, 2010 3:54 pm

Yes it means that you cut the tiles to specified size for a multires panorama, smaller the tile size faster the loading can be (My guess) bcoz only those number tiles will be downloaded.

[MTK]

by MTK » Wed Jan 06, 2010 5:32 pm

Thank you Adrien for your help. May I clarify your statements with some screenshots to help me understand correctly.

If you use the krpano unlimited licence, you should try to set a smaller cutting size in Pictures parameters (512 seems ok to me) to take advantage of multiresolution. Play also a bit with jpeg quality and you should be good.
Most of the time the un-smoothness of visits is due to a too big picture size.

Adrien

Here is a screenshot of my original settings.


Here is a screenshot after clicking "Compute Optimal Size".


The "Partial Panorama Width" increased to "6681".

Which field relates to "cutting size"?

In reading your recommendation, which field should I enter "512"?

Thank you in advance for your help.

Michael T. Kleven

[DrSlony]

by DrSlony » Wed Jan 06, 2010 5:39 pm

Hey klausesser, although I don't use krpano, from what I know about other pano viewers I infer that the cube size limits the resolution of the panorama - the equirectangular pano, regarless of its size, gets converted to 6 cube faces and each one is as large as you set them. I typically use about 1500-2000px for fullscreen viewing (no multires, but its sharp fullscreen on a 1680x1050 screen). From the definitions given here, cutting size I guess is how many tiles each cube face gets divided into. The more tiles you have, the less off-screen data has to be downloaded if you zoom in at such a distance that the whole cube face doesn't fit on the screen. For example if you shot a giga pano and use tiles 2000px wide but your flash window is only 800px wide, you're loading extra 1200px in width for nothing.
So why not make small tiles 10x10 px by default? I don't know, I'd like someone from krpano to answer that, but my guess is that its about overhead and worse performance when flash has to move many little pieces instead of one large one.

[digipano]

by digipano » Wed Jan 06, 2010 5:40 pm

Which field relates to "cutting size"?

"cutting size" is only part of APT 1.1 beta 6, I see that you are using APT 1.06 which has this parameter mentioned differently.

Last edited by digipano on Wed Jan 06, 2010 5:42 pm, edited 1 time in total.

[mediavets]

by mediavets » Wed Jan 06, 2010 5:42 pm

Which field relates to "cutting size"?

In reading your recommendation, which field should I enter "512"?

Thank you in advance for your help.

Michael T. Kleven

You need APT 1.1 beta 6 from here:
http://www.autopano.net/forum/p51122-2009-09-07-11-54-52#p51122
Then you'll find this:

[klausesser]

by klausesser » Wed Jan 06, 2010 6:21 pm

Hey klausesser, although I don't use krpano, from what I know about other pano viewers I infer that the cube size limits the resolution of the panorama - the equirectangular pano, regarless of its size, gets converted to 6 cube faces and each one is as large as you set them. I typically use about 1500-2000px for fullscreen viewing (no multires, but its sharp fullscreen on a 1680x1050 screen). From the definitions given here, cutting size I guess is how many tiles each cube face gets divided into. The more tiles you have, the less off-screen data has to be downloaded if you zoom in at such a distance that the whole cube face doesn't fit on the screen. For example if you shot a giga pano and use tiles 2000px wide but your flash window is only 800px wide, you're loading extra 1200px in width for nothing.
So why not make small tiles 10x10 px by default? I don't know, I'd like someone from krpano to answer that, but my guess is that its about overhead and worse performance when flash has to move many little pieces instead of one large one.

Hi Maciek!

I tried a 10000x5000 pano and used "cutting size" of 512 and cubefaces of 3184.
Per node it´s about 11MB - very fine on fullscreen and good zoomable.

http://www.360impressions.de/mw.html

best, Klaus

Last edited by klausesser on Wed Jan 27, 2010 12:26 pm, edited 1 time in total.

[BrianLR]

by BrianLR » Wed Jan 27, 2010 12:50 am

Hello Michael,

If you use the krpano unlimited licence, you should try to set a smaller cutting size in Pictures parameters (512 seems ok to me) to take advantage of multiresolution. Play also a bit with jpeg quality and you should be good.
Most of the time the un-smoothness of visits is due to a too big picture size.

Adrien

I also get this performance problem and tried using a cutting size of 512 rather than 1200. It did not improve performace and doubled the amount of storage space used, although the actual folder size was the same, probably due to all those tiny files.

When you say "Most of the time the un-smoothness of visits is due to a too big picture size." which picture size do you mean, even with a smaller cutting size, there may be other factors at play here?

Last edited by BrianLR on Wed Jan 27, 2010 12:52 am, edited 1 time in total.

[mediavets]

by mediavets » Wed Jan 27, 2010 8:24 am

I also get this performance problem and tried using a cutting size of 512 rather than 1200. It did not improve performace and doubled the amount of storage space used, although the actual folder size was the same, probably due to all those tiny files.

Exactly what 'performance problem' do you experience?

Perhaps you could provide a link to an example - and tell us what size of pano image you started off with and what settings you used in APT.

[klausesser]

by klausesser » Wed Jan 27, 2010 12:56 pm

Yes it means that you cut the tiles to specified size for a multires panorama, smaller the tile size faster the loading can be (My guess) bcoz only those number tiles will be downloaded.

Hi digi!

I forgot to say thanks . . . sorry.

best, Klaus

[hankkarl]

by hankkarl » Wed Jan 27, 2010 6:03 pm

So why not make small tiles 10x10 px by default? I don't know, I'd like someone from krpano to answer that, but my guess is that its about overhead and worse performance when flash has to move many little pieces instead of one large one.

Its more a network protocol issue. Each tile is a file, and you have to issue an HTML "GET" for each. So if you have too many small files, you have a lot of HTML protocol compared to the data transferred. But a big file takes a while to come down. Also, every time you access a file on the server, the server has extra work to do.

And TCP/IP plays a part. Generally, the largest packet is about 1500 bytes, and the smallest is 64 bytes (all 64 bytes are overhead). There are some compressions that can be used, but don't count on them--they may not always be implemented.

For a 256x256 JPG tile with 24 bit color depth, I got file sizes from 37K to 110K.

So for a 10x10 file, straight scaling says you'd have 56 to 167 bytes, but there may be some JPG overhead that makes the file bigger.

100x100 may be a better choice. YMMV based on the speed of the viewers connection, the server used, etc.