Cube face size problems

[ScottWitte]

Pano2QTVR took my 5954x2977 equilateral and converted it to 1892 cube faces.

Pano2VR takes the same image and wants to produce faces of 1488. If I load my 1892 cube faces or the cube face strip, Pano2VR wants to convert to a 7568 wide equilateral. Which program is doing it right???

[thomas]

Both. Pano2QTVR suggests the maximum resolution (width/pi) and Pano2VR uses the more moderate formular (width/4) which give the maximum on the borders.

It depends on your intent to find the best cubeface width. For retouching width/pi is the better choice. For displaying width/4 is enough.

[ScottWitte]

So, if I understand correctly, the Pano2QTVR cubes will show all available detail or resolution near the center of each cube but toward the edges you are "enlarging" beyond real resolution. Pano2VR doesn't "enlarge" past native resolution at the edges but the centers will loose some real detail (resolution) as a result.

That makes for a perplexing decision. I like the 20%+ file size reduction in Pano2VR. But in the final pano, while you will see no loss of detail when viewing the seams areas you will loose detail in other parts, compared to the result from Pano2QTVR.

Is that the tradeoff? I would prefer to get the choice when making cubes. That would require some kind of option button for automatically sized cubes. But I also love the ability to manually set cube size.... what interpolator is used?

[360Texas]

I think what Thomas is saying is:

Using Pano2qtvr If your stitched image is 6000 pixel wide
============
Sphere to cube using PI (pie)
6000 /3.14 = cube face is 1910.828025 width x 1910.828025 high

Convert cubes back to Sphere:
1910.828025 x 3.14 = 5999.99 [not quite original 6000]

=======
Using Pano2VR Convert Sphere to cube
6000 /4 = cube face is 1500 width x 1500 high

Convert cube back to Sphere
1500 x 4 = 6000 original width.

I think the pano2qtvr software is using 3.14 or PI for its calculation. My cube face conversions always are a little smaller that the original.

[ScottWitte]

Dave,

I think I get the differences in math and method between the two programs. But what are the practical implications and trade offs between the two. If the /4 method looses no detail compared to the Pi method I can certainly handle retouching a smaller cubeface in exchange for the 20%+ smaller file size in the resulting final panorama.

My suspicion is that the pano2VR method looses some detail (relatively) in the cube face center. Does that really matter? Under what circumstances? Shouldn't we have a choice when doing the conversion or are we simply better off with Pano2VR's /4 method and we shouldn't worry about it?

[erik leeman]

Hi Scott,
I understand why you asked about it after noticing the difference, but I really don't understand why this is a problem in the first place.
Perhaps I am doing it all wrong here, but for me it doesn't matter. I just let PTGui and Pano2QTVR (not Pano2VR as it is now) make the largest possible equirectangulars/cubefaces that can be made from my source TIFFs, so I can edit those accurately and relatively easy in Photoshop with as little loss in quality as possible. After that I simply reduce the finished cubefaces to the size best suited for the intended display-size of the VR version, also in Photoshop. I can make as many resized sets I want and sharpen each as much as I think is appropriate. Each of these sets is then used to make the correspondingly sized QTVR or Flash version. Of course I also keep the original large cubefaces!
Again, if you think this is a bad method please tell me, but I think my results might convince you it isn't.

Regards,

erik leeman

[ScottWitte]

Erik,

Oh your results definitely are convincing

Your workflow is essentially what I and probably most of us follow. The thing is, eventually we would most likely migrate completely from v1.6 to v2 so we will end up using, by default, the smaller cube face. I don't mind that unless it means a loss in quality. Unless someone (Thomas?) has run definitive tests showing that there is no loss it would be nice to have the option to use the larger, Pi method... IMO

[erik leeman]

Sorry Scott, from your question I wrongly assumed you let Pano2(QT)VR generate .movs or .swfs directly, without extracting and editing the cubefaces first. I fully agree with you when you ask for the possibility to choose between the two methods in Pano2VR!

[thomas]

Ok, I will add the option to choose the Pi formula into the next beta.

[ScottWitte]

Ok, I will add the option to choose the Pi formula into the next beta.

You da man, Thomas. I, for one, am really looking forward to the next beta. (For far more than this.)

[hum@no.id]

Why, these complications? Why, Pi??

Sphere to cube using PI (pie)
6000 /3.14 = cube face is 1910.828025 width x 1910.828025 high

- this errors of the calculation


360Texas - "1/4" has indicated correct calculation for Remapping.. Who work in 3D visualization, this knows...

For "1/4" method - sphere map Nx(N/2) = cube map (N/4)x(N/4)x6 - this can be shown paradoxical, but this truth... You may take calculator, and consider applicable definite real value...

sphere map 6000x3000 = cube map 1500x1500x6 (6000/4) - And yell: "Hey, Man is here got inequality !?"

6000x3000=18000000 > 1500x1500x6=13500000 (!?)
Beside this inequality, there is constant value -25%

For this there is reasons (We do not calculate area of courtyard for Home). It is necessary understand, that is covered texture on virtual wireframe. Sphere map - carries in itself excess value of pixels , which in consequence interpolates in nowhere... This excess will always is added for mapping "Sphere".

This it is difficult for understanding in importances of the numerals and formula. For this is always given example a "human understanding" and visual estimation (he is not very right, but only shows essence).

Remember at school ... simple Globus (Globe) model and his paper spherical texture.. he was not covered a Rectangle paper.

For example, here is so (ex. from Flexify 2 remaper).


Formed white "comb slots ", this and there is excess of the pixels, which enlarges total pixels amount.

For relief of the solution, was taken in base... this greatly aproximate calculation "1/4" - Tile size for Cube = 1/4 lengths Sphere map.

sphere map Nx(N/2) = cube map (N/4)x(N/4)x6 - TRUE for re-map calculation.

*But if you want very accuracy and want to get importance remap pixel-to-pixel - use this formula - (N/4)+20%

for example - (6000/4)+20% <> 1500+300=1800