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 wrote:

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-que … ng-preview

Adrien F wrote:

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 (2010-01-06 13:43:44)

"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 (2010-01-06 15:00:00)

digipano wrote:

klausesser wrote:

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 (2010-01-06 15:42:36)

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

Adrien F wrote:

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

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 (2010-01-06 17:42:07)

DrSlony wrote:

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 (2010-01-27 12:26:22)

BrianLR wrote:

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.

DrSlony wrote:

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.